Technical Guidelines

This page covers some relevant technical concepts relevant to the strength and quality of a server’s HTTPS configuration.

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:

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.

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.

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:

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:

Web servers vary in how they are configured to serve intermediates, but it should generally be straightforward.