The Security Impact of HTTPS Interception

Abstract

As HTTPS deployment grows, middlebox and antivirus products are increasingly intercepting TLS connections to retain visibility into network traffic. In this work, we present a comprehensive study on the prevalence and impact of HTTPS interception. First, we show that web servers can detect interception by identifying a mismatch between the HTTP User-Agent header and TLS client behavior. We characterize the TLS handshakes of major browsers and popular interception products, which we use to build a set of heuristics to detect interception and identify the responsible product. We deploy these heuristics at three large network providers: (1) Mozilla Firefox update servers, (2) a set of popular e-commerce sites, and (3) the Cloudflare content distribution network. We find more than an order of magnitude more interception than previously estimated and with dramatic impact on connection security. To understand why security suffers, we investigate popular middleboxes and clientside security software, finding that nearly all reduce connection security and many introduce severe vulnerabilities. Drawing on our measurements, we conclude with a discussion on recent proposals to safely monitor HTTPS and recommendations for the security community. Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author's employer if the paper was prepared within the scope of employment.

Client-Focused Security Assessment of mHealth Apps and Recommended Practices to Prevent or Mitigate Transport Security Issues

“…As soon as an app trusts such a rogue certificate, the owner of the rogue certificate can issue valid certificates for any domain visited by the device and can, therefore, pretend to be any server [21]. This enables an attacker to act as a middle man (man-in-the-middle [MitM]) between the client and the server, leading to undermined integrity of server responses and loss of privacy between the client (and thus the user of an app) and the server [40]. In Android version <7, the user can install such a certificate himself.…”

Where the Wild Warnings Are

“…• When a locally installed root of trust is in use, Chrome disables various certificate validation and TLS security checks that cannot reasonably be enforced for local roots, such as HTTP Public Key Pinning [7]. Most proxies do not implement these checks themselves, and in many cases do not perform even basic certificate validation, leaving the user vulnerable to attack [13,24].…”

A Formal Treatment of Accountable Proxying Over TLS

“…Worryingly, recent studies of such proxies uncovered a plethora of serious security issues, from inappropriate or inexistent certification validation and ciphersuite downgrades, to the execution of completely invalid TLS handshakes [15], [34]. A typical example of what can go wrong is the Superfish scandal of 2015 [18] where the private key of the CA certificate used by a client-side proxy was leaked, allowing attackers to impersonate any website to any client who used the proxy.…”