The Transport Layer Security (TLS) protocol [tls12][tls13rev24] is one of the most important and widely used protocols to date. It is used to secure internet communications for billions of people everyday. TLS provides a secure communication channel between two communicating parties. At the beginning of each new TLS session, the client and server must agree on a single common TLS version and ciphersuite to be used in that session. These are extremely important parameters as they define the security guarantees that the protocol can provide in a particular session. TLS supports various protocol versions and ciphersuites. Each ciphersuite is a string that defines the cryptographic algorithms that will be used in a particular session. Generally, these algorithms include111TLS 1.2 and TLS 1.3 ciphersuite strings have different format and define different set of algorithms. See [tls12] and [tls13rev24] for more details.: the Key-Exchange, Digital Signature, Symmetric Encryption, Authenticated Encryption (AE), and Hash. Clients222In our paper, TLS clients are represented by web browsers. We will use the terms client, web browser, or browser interchangeably. and servers tend to support legacy versions, e.g. TLS 1.1 and TLS 1.0, and weak, less secure, or unrecommended ciphersuites, e.g. non-Forward Secrecy (non-FS), non-Authenticated Encryption (non-AE) 333 In our context, non-AE refers to ciphersuites that do not provide confidentiality, integrity, and authenticity simultaneously. For example the CBC MAC-then-encrypt ciphersuites which are susceptible to padding oracle attacks
In our context, non-AE refers to ciphersuites that do not provide confidentiality, integrity, and authenticity simultaneously. For example the CBC MAC-then-encrypt ciphersuites which are susceptible to padding oracle attacks[cloudflare16][vaudenay02]., or weak Hash algorithms, mainly to provide backward compatibility with legacy servers. For example, a recent analysis of IPv4 internet scan dataset shows that embedded web servers in networked devices tend to use legacy TLS versions compared to top domain web servers [samarasinghe17]. To accommodate such servers, web browsers tend to support legacy versions and weak ciphersuites to be able to connect to such legacy servers. The same goes for updated servers. They support legacy versions and weak ciphersuites so as not to lose connections from legacy clients.
In the near future, the coming version of TLS, TLS 1.3, which is currently work in progress [tls13rev24], will become a standard. Ideally, mainstream browsers444Throughout the paper, mainstream browsers refer to the following tested versions: Chrome version 63.0.3239.108, Firefox 57.0.2, Internet Explorer 11.125.16299.0, Edge 41.16299.15.0, and Opera 49.0.2725.64. will deploy it and offer it as the default version. TLS 1.3 provides significant improvements in security and performance over its predecessors. However, experience has shown that ordinary web servers may take years till they get upgraded to support the latest TLS version. This is especially true in embedded web servers as we mentioned earlier. For this reason, web browsers tend to maintain support for legacy TLS versions and weak ciphersuites and silently (without warning or indicator) fall back to them if the server they are trying to connect to does not support the latest version or the strongest ciphersuite. This is the case in all mainstream web browsers today. It is not inconceivable that this will remain the case after the deployment of the coming version, TLS 1.3, despite numerous known weaknesses including design flaws in the current version, TLS 1.2. For example, legacy versions up to TLS 1.2 do not authenticate the server's selected version and ciphersuite at early stage of the handshake. This flaw allows various attacks that result in breaking the protocol's main security guarantees as shown in [adrian15][beurdouche15], for example.
There are several TLS attacks that exploit the support for legacy versions or weak ciphersuites by one or both of the communicating parties during the TLS handshake. This family of attacks is known as downgrade attack, where an active network attacker forces the communicating parties to operate in a mode that is weaker than they would prefer and support, in order for him to perform attacks that would not have been possible in the strong mode. For example, [adrian15][aviram16][beurdouche15][beurdouche14][moller14], among others.
The tension between security and backward compatibility in cryptographic protocols is historical. Backward compatibility seems inevitable in internet protocols such as TLS due to the global and heterogeneous nature of the connected devices over the internet, in addition to the heavy reliance on the internet services in people's daily lives. From the client's perspective (which is our focus in this paper), if a browser is configured with optimal TLS configurations, i.e. it only negotiates the latest version of TLS, e.g. TLS 1.3, and a handful of the strongest ciphersuites that satisfy both FS and AE properties, this can be the strongest client but can render many ordinary websites on legacy servers unreachable due to compatibility issues. Obviously, this will lead to a difficult user experience. On the other hand, if the client supports legacy versions, e.g. TLS 1.0 and weak or non preferred ciphersuites, e.g. non-FS or non-AE as is the case in all mainstream web browsers today, the browser silently falls back to one of the legacy versions or weak ciphersuites to connect to those legacy servers that do not support the latest version or the strongest ciphersuites.
To maintain a balance between the two extremes, the browser needs to distinguish between various contexts and apply fine-grained TLS configurations. That is, the browser enforces optimal configurations for connections going to sensitive domains, and default ones for the rest of the connections.
To this end, we try to answer the following question: How can we guide the browser into making an informed decision on whether to enforce optimal or default TLS configurations?
Our contribution is twofold: First, we propose a light-weight mechanism for fine-grained TLS security configurations in web browsers. Our mechanism allows browsers to enforce optimal TLS security configurations for connections going to sensitive domains while maintaining default configurations for the rest of the connections. It represents a middle-ground between optimal TLS configurations that might render many ordinary websites unreachable and default configurations that might be abused by attackers to perform downgrade attacks. Our mechanism can detect and prevent a class of dangerous downgrade attacks and server misconfigurations. Furthermore, it does not require a new Public Key Infrastructure (PKI) nor third parties such as Certificate Authorities (CAs). Second, we examine the feasibility of our mechanism by implementing a proof-of-concept as a Firefox browser extension. In addition, we present the extension architecture.
The rest of the paper is organised as follows: In section 2 we provide a brief background. In section LABEL:related_work we summarise some related work. In section LABEL:threat_model we describe our system and threat models, and goals. In section LABEL:proposal we present our proposed mechanism. In section LABEL:other_methods we briefly describe some other server-based TLS configurations advertisement methods. In section LABEL:limitations we list some limitations. Finally, in section LABEL:conclusion we conclude.
2.1 TLS Version and Ciphersuite Negotiation
We now briefly describe the version and ciphersuite negotiation in both TLS 1.2 [tls12] and TLS 1.3 (draft-24) [tls13rev24]. We base our description on the current version, TLS 1.2, and if there is any difference in TLS 1.3 we mention it explicitly. As depicted in Figure 1, at the beginning of a new TLS handshake the client (Initiator I) must send a ClientHello (CH) message to initiate a connection with the server (Responder R). The ClientHello contains several parameters including: First, the client's TLS supported versions which is sent as a single value that represents the maximum supported version () while in TLS 1.3, it is sent as a list of supported versions () in the “supportedversions” extension. The is still included in TLS 1.3 ClientHello for backward compatibility and its value is set to TLS 1.2. Second, a list of supported ciphersuites (). Third, a list of the client's supported extensions ([,…,]) is sent at the end of the message. In TLS 1.3 the extensions must at least include the “supportedversions” , while in TLS 1.2, the extensions are optional.
Upon receiving a ClientHello, the server decides which version and ciphersuite will be used in the session and responds with a ServerHello (SH). The ServerHello contains several parameters including: First, the server's selected TLS version () based on the client's supported versions. Second, the selected ciphersuite () based on the client's proposed list. If the server does not support any of the client's proposed versions or ciphersuites, it responds with a handshake failure alert. However, if the server selected a version lower than the client's maximum version, all mainstream web browsers today fall back silently to a lower version (up to TLS 1.0).
2.2 TLS Downgrade Attack
In recent years, several downgrade attacks have been shown practical. For example, the version downgrade in the Padding Oracle On Downgraded Legacy Encryption (POODLE) attack [moller14], the “Version rollback by ClientHello fragmentation” [beurdouche14], and the ciphersuite downgrade (from RSA to non-RSA) in a variant of the DROWN attack [aviram16].
The aforementioned attacks share a pattern: First, the client supports either a legacy version (SSL 3.0 or TLS 1.0) or non preferred or weak ciphersuite (RSA) and silently falls back to them. Second, the attacks circumvent the handshake transcript authentication mechanism (in the Finished MACs) that is placed to detect any modifications in the protocol messages (including the version or ciphersuite). Clearly, these attacks could have been prevented if the client does not support legacy versions or weak ciphersuites. In these cases, the client will refuse to proceed the handshake with a version or ciphersuite that it does not support, as illustrated in Figure LABEL:fig:version_rollback_protection. One might argue that this is what all browsers should do: disable all legacy versions and unrecommended ciphersuites that provide fewer security guarantees (e.g. non-FS) and never accept them from any server. Experience shows that disabling legacy versions and exclusively offering the strongest ciphersuites is a complex decision for browser vendors. Browser vendors scarifies optimal TLS security configurations to some degree to provide backward compatibility for their users who might need to connect to legacy servers as we mentioned earlier. However, in this paper, we do not argue for or against. Rather, we explore the solutions space to augment browsers security while maintaining usability and backward compatibility. Our mechanism augments browsers security for connections to sensitive domains that are capable of providing optimal TLS configurations (but also support legacy configurations for legacy clients) by providing the browser with prior knowledge about these sensitive domains. This is an improvement over the “one-size-fits-all” TLS security policy in all mainstream web browsers which renders some downgrade attacks undetected.