The HTTPS-Only Standard

Technical Guidelines

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


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 employ 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.


There are a number of ciphers available to a TLS connection, and one of those is RC4 (also known as ARC4 or ARCFOUR). RC4 was a popular cipher due to being a fast cipher which was not vulnerable to the BEAST attack. However, in 2013 it was announced that RC4 had a serious flaw that would make it possible for a determined attacker to decrypt data encrypted with RC4 in TLS.

Due to the serious flaw in RC4, and the fact that the BEAST attack has been mitigated by all modern browsers, modern browsers no longer support RC4-based ciphersuites. Therefore all HTTPS sites need to be configured to use ciphers other than 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.