Does "www." Mean Better Transport Layer Security?

TL;DR

This study analyzes nearly two million domain pairs to determine if plain-domains and their www counterparts differ in TLS security, revealing that www-domains generally have stronger security and that redirection practices can introduce security vulnerabilities.

Contribution

The paper provides the first large-scale analysis showing that plain-domains often have weaker TLS security than their www counterparts, highlighting security implications of redirection practices.

Findings

www-domains tend to have stronger TLS configurations than plain-domains.

Over 53% of weak plain-domains redirect to stronger www-domains via HTTPS.

Redirections often involve plain-text HTTP URLs, creating potential security risks.

Abstract

Experience shows that most researchers and developers tend to treat plain-domains (those that are not prefixed with "www" sub-domains, e.g. "example.com") as synonyms for their equivalent www-domains (those that are prefixed with "www" sub-domains, e.g. "www.example.com"). In this paper, we analyse datasets of nearly two million plain-domains against their equivalent www-domains to answer the following question: Do plain-domains and their equivalent www-domains differ in TLS security configurations and certificates? If so, to what extent? Our results provide evidence of an interesting phenomenon: plain-domains and their equivalent www-domains differ in TLS security configurations and certificates in a non-trivial number of cases. Furthermore, www-domains tend to have stronger security configurations than their equivalent plain-domains. Interestingly, this phenomenon is more prevalent in the most-visited domains than in randomly-chosen domains. Further analysis of the top domains dataset shows that 53.35% of the plain-domains that show one or more weakness indicators (e.g. expired certificate) that are not shown in their equivalent www-domains perform HTTPS redirection from HTTPS plain-domains to their equivalent HTTPS www-domains. Additionally, 24.71% of these redirections contains plain-text HTTP intermediate URLs. In these cases, users see the final www-domains with strong TLS configurations and certificates, but in fact, the HTTPS request has passed through plain-domains that have less secure TLS configurations and certificates. Clearly, such a set-up introduces a weak link in the security of the overall interaction.

Full text

††journalyear: 2019††copyright: acmcopyright††conference: Proceedings of the 14th International Conference on Availability, Reliability and Security (ARES 2019); August 26–29, 2019; Canterbury, United Kingdom††booktitle: Proceedings of the 14th International Conference on Availability, Reliability and Security (ARES 2019) (ARES ’19), August 26–29, 2019, Canterbury, United Kingdom††price: 15.00††doi: 10.1145/3339252.3339277††isbn: 978-1-4503-7164-3/19/08

1. Introduction

The “www.” (world-wide web) prefix has become a de facto standard for domains running websites. Plain-domains (those without the “www.” prefix, e.g. “example.com”) are usually treated as synonyms for their equivalent www-domains (those that are prefixed with “www.”, e.g. “www.example.com”).

As a concrete example, from an application development perspective, recently, in August 2018, Google’s Chrome111As a shorthand, we use the term Chrome for the rest of the paper to refer to Google’s Chrome. version 69.0.3497.81 decided to hide the “www” and “m” (“m” for mobile) sub-domains from the steady-state URL in Chrome’s address bar by default (, ). Google describes these sub-domains as “trivial” in Chrome’s custom settings, where users can enable displaying these sub-domains through the following URI: “chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-sub-domains”. This change by Google has received criticism and media attention from the security community, as shown in (, )(, )(, ). One of the reasons for not welcoming this change is that it can cause confusion (, ). For example, two addresses, one with a “www” sub-domain and another without a “www” sub-domain can point to completely different websites (, ). One user reported Chrome’s new behaviour of hiding the “www” and “m” sub-domains as a bug (, ). In the same report (, ), another user has pointed out that the Safari mobile browser also hides the “www” sub-domains from its address bar (, ). Subsequently, other users have reported that the Google search engine sometimes hides the “www” sub-domains in search results and uses plain-domains format (, ). However, we are unable to reproduce the issue (bug) reported in (, ) regarding Chrome’s new behaviour since Chrome does not provide an archive for old versions. Nevertheless, the reported bug includes several confirming responses (, ), in addition to media reports, such as (, )(, )(, ), which provide sufficient evidence that the issue has existed in that particular version, either in the desktop, or the mobile version, or both. Our test of Chrome’s latest version shows that subsequent versions (as of March 2019, version 73.0.3683.86) have reverted this change from a default to a custom setting.

From a research perspective, in particular, on Internet measurement studies which are concerned with examining domains’ TLS security configurations and certificates, we observe different treatments for the examined domain names. A considerable number of these studies make use of the Alexa top domains list (, ). Alexa represents domains as plain-domains, except for a small percentage222This percentage is around 4.99% in our Alexa dataset. of domains that include sub-domains including “www” sub-domains. Some studies, such as (, ), add the “www” sub-domains to the examined domains, and report the results based on TLS handshakes with www-domains. Other studies, such as (, ), first try to establish a TLS handshake with the examined domain “as is”, and if the handshake with the domain “as is” has failed, they make a second handshake with the domain’s equivalent www-domain, and report the results. The third line of Internet measurement studies such as (, )(, ), do not mention adding any “www” sub-domains to the examined domains, hence, we assume that they treat the list’s domains (e.g. the Alexa list in these studies) “as is”. However, it remains unclear whether plain-domains differ from their equivalent www-domains in terms of TLS configurations and certificates? If one type of domains, e.g. www-domains, provides better TLS security configurations than their equivalent plain-domains, or vice versa, to what extent does taking one approach over another affect the overall results? In particular, regarding the domains’ adoption of TLS security configurations, e.g. protocol versions, or the domains’ certificates status results.

In this paper, we try to answer the following question: Do plain-domains and their equivalent www-domains differ in TLS security configurations and certificates? If so, to what extent?

2. Background

The Transport Layer Security (TLS) protocol (, )(, ), formerly known as Secure Socket Layer (SSL), is one of the most important and widely used security protocols to date. The latest version of TLS is known as TLS 1.3 (, ). We refer to versions prior to TLS 1.3 (in particular, TLS 1.2, TLS 1.1, and TLS 1.0) as pre-TLS 1.3. TLS operates below application layer protocols, to provide data confidentiality, integrity, and authentication. TLS consists of multiple sub-protocols, including the handshake protocol. In the handshake protocol, both communicating parties authenticate each other, and negotiate security-sensitive parameters, including the protocol version and the ciphersuite, that will be used to secure subsequent messages of the protocol. The ciphersuite is an identifier, represented by a string or a hexadecimal value, which defines the cryptographic algorithms (e.g. symmetric encryption algorithm) and their parameters (e.g. key length) that will be used in subsequent messages of the protocol. In pre-TLS 1.3 versions, the ciphersuite defines the key-exchange, authentication, symmetric encryption, and hash algorithms. However, in TLS 1.3, the key-exchange is separated from the ciphersuites, and it is now negotiated in specific extensions.

The version and ciphersuite choices are intrinsic in determining the security guarantees that the protocol can provide in a particular session. Some ciphersuites provide stronger security guarantees than others. For example, Forward Secrecy (FS) guarantees that a compromise in a server’s long-term private-key does not compromise past session keys (, ). Similarly, Authenticated Encryption (AE) provides confidentiality, integrity, and authenticity, simultaneously, which provides stronger resilience against attacks over the MAC-then-encrypt schemes (, )(, ). The same applies to the protocol version. Each version of the protocol prevents attacks discovered in previous versions, and provides more security guarantees. For example, TLS 1.3 enforces FS key-exchange algorithms and AE ciphersuites (FS+AE) by design. TLS 1.2 supports AE in addition to FS but both are optional, while TLS 1.1 and TLS 1.0 do not support AE ciphersuites.

As depicted in section 2, at the beginning of a new TLS handshake, the client sends a ClientHello (CH) message to the server. The CH contains several security-sensitive parameters, including: first, the client’s supported versions. In pre-TLS 1.3, this parameter is sent as a single value $v_{\mathit{max}_{C}}$. In TLS 1.3, it is sent as a list [$v_{1},...,v_{n}$] in the “supported_versions” extension. The $v_{\mathit{max}_{C}}$ is still included in TLS 1.3 CH for backward compatibility, and its value is set to TLS 1.2. Second, the client’s supported ciphersuites is sent as a list [$a_{1},...,a_{n}$]. Third, the client’s supported extensions as a list [$e_{1},...,e_{n}$] at the end of the message. In TLS 1.3, the extensions must at least include the “supported_versions”, while in TLS 1.2, the extensions are optional. Upon receiving the CH, the server selects a single mutually supported version $v_{S}$ and ciphersuite $a_{S}$ from the client’s offer. The server then responds with a ServerHello (SH) containing $v_{S}$ and $a_{S}$. The server’s selection of $v_{S}$ and $a_{S}$ is imposed on the client. That is, the server’s decision on the version and ciphersuite is the final one. If the server does not support the client’s offered versions or ciphersuites, the server responds with a handshake failure alert.