Secure Socket Layers (SSL) refers to a set of cryptographic protocols originally developed by Netscape for the purpose of securing communication between endpoints in a network. Due to security vulnerabilities, all versions of SSL have been deprecated and use of Transport Layer Security (TLS) is strongly advised. Because TLS is essentially a newer version of SSL, the term SSL is commonly used to mean either SSL or TLS.
Secure communication with a website is accomplished by means of the HTTPS protocol which is simply the use of SSL/TLS to encrypt HTTP messages. All modern browsers are capable of HTTPS communication, but it must be manually enabled on the website before it can be used.
To enable HTTPS for a website, an X.509 certificate is required. These certificates are typically purchased from a Certificate Authority (CA) such as Symantec, VeriSign, Thawte or GoDaddy and can be fairly expensive. An X.509 certificate contains information about who it was issued to (usually a website domain name), who it was issued by (usually a CA) and a public key which can be used for encryption and decryption. The public key in the certificate is mathematically related to a private key known only to the owner of the certificate. Information encrypted with the public key can only be decrypted with the private key and vice versa. This is known as asymmetric key encryption.
When a website resource is requested using HTTPS a SSL/TLS handshake must occur before any information can be exchanged. The purpose of this handshake is to verify the identify of the website, establish which cryptographic algorithms to use (the cryptosuite) and agree upon a shared master key both parties can use for encryption and decryption. In general, the process consists of the following steps. For a more detailed explanation, Chapter 4. Transport Layer Security of High Performance Browser Networking by Ilya Grigorik provides an excellent description.
- A TCP/IP connection is established.
- The browser sends information about which protocol versions and ciphersuites it supports.
- The server selects a protocol version and ciphersuite and attaches the website’s X.509 certificate.
- The browser validates the certificate, generates a master key and sends it securely to the server by encrypting it with the public key in the provided certificate.
- The server decrypts the master key with it’s own private key and notifies the client that it is ready to proceed.
It is worth noting that the certificate’s public key is only used once (to encrypt the shared master key in step 4 above). Although it would be possible to use the certificate’s public key to encrypt and decrypt all data sent to and from the server (eliminating the need for a shared master key altogether), it is not practical. Asymmetric key encryption is significantly slower than symmetric key encryption. Therefore, in order to maximize performance, asymmetric key encryption is used only in the handshake and symmetric key encryption is used for the remainder of the connection.
Since encryption alone can only guarantee privacy, another important aspect of the handshake is the certificate validation process. This step verifies the identity of the website and ensures that the browser is not communicating with an impostor. Certificate validation is based on a system of trust. Every X.509 certificate is signed by another X.509 certificate. This signifies that the owner of the signing certificate trusts the owner of the signed certificate. In this way, any given X.509 certificate forms a node in a chain of trust. The root certificate in every chain of trust is self-signed and must be trusted explicitly.
Typically, website certificates are leaf nodes in the trust chain and CA certificates are root nodes. Most browsers ship with a list of trusted root certificates from well known and trustworthy CA’s. Most operating systems also ship with a similar list of trusted root certificates and also provide a way for users to add new certificates to this list. In general, certificate validation in the SSL/TLS handshake simply verifies that the certificate presented by the website matches the domain name that was requested, that is has not expired or been revoked and that it chains up to an explicitly trusted root.
If any part of this process fails, the browser will inform the user that there is a problem with the certificate and may also provide an option to continue. When this occurs, there is no guarantee that the connection is being made to the intended website or that any information exchanged will be private. Although this sounds very serious, it may often be acceptable to proceed despite the warning. Ignoring a certificate validation warning is no less secure than accessing a website with the HTTP protocol (no security at all). Although it is not ideal to access any site over HTTP, it is nevertheless common practice and often the only option available. For websites that require the exchange of financial, personal or otherwise private information, a valid HTTPS connection should always be used.
In the end, the most important thing to understand about these protocols is what aspects they guarantee about communication.
- Confidentiality – Communication is private. This is achieved by encrypting all data with a key known only to the communicating parties.
- Integrity – Communication cannot be altered without detection. Although not discussed above, a Message Authenticate Code (MAC) is included in every exchange. This allows the receiver to verify that the message was not modified or corrupted in any way since the MAC was calculated.
- Authenticity – Communication is occurring with the intended party and not an impostor. This is verified during the certificate validation process of the SSL/TLS handshake. A fully trusted certificate implies that the owner is who they claim to be and that they (and no one else) control the certificate’s private key.