This page covers some relevant technical concepts relevant to the strength and quality of a server’s HTTPS configuration.
- SSL and TLS
- Forward secrecy
- Signature algorithms, such as SHA-1 and SHA-2
- Strong ciphersuites
- A complete certificate chain
SSL and TLS
HTTPS today uses Transport Layer Security, or TLS. TLS is a network protocol that establishes an encrypted connection to an authenticated peer over an untrusted network.
Earlier, less secure versions of this protocol were called Secure Sockets Layer, or SSL).
SSL and TLS perform the same function, and TLS is a direct successor and replacement for SSL. Because of its early ubiquity, “SSL” is frequently used today to generically refer to TLS/HTTPS. However, all versions of SSL as a protocol are now considered insecure for modern use.
The major versions of SSL/TLS in use today are:
- SSLv3: Released in 1996. Considered to be insecure after the POODLE attack was published in 2014. Turning off SSLv3 effectively removes support for Internet Explorer 6.
- TLSv1.0: - Released in 1999. Used widely today to support some older clients, like IE8 and Android 4.3 and below. NIST Special Publication 800-52 disallows TLSv1.0 for government-facing systems.
- TLSv1.1: - Released in 2006. An improvement over TLSv1.0, but was quickly superseded by TLSv1.2.
- TLSv1.2: - Released in 2008. This is the strongest form of TLS today, and is widely supported by modern browsers.
Typically, browsers and servers support multiple versions, and will attempt to negotiate the strongest mutually supported version.
It is possible for an attacker to interfere with the negotiation process and attempt to “downgrade” connections to the oldest mutually supported version.
A downgrade attack can be prevented by using TLS Fallback SCSV, a TLS extension proposed in 2014 and which is enabled by default in newer versions of OpenSSL.
For more details of NIST recommendations, read NIST Special Publication 800-52.
- The Pulse HTTPS dashboard for .gov domains will note when a domain still offers insecure SSLv3, or when a domain does not yet offer TLSv1.2.
- https.cio.gov is configured to support TLSv1.0, TLSv1.1, and TLSv1.2, and has TLS Fallback SCSV enabled.
Forward secrecy
Forward secrecy protects information sent over an encrypted HTTPS connection now from being decrypted later, even if the server’s private key is later compromised.
In non-forward-secret HTTPS connections, if an attacker records encrypted traffic between a website and its visitors, and later obtains the website’s private key, that key can be used to decrypt all past recorded traffic.
In forward secret connections, the server and client create a temporary key for every new session that gets effectively “thrown away” after the session is complete. This means that even if the server’s base private key is compromised, an attacker can’t retroactively decrypt information.
In TLS, forward secrecy is provided by choosing ciphersuites that include the DHE and ECDHE key exchanges.
Note: Current drafts of TLS 1.3, the next version of TLS, require new connections to use forward secrecy by removing support for static RSA and DH key exchange.
- The Pulse HTTPS dashboard for .gov domains will note when a domain offers little or no forward secrecy.
- https.cio.gov is configured to offer robust forward secrecy.
Signature algorithms
The HTTPS/TLS security model uses “certificates” to guarantee authenticity. These certificates are cryptographically “signed” by a trusted certificate authority.
The certificate authority’s trusted root certificate (which is included with your OS or browser) is used to sign an intermediary certificate, which is used to sign your website’s certificate. There may be more than one intermediary certificate in the chain. A part of the signature process is computing a “hash” of the data included in the certificate. This can be done using a standard hashing algorithm, such as SHA-1 or SHA-2.
SHA-1 has been shown to have serious weaknesses, and so browser and OS providers like Google, Microsoft, and Mozilla have announced timelines to deprecate SHA-1 in favor of the SHA-2 family of algorithms.
NIST has disallowed SHA-1 for digital signature generation after 2013.
As of January 2016, commercial CAs are forbidden by most root programs from issuing a SHA-1 certificate. As such, obtaining a publicly trusted SHA-1 certificate is no longer feasible. In addition, site owners with an existing SHA-1 certificate should be aware that many browsers and OSes will be disabling SHA-1 support in early 2017.
Strong ciphersuites
Each TLS handshake makes use of a set of cryptographic primitives, including ciphers and signature algorithms.
Which ciphers and algorithms are used in a handshake is a function of client support and preferences, and server support and preferences.
Federal agencies have no control over the primitives supported by major clients used by the public (such as web browsers, cURL, and other common HTTP clients). However, agencies can control the ciphers and algorithms that are supported by their servers (which can also include proxies, load balancers, or content delivery networks).
When configuring servers:
Avoid SHA-1 in the TLS handshake. Though there is no known specific vulnerability in the use of SHA-1 as part of the TLS handshake, SHA-1 has already been shown to be unacceptably weak for use as a signature algorithm for issued certificates. Beginning with TLS 1.2, servers can and should negotiate the use of a signature algorithm other than SHA-1 for the TLS handshake.
Avoid RC4. RC4 was once a popular cipher, but in 2013 was found to have a critical flaw. Modern browsers no longer support RC4-based ciphersuites, and servers should no longer need to be configured to support RC4.
A complete certificate chain
In addition to the certificate itself, you should provide a “chain” of intermediate certificates that give the connecting browser or client enough information to connect the certificate to a trusted root certificate.
Failing to provide intermediates could prevent various browsers and clients from successfully connecting to your service, especially mobile browsers and non-browser clients (such as cURL, and tools based on libcurl).
Some browsers will cache intermediates from a previous connection or attempt to automatically download missing intermediates that are presented in a certificate’s Authority Information Access extension, and so it can be easy to miss this problem during initial configuration. Though most browsers have an option to inspect the certificates on a site, they vary in whether they show the exact certificates the server presented or a chain as reconstructed through the fetching of an intermediate listed in the AIA extension.
In general:
- You do not need to serve the trusted root that the certificate chains to. The client will compare the chain to a local root store, so serving the root will only waste bytes and slow the connection.
- You do need to serve any intermediate certificates that connect your web server certificate to the trusted root. Doing so removes the potential for problems caused by the variation in how clients facilitate trust verification.
Web servers vary in how they are configured to serve intermediates, but it should generally be straightforward.
- What’s My Chain Cert? can help determine if any intermediate certificates are not being served.
