Two technologies come to mind when we talk about trusted connections over the Internet: Secure Sockets Layer (SSL) and Transport Layer Security (TLS). Online conversations are made secure, and e-commerce is made possible by the encryption protocols SSL and its offspring TLS. These protocols provide privacy, authentication, and data integrity. The URL of a website that uses SSL/TLS begins with "HTTPS" rather than "HTTP."
In 1995, Netscape, the company behind the most widely used web browser at the time, created SSL for the first time. SSL 1.0 was never made available to the general public, and SSL 2.0 had significant issues. SSL 3.0, which was totally redesigned and introduced in 1996, laid the foundation for what came after.
The Internet Engineering Task Force (IETF) standardized the second iteration of the SSL protocol, which was introduced in 1999, and gave it a new name: Transport Layer Security, or TLS. Three additional versions have since been issued, the most recent and secure of which is TLS 1.3, which was published in August 2018 and is described in RFC 8446.
TLS vs. SSL
The two names are frequently confused and used interchangeably because they are so similar to one another. SSL still has strong name recognition, and some individuals still use SSL to refer to TLS, while others use the term "SSL/TLS encryption."
By 1999, Netscape was no longer participating in the development of the SSL upgrade that the Internet Engineering Task Force (IETF) recommended. The name change was implemented to indicate the change in ownership; there are not many significant differences between the final version of SSL (3.0) and the initial version of TLS.
In a paper published in 2014, the National Institute of Science and Technology determined SSL 3.0 to be "not acceptable for use in the safeguarding of Federal information" and deprecated it. Later that year, the Padding Oracle On Downgraded Legacy Encryption (POODLE) attack was discovered, which was the final straw. This vulnerability allows an attacker to decode content within an SSL session by taking advantage of the way blocks of data are encrypted using a particular kind of encryption algorithm within the SSL protocol.
Three updates to TLS have been released: TLS 1.1 (2006), TLS 1.2 (2008), and TLS 1.3. (2018). The IETF eliminated support for SSL 2.0 backward compatibility in 2011. Backward compatibility between SSL 3.0 and TLS 1.1 and 1.2 was maintained. TLS 1.3 was created from scratch rather than as an evolution of TLS 1.2. It was redesigned to eliminate legacy functionality and speed up performance on a secure connection. TLS 1.3 intends to reduce the risk of downgrade attacks, which force the server to use a less secure, more dated protocol, by avoiding downward compatibility.
Functional differences between SSL and TLS
Although SSL and the initial versions of TLS do not share many differences, they implement message authentication in a different way.
A message is authenticated via SSL by utilizing a brief piece of data known as a message authentication code (MAC), which ensures a message's validity and integrity. TLS employs a keyed-hash message authentication code (HMAC), or MAC, which is generated using a secret cryptographic key and a cryptographic hash function.
TLS is frequently also referred to as "By Program" or "implicit" security since it requires a program to establish an unsafe connection first before using special commands to activate encryption. This is distinct from "By Port" or "explicit" security in SSL, or an explicit connection to a port that anticipates a session to commence with security negotiation.
TLS 1.3 is the version where we can witness the most changes, except for the removal of the backward compatibility with the previous versions. TLS 1.3 enhances TLS 1.2 in a variety of ways:
- Removed support for SHA-224 and MD5, two vulnerable hashing methods.
- Abandoned the use of RSA key exchanges. Only Diffie-Hellman key exchanges, which provide forward secrecy, are used in TLS 1.3.
- Compared to TLS 1.2, handshake negotiation is less latent.
How TLS/SSL Protocol works
Before digging into the specifics of how the TLS/SSL protocol works, it is important to understand some overarching principles:
- A TLS handshake signals the start of secure communication. The two parties create session keys during the TLS handshake, and the session keys encrypt and decrypt any communications after the handshake.
- Each new session uses a unique set of session keys to encrypt communications.
- TLS ensures that the party on the server side, or the website the user is interacting with, is actually whom they claim to be.
- TLS additionally makes sure that data hasn't been altered because it sends transmissions with a message authentication code (HMAC).
The other important issue to understand is that the protocol makes use of both public key or asymmetric encryption and symmetric encryption. The reasons behind that technique are explained in the next section, where we describe the TLS handshake process.
The TLS handshake process
The handshake process is quite complex. However, the following steps provide a high-level outline of how the TLS handshake is implemented.
- The client contacts the server and requests a secure connection. The server replies with the list of cipher suites that it knows how to use. A cipher suite is an algorithmic toolkit of creating encrypted connections. The client compares this list against its own list of supported cipher suites, selects one, and informs the server accordingly.
- The server then provides its SSL digital certificate, an electronic document issued by a third-party authority confirming the server's identity (more on this shortly after). This is where asymmetric encryption is employed since the SSL certificate contains the server's public key. Once the client receives the certificate, it confirms the certificate's authenticity.
- Using the server's public key, the client and server establish a session key that both will use for the rest of the session to encrypt communication using symmetric encryption. To establish the session key, the two parties use Diffie-Hellman key exchange.
The reason for switching from asymmetric to symmetric encryption is simple: asymmetric cryptography involves difficult mathematical problems that consume a lot of computing resources. If we were to employ public key cryptography to encrypt all the information in a communications session, both the computer and the connection would bring to a halt.
What is an SSL certificate?
An SSL certificate is an electronic document that verifies the identity of a server and enables encrypted communication. These certificates are crucial to the SSL/TLS protocol, as they provide the client with the appropriate public cryptographic key to establish secure connections. But their mission extends beyond simply providing the key; they also verify that the key is associated with the company providing it to the customer.
Certificate Authorities (CAs) act as the equivalent of a passport office when it comes to authenticating identities and issuing certificates. Organizations that wish to offer TLS-encrypted services must obtain certificates from CAs, which then validate the organizations' identities.
X.509 is the standard that defines SSL certificates. This standard enables certificates to incorporate additional information beyond the public key and the owner's proven identity.
Types of TLS/SSL Certificates
Single-domain SSL certificates
A single-domain SSL certificate only applies to a single domain. It cannot be used to authenticate any other domain, including subdomains of the issued domain. If venafi.com has a single-domain certificate, then venafi.com/education-center is likewise protected.
Wildcard SSL certificates
Wildcard SSL certificates are applicable to a single domain and all of its subdomains. A subdomain exists behind the main domain. Typically, subdomains will have an address that does not begin with www. Among the subdomains of www.venafi.com are support.venafi.com and success.venafi.com, for instance. Each is a subdomain of the main domain venafi.com.
However, the freedom that comes with using wildcard certificates also introduces substantial security vulnerabilities, as the same private key is used across many platforms, hence raising the organization's risk of compromise. Without sufficient security, control, and monitoring, wildcard certificates can be readily abused by cybercriminals to take advantage of the trust companies have in them and launch phishing attacks.
Multi-domain SSL certificates
A multi-domain SSL certificate lists numerous different domains on one certificate. Domains that are not subdomains of one another can share a certificate using a multi-domain certificate.
Securing TLS/SSL Certificates
The internet has made global trade swift and seamless. This is only feasible because internet connections are trusted to be secure. TLS/SSL is essential for this level of trust. SSL is dependent upon SSL certificates. Organizations must deploy SSL certificates and related private keys to their systems to provide them with reliable, unique identifiers. The SSL certificate lets anyone connecting to a system to verify that their data is being sent to the correct location. Additionally, it permits the development of secure connections so that no one may intercept communications.
Despite the importance of TLS certificates to the security of both public and private web services, many organizations lack the ability to centrally monitor and manage their certificates.
This lack of a central certificate management service puts the company at risk, as certificates require frequent monitoring and maintenance once they have been distributed. Organizations that handle their certificates improperly run the danger of system disruptions and security breaches, which can lead to revenue loss, reputation damage, and the disclosure of sensitive data to attackers.
The NIST SP 1800-16 defines best practices for effective and resilient certificate management that should be implemented by any professional organization. Using commercially available technologies, the publication demonstrates how medium and large businesses that rely on TLS can secure both customer-facing and internal applications and better manage TLS server certificates by:
- Defining operational and security policies and assigning roles and responsibilities.
- Creating thorough certificate inventory and tracking ownership.
- Continuously checking the operational and security status of certificates.
- Automating certificate management to minimize human mistakes and maximize large-scale productivity.
- Enabling quick migration to new certificates and keys when weak, compromised, or susceptible cryptographic techniques are discovered.
Best practices for automating TLS certificate management
The following recommendations provide a framework for automating the management and effectively protecting SSL/TLS keys and certificates.
1. Gain visibility
Create a thorough and accurate inventory of your corporate keys and certificates as the initial step in gaining visibility into the entire machine identity lifecycle. If you attempt to accomplish this manually, you will quickly learn that it is a never-ending, inefficient, wasteful, and error-prone operation. This is due to the sheer quantity and scope of machine identities in your environment. To produce an accurate inventory, businesses want an automated system that instantly scans their whole digital infrastructure to identify all machine identities, including where they are installed, who owns them, and how they are utilized.
2. Gather intelligence on certificate vulnerabilities
Each form of machine identity presents its own distinct difficulties and complexity. Organizations require enhanced threat intelligence to establish a baseline for detecting unsafe keys and certificates, such as those with insecure encryption algorithms or short key lengths. A baseline aids in the identification of applications supported by vulnerable keys and certificates, as well as potentially compromised, underused, or expired certificates that should be retired.
The intelligence of machine identification loses significance if it simply reflects a single moment in time. Only by automating your information collection can you continuously monitor the security and wellbeing of your machine identities. In addition, since your intelligence is automatically updated, you can generate warnings if abnormalities or vulnerabilities are discovered.
3. Enforce policies
Your security posture should contain a tight and well-defined policy that dictates which application configurations are required and how your certificates are utilized. To ensure the safety of your machine identities, you must establish machine identity security policies and practices. This allows you to control every aspect of machine identities, including issuance, configuration, use, ownership, maintenance, and security.
If you are unable to enforce policies, you do not have policies. You have recommendations. Additionally, enforcing policies guarantees that each machine identity in your firm conforms with applicable industry and government standards. Automating the enforcement of machine identity regulations guarantees that your organization maximizes the security of every machine identity it employs and can produce audit-ready documentation anytime it is required. Automation is a crucial capability that allows consistent enforcement of your organization's machine identity policy and applicable regulatory obligations.
4. Automate remediation
Strong security policies necessitate the implementation of procedures to promptly rotate all keys and certificates on a regular basis or as needed. With an automated solution, what was once an error-prone human operation becomes a routine component of overall security management.
Automation provides the ability to respond swiftly to important security events, such as a compromised certification authority (CA) or zero-day vulnerability in a cryptographic algorithm or library. Automation is also the quickest approach to remedy security events with a narrower scope, such as changing a compromised certificate used on several machines.
5. Save money, ensure compliance with automation
TLS certificates need to be generated not only for your organization’s websites and web applications, but also for all your organization’s internal and external entities which interface with public key infrastructures, such as email, internal documents, application authentication, Internet of Things devices, and network services of all kinds. You could be working with one certificate authority or several different certificate authorities. Certificates constantly expire, and new certificates constantly need to be generated. One little mistake made with any of them can have catastrophic consequences. Cyber attackers could access your sensitive data, interfere with your crucial business operations, or millions of customers could find that your services for them do not work.
To identify breaches more quickly, reduce the loss incurred by breaches, and ultimately, reduce the number of breaches, firms must institute effective, automated machine identity protections. Finally, automation relieves human workers of the burden of having to conduct very tedious tasks. The human brain absolutely hates tedious tasks and boredom increases the risk of human error. Computerized automation systems conduct tedious tasks perfectly according to the instructions they have been given, and they are much less expensive than human labor hours. Save your labor costs for work that absolutely requires human beings.
If you want to dig more into the topic of machine identity management, download the Machine Identity Management Dummies Guide.