As security and privacy become more important for web-based communications, there is a natural migration toward using secure connections to ensure that the information being exchanged is not read by third parties. SSL (Secure Sockets Layer) is one such form of encryption that is commonly used in this scenario. This document provides a brief overview of how SSL/TLS should be used, and considerations that must be taken into account in order to effectively use SSL.
As more and more organizations see the value in, and deploy secure communications, we are seeing an increased frequency of implementations that do not properly account for one or more aspects of either certificate generation and usage, or protocol usage. This document is not intended to provide a complete treatment of how to use SSL and X.509 certificates, but it is intended to provide a short introduction to each of the aspects of using SSL, as well as recommendations and best practices, in order to successfully interact with Google services now and in the future. It also provides some relevant links for those seeking more information.
This document does not contain any proprietary information, and is intended to be given out to customers and/or partners to aid in their planning and implementation efforts.
At its core, SSL uses X.509 certificates to validate connection endpoints (e.g., the identity of the server to which the connection is made). To allow verification of the authenticity of these certificates, they are digitally signed by a certificate authority (CA). In a similar manner, that certificate authority’s certificate is signed by a higher level CA. This continues until the certificate is signed by a CA known as a “Root CA”. A Root CA is a CA whose certificate is considered trusted, and is distributed with the browser or operating system - thereby eliminating the need to download it from a potentially untrustworthy host. Presumably, these Root Certificate Authorities have had their trustworthiness independently evaluated, which is why browser vendors distribute their certificates.
This process of signing certificates, whereby the Root CA signs the next “lower” certificate, and that CA signs the next lower one, down to the server certificate, is known as certificate chaining.
If the certificate at the top level is not a recognized Root CA, then the browser will display a warning message to the user that they are accessing a potentially untrusted site, and ask for permission to continue.
One thing that is important to remember when building applications that use SSL, is that Root certificates can (and do) change over time. Reasons for the change are:
So, if you are planning to use SSL to secure your communications, make sure that you provide for a way to update your root certificates as they change.
In the original SSL specification, there was an expectation of one server with one service, and therefore one certificate. Unfortunately, virtual hosting broke that assumption/expectation. If virtual hosting is used, a single server can host multiple host/domain names on a single IP address.
One of the solutions to this was the addition of the Subject Alternate Name extension. This allows a certificate to have additional hostnames for which it is valid. If a server responds to www.example.com and mail.example.com, mail.example.com can be listed as an alternate name in the certificate, allowing a single certificate to be used for both hostnames.
The client software must check the hostname it is expecting against all SANs in the certificate before issuing any sort of failure or warning to the user.
Also note, the list of SANs can be quite large (numbering in the hundreds), so no assumptions should be made about size.
While SANs solve the fundamental issue of not being able to have multiple hostnames for a single server, they also have some limitations. First, if there are a lot of names, they can increase the size of the certificate, and this can increase latency for establishment of the connection.
Another problem is that the issuing certification authority must be willing to issue a certificate that has all of the names listed. If all of the names are in the same second level domain (e.g., example/com) as shown above, this is usually not a problem. However, if the certificate needed the following list:
many certificate authorities have policies that prohibit issuing such certificates.
Another disadvantage to SANs is that the certificate must be reissued every time a new hostname is added.
A certificate with multiple SANs can be used for multiple applications (e.g. email, www) or physicSCal servers (e.g. in the case where www.foo.com andwww.bar.com are separate hosts). however, because the certificate only lists one key and one key algorithm, all the services and all the hosts using the certificate need to be able to access and use the key using the single crypto method listed in the cert.
In some cases, this list of hostnames can grow quite long. Consider:
One way to reduce the number of domains listed as SANs is to use wildcards to specify the list of acceptable hostnames. In this example, all of these hostnames could be represented with the single SAN entry *.example.com.
Any client implementation that checks validity of certificates needs to be able to check the hostname against a wildcard specification.
As convenient as wildcards are, they also introduce a security hole in that any host in the example.com domain whose DNS resolves to that IP address will be able to connect via SSL. This may not be desirable.
For example, if an attacker compromised a host (say, www.example.com) having a certificate containing *.example.com, that certificate could be deployed on another host which was labeled evil.example.com, and it would continue to work, lulling the user into a false sense of security.
Also note that RFC6125 needs to be stringently adhered to when issuing or parsing wildcard certificates, as there are many browsers that will fail otherwise.
Another method of dealing with multiple hostnames for a single IP address is Server Name Indication (SNI). Details are specified in RFC4366.
With SNI, the client passes the server name as part of the initial ClientHello message. This allows a server to have multiple certificates, one for each hostname served, and know which one to select and return to the client, prior to establishment of the session.
SNI is a newer extension to the SSL protocol, and is not as widely supported in legacy systems. SANs have been around longer, and are widely supported. However, in any case, new clients (or servers) being developed should support both.
SNI will solve many of the problems mentioned earlier to which SANs are subject.
Certificate Revocation Lists are exactly what their name implies - lists of revoked certificates. When a certificate is revoked, for the remainder of its lifetime, it will be listed on the CRL of the site that previously signed that certificate as being valid. Once the expiration date has passed, the certificate will be removed from the CRL, since it should no longer be trusted.
CRLs are generated periodically (often daily or weekly), and can be downloaded and cached by clients. If a client caches the CRL, then it must provide a method to flush the cache and force the CRL to be re-downloaded. The client should provide configuration options for setting a maximum validity period for a cached CRL. These cache controls are necessary because some CAs publish CRLs frequently (e.g. daily) but specify the CRL’s nextUpdate time far in the future (e.g. 1 year) to prevent an “expired” CRL.
In contrast to the CRL, which contains all of the invalid certificates, the Online Certificate Status Protocol (OCSP) provides a way for a client to check whether a certificate has been revoked in real-time, while establishing the connection.
To support OCSP, each certificate issuer must have a server responding to OCSP requests, that returns whether or not a certificate is valid.
As an optimization, the server providing the certificate can “staple” the OCSP response to the original certificate, thus eliminating the extra round trip (but at the expense of larger packets).
Unfortunately, many clients do not require either current CRLs or a reachable OCSP responder, since the lack of availability would create a denial-of-service.
Summary of Recommendations for Client Developers
A client and server that use SSL (or TLS) must open a connection, exchange identity information (in the form of X.509 certificates), negotiate an encryption key to be used during the communication session, and then finally, exchange data. This is expanded in more detail below.
Complete details can be found in RFC2246. A more readable treatise can be found in a number of books, including SSL and TLS Essentials by Stephen Thomas and SSL and TLS: Designing and Building Secure Systems by Eric Rescorla.
In some situations where higher security is required, a client might not want to trust the entire set of certificates that are trusted by browser/OS vendors. In these cases, there is a tendency to hard-code the certificate of the server directly into the client application code. This can lead to very brittle applications, since server certificates change (usually) every one or two years. A much better approach is to place in the client only the root certificates that are trusted. But, if you do this, be sure that there is a way to update them if needed.
Note that, in the event of a compromise of the root certificate, it may be necessary for server certificates to be signed by a different root very quickly. Though this situation is rare, it does happen. One example of this was the Diginotar compromise that happened in Sept 2011. When Diginotar roots were revoked, the Dutch government needed to get new server certificates signed by a different root. If applications had hard coded only the Diginotar root, there would have been the additional problem of updating the trusted root set. So, including a set of trusted root certificates broad enough to accomodate any unplanned events is a good contingency plan.
One excellent option for implementation is OpenSSL. A good, detailed book on how to use it can be found in Network Security with OpenSSL. A thorough read is recommended, as implementing an SSL client or server can be fraught with subtleties that can affect the quality of the resulting code.
Another option that people have used is libcurl. If you are using libcurl, here are some suggestions that should be followed for updating the trusted root certificates on the client.
Unfortunately, the HTTP libraries provided with some languages have poor support for server certificate checking. For example, Python urllib doesn’t do any server certificate validation at all. So, additional work must be done to ensure that an environment using these is able to connect securely. Typically, this includes adding certificate verification, and CRL or OCSP revocation checks.
Securing Communications with SSL/TLS: A High-Level Overview - Part 1
Overview of SSL & TLS Encryption, Microsoft.
SSL and TLS Essentials by Stephen Thomas
SSL and TLS: Designing and Building Secure Systems by Eric Rescorla.
Network Security with OpenSSL - John Viega, et. al.
RFC6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations - US NIST, June 2005.