Talking with Familiar Strangers: An Empirical Study on HTTPS Context Confusion Attacks

Paper Info

• Paper Name: Talking with Familiar Strangers: An Empirical Study on HTTPS Context Confusion Attacks
• Conference CCS ‘20
• Author List: Mingming Zhang, Xiaofeng Zheng, Kaiwen Shen, Ziqiao Kong, Chaoyi Lu, Yu Wang, Haixin Duan, Shuang Hao, Baojun Liu, Min Yang
• Link to Paper: here
• Food: Hunger

It is broadly understood that mitigations such as HSTS and TLS certificate pinning reduce the risks of using the internet in the presence of attacker-controlled networks, but there are still mechanisms that can subvert the security of a user’s connection even if these techniques are in place. This paper explores a new class of attack on TLS, called Secure Context Confusion, or SCC for short, and evaluates its applicability on the open internet.

The Attack

SCC builds off the following facts:

1. It is common to have different hosts, virtual or physical, to service different domains of a website.
2. It is commmon for different domains for the same website to a) share TLS certificates and b) have different security properties.
3. It is common for different hosts for the same website to issue HTTP redirects to their corresponding domains when they receive HTTP requests with a Host header that does not match that domain.
4. Browsers do not notify users when redirecting between domains with different security properties.

With these facts in mind, the most basic version of the attack plays out like this:

1. A user securely initiates a request to a.z.com containing sensitive information.
2. The attacker, who controls the network but cannot break the encryption, rewrites the TCP metadata of the user’s packets to indicate that they are actually destined for w.z.com.
3. w.z.com, which shares a certificate with a.z.com, is misconfigured to redirect to http://w.z.com when it receives an inappropriate domain. It responds with a 301 or 302 redirect.
4. The browser re-sends the sensitive information in plaintext to w.z.com without any forewarning.

The fact that w.z.com redirects to pain HTTP is a stand-in for a more general category of “weakness” - any deficiency in the security of a domain which will redirect to itself and shares a certificate with another domain can be used to compromise the security of the stronger domain. For example, the weak domain can have a weaker HSTS or CSP header, or be vulnerable to downgrade attacks.

Some variants of the attack are as follows:

• Since servers can have multiple certificates, the weakness of a domain can simply be “is vulnerable to SCC with a different certificate”. This lets the attacker juggle the connection from domain to domain until it reaches one which is vulnerable to something else.
• If the attacker ever acquires full control over the connection, they can inject a redirect back to the original domain after they have extracted whatever information they want from the request. This completely obscures any indication to the user that something unintended happened to their request.
• In the same situation, the attacker can inject cookies which have a Path attribute. This causes the injected cookie to be sent by the browser in future requests matching that path. By making this cookie very large, it can be used to fingerprint which requests include this path without attacking their encryption.
• It is also possible, with some caveats about browser-specific behavior, to initiate this attack not at the beginning of a TLS connection but rather during a TLS re-handshake spawned by an injected TCP RST or timeout packet.

The obvious mitigation to this attack is for browsers to refuse to process redirects which change the security context of the connection. But barring this, developers should take care to secure all endpoints for their websites.

The Study

Research goals: figure out what the applicability of this attack is on the open internet. This is done with the following research methodology:

1. Determine related domains.
   • Given a list of domains, find domains that share TLS certificates with them (provided in CN and SAN fields of certificate).
   • The list of domains used in this study is the Alexa Top 500 apex domains.
2. Send HTTPs requests to domains, reroute to related domains.
   • Send HTTPs request for each domain to all related domains’ IP addresses.
3. Check if response indicates SCC vulnerability
   • HTTPS downgrade: related domain responds with HTTP redirect
   • HSTS bypass: Strict-Transport-Security with max-age=0, decreased max-age, or no includeSubdomains

“By analyzing the responses of HTTPS requests, we find 2,918 (8.50%) subdomains under 126 (25.2%) Alexa Top 500 apex domains are vulnerable to SCC attacks.”

Discussion

Generally, this paper presents an interesting and novel technique that opens up a lot of avenues for exploits and shifts the cultural perception of what can be possible in the realm of man in the middle attacks. It further shows the intertwined security relationship that browsers and web servers are in with their seemingly dozens of security-relevant headers and concepts that must be precisely configured to prevent the entire house of cards from collapsing. What a mess.

This paper could have been cleaned up a bit more by sticking to precisely describing and separating out the potential attacks, and directly tying back to and using these attacks as the focal point in describing the evaluation methodology.

More background on the underlying goals of HTTPs and how HSTS enables that would have been nice. Near the end, the paper states “As aforementioned in Section 4.1, clearing HSTS policy by setting max-age to zero is more dangerous than the other two scenarios.” But this in fact is not explicitly made clear as to why clearing HSTS is so critically dangerous compared to an HTTP redirect.