Let's return to the concept of an SSL certificate. But their purpose goes beyond just supplying the key itself; they also authenticate that the key is in fact associated with organization offering it to the client. How does this work? Certificates are issued by Certificate Authorities CAs , who serve as the equivalent of a passport office when it comes to confirming identities. Organizations that want to offer services encrypted by TLS must purchase certificates from CAs, who in turn verify that the organizations are who they claim to be.
For instance, if you wanted to buy a certificate to secure a website at example. That way, if someone connects to example. This can prevent man in the middle attacks. Notice that we used the phrase "trusted CA" in that last paragraph. Anyone can set themselves up as a certificate authority; how can you tell which ones perform the due diligence needed to authenticate their customers?
Fortunately, the job of figuring that out is mostly taken care of by software manufacturers. The decisions on which CAs to trust have high stakes, as a showdown between Google and Symantec over what Google felt were Symantec's lax standards made clear.
The standard that defines SSL certificates is called X. This standard allows certificates to carry a lot of information beyond just the public key and the confirmed identity of the certificate owner; DigiCert is a CA whose knowledge base has a detailed breakdown of the standard. Almost all of the exchange and confirmation of information detailed above takes place behind the scenes as you communicate with servers that offer TLS-encrypted connections.
The checker will return a host of information about the tested site's certificate, including the server type, which web browsers will and won't trust the certificate, the issuer, the serial number, and the expiration date. Most SSL checkers are free services offered by CAs as marketing tools for their wares; many will, for instance, allow you to set an alert for when an inspected certificate will expire, on the assumption that it's your certificate and you'll be in the market for a new one as that date approaches.
If you're looking for a somewhat less commercial alternative, check out the SSL checker from Qualys SSL Labs , which provides a particularly robust collection of information on inspected websites. TLS 1. It established a host of new cryptographic options for communication. However, like some previous versions of the protocol, it also allowed older cryptographic techniques to be used, in order to support older computers. Unfortunately, that opened it up to vulnerabilities, as those older techniques have become more vulnerable as time has passed and computing power has become cheaper.
In particular, TLS 1. Many of these problems have arisen in the last two years, increasing the sense of urgency for updating the protocol. If this is all completed successfully, the handshake is finished. At this point, the application protocol is established. Data can then be exchanged securely in the same way as the Finished message from above, with authentication and optional encryption. This handshake is much like the basic TLS handshake, but the client is authenticated as well. Once the server is finished, the client sends its certificate in a Certificate message.
Once a handshake has already taken place, TLS allows much of the process to be cut out by using an abbreviated handshake instead. These handshakes use the session ID to link the new connection to the previous parameters. An abbreviated handshake allows both parties to resume the secure connection with the same setup that was negotiated earlier.
Because some of the cryptography that is normally involved in initiating a handshake can be pretty heavy on computational resources, this saves time and makes the connection easier.
The process begins with the Client Hello message. If the server knows the session ID, it includes it in its Server Hello message. If it does not recognize the session ID, it will return a different number, and a full TLS handshake will have to take place instead.
If the server does recognize the session ID, then the Certificate and Key Exchange steps can be skipped. There is also a TLS extension that allows connections to be resumed with session tickets instead of session IDs. The server encrypts data about the session and sends it to the client. When the client wants to resume this connection, it sends the session ticket to the server, which decrypts it to reveal the parameters.
At the start of the handshake, the client and the server negotiate the parameters of the connection by mutual agreement. The first of these is which version of TLS will be used. This is the highest version that both parties support, which tends to be the most secure. The parties also decide which key exchange algorithm they will use to establish the master key.
The hash function, encryption algorithm, and compression method are also agreed upon in this stage. These will be covered in detail when we discuss the Application protocol later in the article. Authentication is a key part of securing a communication channel, because it lets both parties know that they are actually talking to who they think they are and not an impostor. In TLS and many other security mechanisms, this is achieved with what are known as digital certificates.
Digital certificates are electronic documents that show the link between an individual or entity and their public key. This link is validated by a certificate authority CA , which is a trusted organization that verifies that the two are actually related, then uses its own reputation to grant trust to the certificate.
Different certificate levels represent varying degrees of trust. The important thing to know is that if a client or a server has a reliable and valid certificate, then it is reasonable to assume that the public key is legitimate and that you are not dealing with an attacker.
Public-key encryption also known as asymmetric encryption is an important part of cryptography, and it is used extensively in the different aspects of TLS. The short explanation is that public-key cryptography uses a key pair for encryption and decryption, rather than just a single key.
Of course, the public key can be shared publicly while the private key must be kept secret. Public-key encryption allows parties to share information securely, even if they have never met or had an opportunity to exchange keys beforehand.
It does this through some unique properties of prime numbers. As we saw above when we discussed the process of the basic TLS handshake, after a party or both parties proves its identity with its public certificate, the next step is to establish the master secret, also known as the shared secret.
The master secret is the base for deriving the keys used to both encrypt and check the integrity of data transmitted between the two parties. The TLS handshake can use a number of different mechanisms to share this secret securely. Each has its own advantages and disadvantages, such as providing forward secrecy, but these differences are out of the scope of this article. The exact process will depend on which key exchange method has been chosen, but it follows the rough steps mentioned in The basic TLS handshake section.
The premaster secret is derived according to whichever key exchange method had previously been selected. The client and server then both use the premaster secret and the random numbers that they sent at the start of the communication to come up with the master secret. Once the master key has been calculated, it is used to come up with either four or six separate keys. These are the:. Establishing the master key is an important part of the TLS handshake, because it enables both sides of the connection to securely derive keys that can be used for both authentication and encryption.
Separate keys are used for both processes as a precaution. Once the authentication and encryption keys have been derived, they are used to protect both Finished messages, as well as records sent through the application protocol. Once a secure connection has been established by the TLS handshake, the application protocol is used to protect the transmitted data.
It can be configured to use a wide range of algorithms to suit different scenarios. To prove the integrity of the data being sent, the sender runs the information through a hash function to return a unique string of characters. These are special formulas that will always return the same result whenever they receive the same input. The sender signs this data with their private key to form what is known as a digital signature, The digital signature is then attached to the message and sent to the recipient.
They then use the same hash function on the data that was sent. The recipient then compares the two values. If they are the same, it means that the data has not been altered since it was signed by the sender. If they are different, it is likely that the data has been tampered with, or there has been some other error. If you would like a more in-depth understanding, check out our article on encryption, salting and hashing. TLS uses symmetric-key encryption to provide confidentiality to the data that it transmits.
Unlike public-key encryption, just one key is used in both the encryption and decryption processes. Once data has been encrypted with an algorithm, it will appear as a jumble of ciphertext. As long as an appropriate algorithm is used, attackers will not be able to access the actual data, even if they intercept it.
Compression is the process of encoding data to make it take up less room. TLS supports compression if both sides of the connection decide to use it. Despite this ability, it is generally recommended to avoid using TLS to compress data, especially since the CRIME attack see the TLS Security Issues section below was found to be able to take advantage of compressed data for session hijacking.
Padding adds extra data to a message before it is encrypted. If the connection or security becomes unstable, compromised, or a serious error has occurred, the alert protocol allows the sender to notify the other party. These messages have two types, either warning or fatal.
A warning message indicates that the session is unstable and allows the recipient to determine whether or not the session should be continued. A fatal message tells the recipient that the connection has been compromised or a serious error has occurred. The sender should close the connection after they send the message. The alert protocol also contains information about what is causing the particular connection problem.
This can include things like decryption failure, an unknown certificate authority, an illegal parameter and much more. Almost every website supports TLS 1. As we move toward the dominance of TLS 1. TLS 1. We will run through the most significant changes here, but if you really want to get into the details, you should head over to our TLS SSL handshakes explained article.
One of the most significant changes in TLS 1. In TLS 1. When the server supports these parameters, it uses them as part of its Server Hello message. Not only can this eliminate the key exchange messages, but it means that some of the data is already encrypted as part of the Server Hello message. This enhances the security. Older versions of TLS offered a large number of cipher suites that allowed for flexible implementation.
This larger range of choices often led to them being used improperly, resulting in poor security. It is therefore recommended that all clients and servers insist on mandatory usage of TLS in their communications, and preferably the most recent version TLS 1.
For complete security, it is necessary to use it in conjunction with a publicly trusted X. TLS uses a combination of symmetric and asymmetric cryptography, as this provides a good compromise between performance and security when transmitting data securely. With symmetric cryptography, data is encrypted and decrypted with a secret key known to both sender and recipient; typically but preferably bits in length anything less than 80 bits is now considered insecure.
Symmetric cryptography is efficient in terms of computation, but having a common secret key means it needs to be shared in a secure manner. Asymmetric cryptography uses key pairs — a public key, and a private key. The public key is mathematically related to the private key, but given sufficient key length, it is computationally impractical to derive the private key from the public key. This allows the public key of the recipient to be used by the sender to encrypt the data they wish to send to them, but that data can only be decrypted with the private key of the recipient.
The advantage of asymmetric cryptography is that the process of sharing encryption keys does not have to be secure, but the mathematical relationship between public and private keys means that much larger key sizes are required. The recommended minimum key length is bits, with bits preferred, but this is up to a thousand times more computationally intensive than symmetric keys of equivalent strength e.
For this reason, TLS uses asymmetric cryptography for securely generating and exchanging a session key. The session key is then used for encrypting the data transmitted by one party, and for decrypting the data received at the other end. Once the session is over, the session key is discarded. However, these may be considered implementation rather than protocol issues, and there are tools available to test for weaker cipher suites.
This is normally undertaken using an X. It is highly recommended though, to use certificates issued by publicly trusted CAs. Digital certificates certify the public key of the owner of the certificate known as the subject , and that the owner controls the domain being secured by the certificate. A CA therefore acts as a trusted third party that gives clients known as relying parties assurance they are connecting to a server operated by a validated entity.
0コメント