Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communication security over the Internet. They use X.509 certificates and hence asymmetric cryptography to authenticate the counterparty with whom they are communicating, and to exchange a symmetric key. This session key is then used to encrypt data flowing between the parties. TLS is an Internet Engineering Task Force (IETF,) standards track protocol, first defined in 1999. It is based on the earlier SSL specifications (1994) developed by Netscape Communications. When the SSL protocol was standardized by the IETF, it was renamed to Transport Layer Security (TLS).
As a consequence of choosing X.509 certificates, certificate authorities and a public key infrastructure are necessary to verify the relation between a certificate and its owner, as well as to generate, sign, and administer the validity of certificates.
Since protocols can operate either with or without TLS (or SSL), it is necessary for the client to indicate to the server the setup of a TLS connection. There are two main ways of achieving this:
- Use a different port number for TLS connections (for example, port 443 for HTTPS)
- Request that the server switches the connection to TLS using a protocol-specific mechanism (for example, STARTTLS for mail and news protocols)
Negotiating a secure TLS tunnel is a complicated process, and there are many ways to get it wrong. It is important to realize that every TLS connection will require up to two extra roundtrips on top of the TCP handshake—that’s a long time to wait before any application data can be exchanged. If not managed carefully, delivering application data over TLS can add hundreds, if not thousands of milliseconds of network latency.
Before the client and the server can begin exchanging application data over TLS, the encrypted tunnel must be negotiated: the client and the server must agree on the version of the TLS protocol, choose the ciphersuite, and verify certificates if necessary. Unfortunately, each of these steps requires new packet roundtrips between the client and the server, which adds startup latency to all TLS connections.
Root and intermediate certificates
There are two types of certificate authorities (CAs), root CAs and intermediate CAs. In order for a certificate to be trusted that certificate must have been issued by a CA that is included in the trusted store of the device that is connecting.
If the certificate was not issued by a trusted CA, the connecting device (e.g., a web browser) will then check to see if the certificate of the issuing CA was issued by a trusted CA, and so on until either a trusted CA is found or no trusted CA can be found (at which point the device will usually display an error). To facilitate this process of verifying a chain of trust, every certificate includes the fields Issued To and Issued By:
- An intermediate CA will show different information in these two fields, showing a connecting device where to continue checking, if necessary, in order to establish trust
- Root CA certificates are Issued To and Issued By themselves, so no further checking is possible or necessary in order to establish trust (or lack thereof)
A CA bundle is a file that contains both root and intermediate certificates.
Extended Validation SSL certificates require the use of two CA certificates to be installed on the web server; the Extended Validation Root CA certificate and the Extended Validation Intermediate CA certificate.
Read more about the installation of root and intermediate certificates.
Modern software-based TLS implementations running on commodity CPUs are fast enough to handle heavy HTTPS traffic load without needing to resort to dedicated cryptographic hardware. Rough memory usage numbers shows that by disabling TLS compression you save a lot of memory.
# Upgrade to latest openssl version # Run benchmark openssl speed sha openssl speed ecdh
As of September 2014, the latest version of all major web browsers support SSL 3.0, TLS 1.0, 1.1, and 1.2 enabled by default. However, there are still problems on several version of browsers which are not the latest but still supported:
- Support for TLS 1.1 and 1.2 but disabled by default: Internet Explorer (8–10 for Windows 7 / Server 2008 R2, 10 for Windows 8 / Server 2012, Mobile 10 for Windows Phone 8), Opera 12
- No support for TLS 1.1 and 1.2: Internet Explorer (6-8 for Windows Server 2003, 7–9 for Windows Vista / Server 2008, Mobile 7 and 9 for Windows Phone 7.x), Safari 6 for Mac OS X 10.7 and 10.8
Support for name-based virtual servers
The server uses a hostname presented by the client as part of the protocol (for HTTP the name is presented in the host header). However when using HTTPS the TLS handshake happens before the server sees any HTTP headers. Therefore it is not possible for the server to use the information in the HTTP host header to decide which certificate to present and as such only names covered by the same certificate can be served from the same IP address.
In more technical terms: from the application protocol point of view, TLS belongs to a lower layer, although the TCP/IP model is too coarse to show it. This means that the TLS handshake is usually (except in the STARTTLS case) performed before the application protocol can start. In the name-based virtual server feature being provided by the application layer, all co-hosted virtual servers share the same certificate because the server has to select and send a certificate immediately after the ClientHello message. This is a big problem in hosting environments because it means either sharing the same certificate among all customers or using a different IP address for each of them. There are two known workarounds provided by X.509:
- If all virtual servers belong to the same domain, a wildcard certificate can be used. Besides the loose host name selection that might be a problem or not, there is no common agreement about how to match wildcard certificates. Different rules are applied depending on the application protocol or software used
- Add every virtual host name in the subjectAltName extension. The major problem being that the certificate needs to be reissued whenever a new virtual server is added
In order to provide the server name, RFC 4366 Transport Layer Security (TLS) Extensions allow clients to include a Server Name Indication extension (SNI) in the extended ClientHello message. This extension hints the server immediately which name the client wishes to connect to, so the server can select the appropriate certificate to send to the client.
A cipher suite is a named combination of authentication, encryption, and message authentication code (MAC) algorithms used to negotiate the security settings for a network connection using the Transport Layer Security (TLS) / Secure Sockets Layer (SSL) network protocol.
When a TLS connection is established, a handshaking, known as the TLS Handshake Protocol, occurs. Within this handshake, a client hello (ClientHello) and a server hello (ServerHello) message are passed. First, the client sends a cipher suite list, a list of the cipher suites that it supports, in order of preference. Then the server replies with the cipher suite that it has selected from the client cipher suite list.
Certificate Signing Request
A Certificate Signing request (CSR) is a block of encrypted text that is generated on the server that the certificate will be used on. It contains information that will be included in your certificate such as your organization name, common name (domain name), locality, and country. It also contains the public key that will be included in your certificate. A private key is usually created at the same time that you create the CSR.
A certificate authority will use a CSR to create your SSL certificate, but it does not need your private key. You need to keep your private key secret. What is a CSR and private key good for if someone else can potentially read your communications? The certificate created with a particular CSR will only work with the private key that was generated with it. So if you lose the private key, the certificate will no longer work.
Application-Layer Protocol Negotiation
Because TLS belongs to a lower layer from the application protocol point of view it is not possible to determine the protocol upfront. Application-Layer Protocol Negotiation (ALPN – successor of NPN) is a Transport Layer Security (TLS) extension for application layer protocol negotiation. ALPN allows the application layer to negotiate which protocol should be performed over a secure connection in a manner which avoids additional round trips and which is independent of the application layer protocols. It is used by SPDY.
Server Name Indication
Server Name Indication (SNI) is an extension to TLS that indicates to what hostname the client is attempting to connect at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number. This will allow multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate.
Many older clients (e.g., most IE versions running on Windows XP, Android 2.2, and others) do not support SNI. Clients which do not support SNI will be presented with a default certificate and hence are likely to receive certificate warnings, unless the server is equipped with a wildcard certificate that matches the name of the website.
Chain of Trust and Certificate Authorities
Every new TLS connection requires that the browser must verify the signatures of the sent certificate chain. However, there is one more step we can’t forget: the browser also needs to verify that the certificate is not revoked. To do so, it may periodically download and cache the CRL of the certificate authority, but it may also need to dispatch an OCSP request during the verification process for a real-time check. Unfortunately, the browser behavior for this process varies wildly:
- Some browsers may use their own update mechanism to push updated CRL lists instead of relying on on-demand requests
- Some browsers may do only real-time OCSP and CRL checks for Extended Validation (EV) certificates
- Some browsers may block the TLS handshake on either revocation method, others may not, and this behavior will vary by vendor, platform, and version of the browser
Certificate Revocation List
Certificate Revocation List (CRL) specifies a simple mechanism to check the status of every certificate: each certificate authority maintains and periodically publishes a list of revoked certificate serial numbers. Anyone attempting to verify a certificate is then able to download the revocation list and check the presence of the serial number within it—if it is present, then it has been revoked. But there are instances where CRL mechanism may be insufficient:
- The growing number of revocations means that the CRL list will only get longer, and each client must retrieve the entire list of serial numbers
- There is no mechanism for instant notification of certificate revocation—if the CRL was cached by the client before the certificate was revoked, then the CRL will deem the revoked certificate valid until the cache expires
To address some of the limitations of the CRL mechanism, the Online Certificate Status Protocol (OCSP) was introduced.
Online Certificate Status Protocol (OCSP)
The Online Certificate Status Protocol (OCSP) provides a mechanism to perform a real-time check for status of the certificate. OCSP allows the verifier to query the certificate database directly for just the serial number in question while validating the certificate chain. But the requirement to perform real-time OCSP queries creates several problems of its own:
- The CA must be able to handle the load of the real-time queries
- The CA must ensure that the service is up and globally available at all times
- The client must block on OCSP requests before proceeding with the navigation
- Real-time OCSP requests may impair the client’s privacy because the CA knows which sites the client is visiting
Note that some browsers distribute their own CRL lists, others fetch and cache the CRL files from the CAs. Similarly, some browsers will perform the real-time OCSP check but will differ in their behavior if the OCSP request fails.
See figure beneath for a status list of important performance-oriented features: resumption, stapling, false start (requires NPN and forward secrecy), and support for SPDY and HTTP/2 protocols.
OCSP stapling is an alternative approach to the OCSP for checking the revocation status of X.509 digital certificates. The server can include (staple) the OCSP response from the CA to its certificate chain, allowing the browser to skip the online check. Moving the OCSP fetch to the server allows the server to cache the signed OCSP response and save the extra request for many clients. However, there are also a few things to watch out for:
- OCSP responses can vary from 400 to 4,000 bytes in size. Stapling this response to your certificate chain may once again overflow your TCP congestion window—pay close attention to the total size
- Only one OCSP response can be included, which may still mean that the browser will have to issue an OCSP request for other intermediate certificates, if it has not been cached already
OCSP stapling was implemented in:
- Opera – Version 8.0 and above
- Firefox – Enabled by default in version 3.0 and above
- Internet Explorer – Enabled by default in version 7.0 and above
- Safari – Enabled by default in Mac OS X 10.7 and above
- Google Chrome – Enabled by default
To check if your server supports OCSP stapling:
openssl s_client -connect example.com:443 -tls1 -tlsextdebug -status
Optimizing TLS handshake
New TLS connections require two roundtrips for a “full handshake” and CPU resources to verify and compute the parameters for the ensuing session. However, the good news is that we don’t have to repeat the full handshake in every case:
- If the client has previously communicated with the server, an abbreviated handshake can be used, which requires one roundtrip and allows the client and server to reduce the CPU overhead by reusing the previously negotiated parameters for the secure session. This is called TLS Session Resumption
- False Start is an optional TLS protocol extension that allows the client and server to start transmitting encrypted application data when the handshake is only partially complete—i.e. once ChangeCipherSpec and Finished messages are sent, but without waiting for the other side to do the same. This optimization reduces new handshake overhead to one roundtrip. Note that Chrome will continue to use False Start with websites that have deployed Next Protocol Negotiation.
For best results, both optimizations should be used together to provide a single roundtrip handshake for new and returning visitors, plus computational savings for sessions that can be resumed based on previously negotiated session parameters.
TLS Session Resumption
Session resumption is a performance optimization that allows a client/server pair to re-use previously generated crypto material, so that they don’t have to compute new crypto keys every time a connection gets established. Because it greatly reduces the overhead caused by SSL/TLS, it’s a crucial server configuration in order to make SSL/TLS affordable. There exists two distinct ways to achieve session reuse: session identifiers and session tickets.
Session resumption provides two important benefits: it eliminates an extra handshake roundtrip for returning visitors and reduces the computational cost of the handshake by allowing reuse of previously negotiated session parameters. However, it does not help in cases where the visitor is communicating with the server for the first time, or if the previous session has expired.
To get the best of both worlds—a one roundtrip handshake for new and repeat visitors, and computational savings for repeat visitors—we can use TLS False Start, which is an optional protocol extension that allows the sender to send application data when the handshake is only partially complete.
All modern browsers are capable of using TLS False Start, but will only do so when certain conditions are met by the server:
- Chrome and Firefox require an NPN/ALPN protocol advertisement to be present in the server handshake, and that the cipher suite chosen by the server enables forward secrecy
- Safari requires that the cipher suite chosen by the server enables forward secrecy
- Internet Explorer uses a combination of a blacklist of known sites that break when TLS False Start is enabled, and a timeout to repeat the handshake if the TLS False Start handshake failed
To enable TLS False Start across all browsers the server should advertise a list of supported protocols via the NPN/ALPN extension—e.g. “http/1, http/1.1″—and be configured to support and prefer cipher suites that enable forward secrecy.
Session Identifiers allow the server to create and send a session identifier as part of its ServerHello message during the full TLS negotiation. The server could then maintain a cache of session IDs and the negotiated session parameters for each peer. In turn, the client could then also store the session ID information and include the ID in the ClientHello message for a subsequent session, which serves as an indication to the server that the client still remembers the negotiated cipher suite and keys from previous handshake and is able to reuse them. Assuming both the client and the server are able to find the shared session ID parameters in their respective caches, then an abbreviated handshake can take place. Otherwise, a full new session negotiation is required, which will generate a new session ID. Leveraging session identifiers allows us to remove a full roundtrip, as well as the overhead of public key cryptography.
However, one of the practical limitations of the Session Identifiers mechanism is the requirement for the server to create and maintain a session cache for every client. This results in several problems on the server, which may see tens of thousands or even millions of unique connections every day: consumed memory for every open TLS connection, a requirement for session ID cache and eviction policies, and nontrivial deployment challenges for popular sites with many servers, which should, ideally, use a shared TLS session cache for best performance. To address this concern for server-side deployment of TLS session caches, the Session Ticket replacement mechanism was introduced.
None of the preceding problems are impossible to solve, and many high-traffic sites are using session identifiers successfully today. But for any multiserver deployment, session identifiers will require some careful thinking and systems architecture to ensure a well operating session cache.
Session Tickets removes the requirement for the server to keep per-client session state (server-side session cache). Instead, if the client indicated that it supports Session Tickets, in the last exchange of the full TLS handshake, the server can include a New Session Ticket record, which includes all of the session data encrypted with a secret key known only by the server.
This session ticket is then stored by the client and can be included in the SessionTicket extension within the ClientHello message of a subsequent session. Thus, all session data is stored only on the client, but the ticket is still safe because it is encrypted with a key known only by the server.
Perfect Forward Secrecy
Perfect Forward Secrecy (PFS) works by the idea that a compromise of the private key should not compromise session key. Forward secrecy is a property of key-agreement protocols ensuring that a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future. The key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data is derived from some other keying material, then that material must not be used to derive any more keys. In this way, compromise of a single key permits access only to data protected by that single key. The Algorithm that helps to achieve this kind of perfect forward secrecy is called as Diffie–Hellman key exchange.
Assuming the interest and knowledge to deploy forward secrecy is there, two obstacles remain:
- DHE (Diffie-Hellman) is significantly slower. For this reason, web site operators tend to disable all DHE suites in order to achieve better performance. In recent years, we’ve seen DHE fall out of fashion. Internet Explorer 9 and 10, for example, support DHE only in combination with obsolete DSA keys
- ECDHE (Diffie-Hellman elliptic-curve) too is slower, but not as much as DHE. But be warned that the situation might have changed since 2011. However, ECDHE algorithms are relatively new and not as widely supported. For example, they were added to OpenSSL only fairly recently, in the 1.x releases
If you’re willing to support both ECDHE and DHE, then you will probably be able to support forward secrecy with virtually all clients. But ECDHE alone is supported by all major modern browsers, which means that even with only ECDHE you might be able to cover a very large chunk of your user base. The decision what to do is entirely up to you. Google, for example, do not support any DHE suites on their main web sites.
While accessing any HTTPs enabled websites, you can easily see the cipher suite used by selecting the LOCK icon beside the URL area. If you see something like TLS_ECDHE_ECDSA, its using PFS.
Configure Perfect Forward Secrecy
The configuration differs slightly on each web server package. We will see how to enable this on Apache and Nginx. Nginx has this added advantage that if you are using SSL on it, it by default enforces PFS, by keeping the DH and Elliptical DH at a higher priority than other ciphers. However, please remember the fact that any web server that employs DH for PFS then there will be a slight performance degradation as the web server has to do a little bit more math. The below shown nginx configuration parameters are quite self explanatory. The only main thing that you need to note here is the order in which the cipher is mentioned.
ssl_prefer_server_ciphers on; ssl_protocols SSLv3 TLSv1; ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:RC4-SHA;
In apache, the configuration is exactly the same with only the parameter name difference. The apache configuration looks like the one shown below.
SSLProtocol all -SSLv2 -SSLv3 SSLHonorCipherOrder on SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4EECDHEDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
SSL termination refers to the process that occurs at the server end of an SSL connection, where the traffic transitions between encrypted and unencrypted forms. A device that handles both SSL offloading and SSL termination can be advantageous in some situations, such as high-performance large-scale clustering of SSL VPNs.
HTTP Strict Transport Security
HTTP Strict Transport Security (HSTS) is a security policy mechanism that allows the server to declare access rules to a compliant browser via a simple HTTP header. Specifically, it instructs the user-agent to enforce the following rules:\
- All requests to the origin should be sent over HTTPS
- All insecure links and client requests should be automatically converted to HTTPS on the client before the request is sent
- In case of a certificate error, an error message is displayed, and the user is not allowed to circumvent the warning
- max-age specifies the lifetime of the specified HSTS ruleset in seconds
- Optionally, the UA can be instructed to remember (“pin”) the fingerprint of a host in the specified certificate chain for future access, effectively limiting the scope of authorities who can authenticate the certificate
HSTS converts the origin to an HTTPS-only destination and helps protect the application from a variety of passive and active network attacks against the user. Performance wise, it also helps eliminate unnecessary HTTP-to-HTTPS redirects by shifting this responsibility to the client, which will automatically rewrite all links to HTTPS.
As of early 2013, HSTS is supported by Firefox 4+, Chrome 4+, Opera 12+, and Chrome and Firefox for Android. See complete list here.
A little-known feature of TLS is built-in support for lossless compression of data transferred within the record protocol: the compression algorithm is negotiated during the TLS handshake, and compression is applied prior to encryption of each record. However, in practice, you should disable TLS compression on your server for several reasons:
- The “CRIME” attack, published in 2012, leverages TLS compression to recover secret authentication cookies and allows the attacker to perform session hijacking.
- Transport-level TLS compression is not content aware and will end up attempting to recompress already compressed data (images, video, etc.).
Double compression will waste CPU time on both the server and the client, and the security breach implications are quite serious: disable TLS compression. In practice, most browsers disable support for TLS compression, but you should nonetheless also explicitly disable it in the configuration of your server to protect your users.
openssl req -in www.domain.nl.csr -noout -text
Read Introducing Universal SSL by CloudFlare.
Visit Qualys SSL Labs to test your server certificate and configuration.
Read more on the Mozilla Wiki about configuration of TLS on servers.