Killed by Proxy: Analyzing Client-end TLS Interception Software [1]
Summarized by Mohammad Mannan
To filter SSL-protected traffic, some antivirus and parental-control applications interpose a SSL proxy in the middle of the host’s communications. However, the use of such a proxy may weaken TLS security in several ways, including:
1.If the proxy’s root certificate is pre-generated (i.e., fixed across different installations), users could be vulnerable to impersonation by an active MITM network adversary, having access to the signing key, if the proxy accepts external site certificates issued by its own root certificate. For example, in Feb. 2015, the advertisement-inserting tool SuperFish [2] was found to be vulnerable to such an attack due to its use of the Komodia SDK, which pre-generates a single root certificate per product.
2.As the TLS proxy itself connects to the server, it is in charge of the certificate validation process, which may be vulnerable to several known problems, including: accepting any certificate (cf. Privdog [3]), failing to verify the certificate chain, relying on an outdated list of trusted CAs, or failing to check revocation status. Brubaker et al. [4] show that certificate validation is a particularly error-prone task, even for well-known and tested TLS libraries and clients.
3.The proxy may use an outdated SSL library and reintroduce security issues that are potentially fixed in the original client, e.g., FREAK, reverse Heartbleed, certificate parsing errors (CVE-2015-0287).
4.The lack of transparency between versions and ciphersuites negotiated with the server, which may force a client to accept otherwise unacceptable parameters.
Covering existing and new attack vectors on SSL engines, we design a comprehensive framework to analyze such client-end TLS proxies. Challenges faced by our analysis include, but are not limited to:
1.the lack of Server Name Indication (SNI) support (requiring one IP address per test) and filtering on specific ports only, both of which limit the applicability of existing online TLS test-suites; and
2. difficulties to make a proxy trust our test root certificate due to the use of custom CA trusted stores (often encrypted/obfuscated in an undocumented manner).
We use our framework to analyze client proxies from four perspectives: (a) root certificates of proxies, and protections of corresponding private keys; (b) certificate validation; (c) server-end TLS parameters; and (d) client-end transparency. We perform a thorough analysis of eight antivirus (e.g., Kaspersky, ESET, etc.) and four parental-control applications (e.g., PC Pandora, etc.) that act as TLS proxies, along with two additional products that only import a root certificate; these products are possibly used by millions of users.
Our systematic analysis uncovered that some of these security enhancing tools severely affect SSL security on their host machines. We found that all the analyzed products in some way weaken TLS security on their host.
●Three of the four parental control applications we analyzed are vulnerable to server impersonation or MITM attacks because they either import a pre-generated certificate into the OS/browser trusted stores during installation, lack any certificate validation, or trust a root certificate “for testing purpose only” with a factorable 512-bit RSA key. The remaining one imports a pre-generated certificate when filtering is enabled for the first time, and never removes it even after uninstalling the product, leaving the host perpetually vulnerable.
●One antivirus did not validate any certificate in the first version we analyzed, then changed to prompting user for each and every certificate presented on email ports (secure POP3, IMAP and SMTP), leaving users unprotected or in charge of critical security decisions. Another antivirus fails to verify the certificate signatures, allowing a trivial MITM attack when filtering is enabled. A third antivirus leaves its host vulnerable to server impersonation under a trivial MITM attack after the product license is expired (accepts all certificates, valid or otherwise). Due to the expired license, this product also cannot be automatically updated to a newer version that fixes the vulnerability.
We have contacted all affected companies involving the products we analyzed. Most accepted our findings, and are fixing their products. A leading AV company has also implemented our recommendations on safer TLS interception [5]. As the most used interface to web, browser manufacturers in the recent years have taken a more pro-active role in improving online security than simply faithfully implementing the TLS specifications, e.g., deploying optional/experimental extensions to TLS, such as HSTS and key pinning; blocking malware and phishing sites; and restricting misbehaving CAs, such as CNNIC and TURKTRUST. We thus expect browser manufacturers to force companies behind the most offending products to fix obvious vulnerabilities, by blocking connections when a known, broken proxy is involved. There are possible research opportunities in this direction – e.g., analyzing other TLS implementations, and design better solutions.
参考文献：
[1] Xavier de Carné de Carnavalet and Mohammad Mannan. Killed by Proxy: Analyzing Client-end TLS Interception Software. In Network and Distributed System Security Symposium (NDSS 2016), San Diego, CA, USA, 2016. Internet Society.
[2] “Lenovo PCs ship with man-in-the-middle adware that breaks HTTPS connections,” news article (Feb. 19, 2015)
[3] ComputerWeekly.com, “PrivDog SSL compromise potentially worse than Superfish,” news article (Apr. 24, 2015).
[4] C. Brubaker, S. Jana, B. Ray, S. Khurshid, and V. Shmatikov, “Using frankencerts for automated adversarial testing of certificate validation in SSL/TLS implementations,” in IEEE S&P, 2014
[5] Avast blog, “Independent test shows Avast offers best HTTPS protection in the market”, https://blog.avast.com/independent-test-shows-avast-offers-best-https-protection-in-the-market (May 23, 2016).
作者简介：
Mohammad Mannan is an Associate Professor at the Concordia Institute for Information Systems Engineering, Concordia University, Montreal. He has a Ph.D. in Computer Science from Carleton University (2009) in the area of Internet authentication and usable security. He was a post-doctoral fellow at the University of Toronto from 2009 to 2011. His research interests lie in the area of Internet and systems security, with a focus on solving high-impact security and privacy problems of today’s Internet. He is involved in several well-known conferences (e.g., program committee: ACM CCS 2016, ACSAC 2014, USENIX Security 2010; program co-chair: ACM SPSM 2016), and journals (e.g., ACM TISSEC, IEEE TDSC, IEEE TIFS). His industrial R&D experience prior to graduate school included three years in large-scale software design.
Professor Mannan is looking for students with the following qualities. (1) Highly motivated to solve “difficult” security/privacy problems. (2) Strong academic background (e.g., good university with good GPA). (3) Strong systems knowledge and programming experience. (4) English proficiency.
