Bamboozling Certificate Authorities With

Total Page:16

File Type:pdf, Size:1020Kb

Bamboozling Certificate Authorities With Bamboozling Certificate Authorities with BGP Henry Birge-Lee Yixin Sun Anne Edmundson Princeton University Princeton University Princeton University Jennifer Rexford Prateek Mittal Princeton University Princeton University Abstract cates for domains they do not control. Domain control verification is performed through a standardized set of The Public Key Infrastructure (PKI) protects users from methods including http-based and email-based verifica- malicious man-in-the-middle attacks by having trusted tion [18]. Certificate Authorities (CAs) vouch for the domain Recently, researchers have exposed several flaws names of servers on the Internet through digitally signed in existing domain control verification mechanisms. certificates. Ironically, the mechanism CAs use to issue WoSign was found issuing certificates to users that could certificates is itself vulnerable to man-in-the-middle at- demonstrate control of any TCP port at a domain (in- tacks by network-level adversaries. Autonomous Sys- cluding those above 50,000) as opposed to strictly requir- tems (ASes) can exploit vulnerabilities in the Border ing control of traditional mail, HTTP, and TLS ports [3]. Gateway Protocol (BGP) to hijack traffic destined to a In addition, researchers have found instances of CAs victim’s domain. In this paper, we rigorously analyze sending domain control verification requests to email ad- attacks that an adversary can use to obtain a bogus cer- dresses that belong to ordinary users at a domain as op- tificate. We perform the first real-world demonstration posed to bona fide administrators [1]. In response, coun- of BGP attacks to obtain bogus certificates from top CAs termeasures are being developed such as standardizing in an ethical manner. To assess the vulnerability of the which URLs on a domain’s web server can serve to ver- PKI, we collect a dataset of 1.8 million certificates and ify control of that domain [11]. find that an adversary would be capable of gaining a bo- While these advances can defend against some attacks, gus certificate for the vast majority of domains. Finally, none of them help to secure domain control verification we propose and evaluate two countermeasures to secure against network-level adversaries, i.e., Autonomous Sys- the PKI: 1) CAs verifying domains from multiple van- tem (AS), that can manipulate the Border Gateway Pro- tage points to make it harder to launch a successful at- tocol (BGP). Such adversaries can launch active BGP hi- tack, and 2) a BGP monitoring system for CAs to detect jack and interception attacks to steal traffic away from suspicious BGP routes and delay certificate issuance to victims or CAs, and spoof the domain control verifica- give network operators time to react to BGP attacks. tion process to obtain bogus certificates. In this paper, we first analyze and compare BGP at- 1 Introduction tacks on the domain verification process to develop a tax- onomy and present a highly effective use of the “AS-path Digital certificates serve as the foundation of trust in en- poisoning” attack originally performed in [39]. Next, we crypted communication. When a Certificate Authority launch all the BGP attacks against our own domain and (CA) is asked to sign a certificate, the CA must estab- decrypt seemingly “secure” HTTPS traffic within sec- lish that the client requesting the certificate is the legit- onds. To avoid harming real users, these attacks were imate owner of the domain name in question. An ad- done in an ethical manner on domains that resolve into versary that obtains a trusted certificate can pose as the our own IP prefix and were registered solely for the pur- victim’s domain and intercept/modify sensitive HTTPS pose of the experiments. We then quantify the vulner- traffic like bank logins and credit card information [24]. ability of domain verification to these attacks. Finally, The mechanism used by CAs to verify domain owner- we propose countermeasures against these attacks. Our ship, known as domain control verification, is critical main contributions are as follows: to preventing adversaries from obtaining trusted certifi- Active BGP Attacks on Domain Verification Pro- cess: We performed five types of real-world BGP attacks 2 BGP Attacks on the PKI (against a domain we owned running on an IP prefix we controlled) during the domain verification process: The Public Key Infrastructure (PKI) requires that all cer- 1) a traditional BGP sub-prefix attack, 2) a traditional tificates be signed by a trusted certificate authority (CA). BGP equally-specific-prefix attack (like the attack theo- Browsers and any other TLS clients maintain lists of pub- rized in [22]), 3) a prepended BGP sub-prefix attack, 4) licly trusted CAs. 135 organizations were recognized as a prepended BGP equally-specific-prefix attack, and 5) commercial CAs (other CAs, such as the government of a BGP AS-path poisoning attack (see section 2.2 for de- France, will not accept certificate signing requests from tails about these attacks). the general public) [20]. Any CA is capable of signing a We are the first to demonstrate the use of the certificate for any domain. prepended and AS-path poisoning attacks on the PKI, Domain Control Verification. In order to verify that and the first to perform any of these attacks during the an applicant requesting a certificate has control of the do- domain verification process in the wild. We successfully main in question, the CA must perform domain control obtained bogus certificates from all of the top five CAs verification through a set of methods. Each method boot- (Let’s Encrypt, GoDaddy, Comodo, Symantec, Global- straps trust by forcing a user to demonstrate control of an Sign) [8] in our real-world attacks. Our results were a important network resource (e.g., a website or email ad- major factor in Let’s Encrypt’s decision to start deploy- dress) associated with the domain. Figure 1 illustrates ing the multiple-vantage-point countermeasure [37]. the domain control verification process with HTTP veri- Quantify vulnerability of domains: We collected a fication, which requires the user to make an agreed upon dataset of 1.8 million certificates from Google’s Certifi- change to the root directory of the website running at the cate Transparency project logs [32] and studied the do- domain. Another commonly used method is email veri- mains requesting those certificates. By observing the fication, by which an email is sent to an administrator’s number of domains run out of IP prefixes shorter than 24 email address at the domain, requiring the administrator bits long (/24), we found that 72% of the domains were to visit a randomly generated URL before continuing. vulnerable to BGP sub-prefix hijack attacks and BGP Other methods include DNS TXT verification or meth- AS-path poisoning attacks, which could allow any AS ods that do not rely on communication via the Internet to get a certificate for these domains. Furthermore, the (e.g., official letters of authorization). domains were vulnerable to BGP equally-specific-prefix attacks from an average of 70% of ASes. Countermeasures against BGP attacks: We pro- posed and developed two countermeasures to mitigate the threat of BGP attacks: multiple vantage point veri- fication and a live BGP monitoring system. • Multiple Vantage Point Verification: We propose to perform domain control verification from multi- ple locations on the Internet (vantage points) to pre- vent localized BGP attacks. We calculate the best locations for vantage points and quantify the result- ing security benefit. • Live BGP Monitoring System: We design and im- plement (in the Let’s Encrypt’s CA) a monitoring system with a novel route age heuristic to prevent Figure 1: HTTP domain control verification. short-lived BGP attacks [19] that can quickly lead to a bogus certificate before the attack is noticed. BGP Attacks on Domain Control Verification. The Our heuristic is designed for CAs and forces adver- domain control verification process creates a vulnerabil- saries to keep attacks active for several hours, giving ity to network-level adversaries who can fake control of network operators time to react. the network resources in step (5) and (6) in Figure 1. An Some of the BGP attacks were briefly discussed in a adversary can send a certificate signing request for a vic- short abstract [16]. In this paper, we go further by an- tim’s domain to a CA. When the CA verifies the network alyzing the complete attack surface of BGP attacks on resources via an HTTP GET request in step (5), the ad- PKI and performing all the attacks in the wild — with versary can use BGP attacks to hijack/intercept the traffic success. We also measure the vulnerability of the current to the victim’s domain such that the CA’s request will be PKI to these attacks, and propose/evaluate two effective routed to the adversary instead. The adversary can then countermeasures to defend against the attacks. answer the CA’s HTTP request in step (6) and present the document required for domain control verification. IP address of the victim’s domain, or the IP address of Our key contribution in this section is to explore the any DNS server involved in resolving the victim’s do- broad BGP attack surface that can be used to obtain a main to give a bogus DNS response to the CA. This will bogus TLS certificate in the above process. We first de- cause the CA to request the verification webpage from velop an adversary model, and then explore five types the adversary as opposed to the victim. of BGP attacks. In particular, we propose and analyze an In addition, it is possible for the adversary to attack advanced and stealthy AS-path poisoning attack, that can a CA’s IP address.
Recommended publications
  • Securing Interdomain Network Routing with Resource Public Key Infrastructure (RPKI)
    Securing Interdomain Network Routing with Resource Public Key Infrastructure (RPKI) A Technical Paper prepared for SCTE•ISBE by Mark Goodwin IP Design Engineer Cox Communications, Inc 6305-B Peachtree Dunwoody Rd, Atlanta, GA 30328 404-269-8267 [email protected] © 2019 SCTE•ISBE and NCTA. All rights reserved. Table of Contents Title Page Number Table of Contents .................................................................................................................................... 2 1. Introduction .................................................................................................................................... 4 2. Motivations .................................................................................................................................... 4 2.1. BGP Security Analysis ....................................................................................................... 4 3. RPKI Components ......................................................................................................................... 6 3.1. Certificate Authority (CA) ................................................................................................... 7 3.2. Resource Certificate .......................................................................................................... 7 3.3. Route Origin Authorizations (ROAs)................................................................................... 8 3.4. RPKI Validating Cache .....................................................................................................
    [Show full text]
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • Bambauer-Macro-V2-Nov 28.Docx (Do Not Delete) 12/12/14 6:26 Pm
    BAMBAUER-MACRO-V2-NOV 28.DOCX (DO NOT DELETE) 12/12/14 6:26 PM FOXES AND HEDGEHOGS IN TRANSITION DEREK E. BAMBAUER* INTRODUCTION .......................................................................................... 1 I. A FLATTER NETWORK ........................................................................... 2 II. UNIVERSAL SERVICE? .......................................................................... 7 III. THE CAST OF CHARACTERS .............................................................. 10 CONCLUSION ........................................................................................... 16 INTRODUCTION The migration from a congeries of communications protocols and technologies to an Internet Protocol-based system is an architectural shift of profound magnitude: it is as though people returned to the city of Babel, abandoning their native tongues for a single lingua franca. Perhaps, after this shift, nothing will be restrained from those who use the Internet.1 And yet, there will inevitably be problems that arise from the shift. Scholars and activists have already raised concerns about equal access to communications capabilities; about the security and resiliency of the new architecture; and about the tension between competing speech interests on the network. One way of thinking about these problems, and potential solutions, is to classify them as either hedgehogs or foxes. The British philosopher Isaiah Berlin suggested that intellectuals can be classified into these two camps, puckishly borrowing from the Greek
    [Show full text]
  • Overview of Routing Security Landscape for the Quilt Member Meeting, Winter 2019 Mark Beadles, CISO, Oarnet [email protected] BGP IDLE
    Overview of Routing Security Landscape for the Quilt Member Meeting, Winter 2019 Mark Beadles, CISO, OARnet [email protected] BGP IDLE CONNECT ACTIVE OPEN OPEN SENT CONFIRM ESTAB- LISHED 2/13/2019 Routing Security Landscape - The Quilt 2 Overview of Routing Security Landscape • Background • Threat environment • Current best practices • Gaps 2/13/2019 Routing Security Landscape - The Quilt 3 Background - Definitions • BGP • Border Gateway Protocol, an exterior path-vector gateway routing protocol • Autonomous System & Autonomous System Numbers • Collection of IP routing prefixes under control of a network operator on behalf of a single administrative domain that presents a defined routing policy to the Internet • Assigned number for each AS e.g. AS600 2/13/2019 Routing Security Landscape - The Quilt 4 Background - The BGP Security Problem By design, routers running BGP accept advertised routes from other BGP routers by default. (BGP was written under the assumption that no one would lie about the routes, so there’s no process for verifying the published announcements.) This allows for automatic and decentralized routing of traffic across the Internet, but it also leaves the Internet potentially vulnerable to accidental or malicious disruption, known as BGP hijacking. Due to the extent to which BGP is embedded in the core systems of the Internet, and the number of different networks operated by many different organizations which collectively make up the Internet, correcting this vulnerabilityis a technically and economically challenging problem. 2/13/2019 Routing Security Landscape - The Quilt 5 Background – BGP Terminology • Bogons • Objects (addresses/prefixes/ASNs) that don't belong on the internet • Spoofing • Lying about your address.
    [Show full text]
  • Analysis of SSL Certificate Reissues and Revocations in the Wake
    Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed Liang Zhang David Choffnes Dave Levin Tudor Dumitra¸s Northeastern University Northeastern University University of Maryland University of Maryland [email protected] [email protected] [email protected] [email protected] Alan Mislove Aaron Schulman Christo Wilson Northeastern University Stanford University Northeastern University [email protected] [email protected] [email protected] ABSTRACT Categories and Subject Descriptors Central to the secure operation of a public key infrastruc- C.2.2 [Computer-Communication Networks]: Net- ture (PKI) is the ability to revoke certificates. While much work Protocols; C.2.3 [Computer-Communication Net- of users' security rests on this process taking place quickly, works]: Network Operations; E.3 [Data Encryption]: in practice, revocation typically requires a human to decide Public Key Cryptosystems, Standards to reissue a new certificate and revoke the old one. Thus, having a proper understanding of how often systems admin- istrators reissue and revoke certificates is crucial to under- Keywords standing the integrity of a PKI. Unfortunately, this is typi- Heartbleed; SSL; TLS; HTTPS; X.509; Certificates; Reissue; cally difficult to measure: while it is relatively easy to deter- Revocation; Extended validation mine when a certificate is revoked, it is difficult to determine whether and when an administrator should have revoked. In this paper, we use a recent widespread security vul- 1. INTRODUCTION nerability as a natural experiment. Publicly announced in Secure Sockets Layer (SSL) and Transport Layer Secu- April 2014, the Heartbleed OpenSSL bug, potentially (and rity (TLS)1 are the de-facto standards for securing Internet undetectably) revealed servers' private keys.
    [Show full text]
  • High Volume of European Network Traffic Re-Routed Through China
    Memo 11/06/2019 - TLP:WHITE High volume of European network traffic re-routed through China Telecom Reference: Memo [190611-1] Date: 11/06/2019 - Version: 1.0 Keywords: BGP, digital infrastructure, China Sources: publicly available information Key Points A routing incident led to 70 000 routes used for European traffic being redirected through China Telecom for over 2 hours. Border Gateway Protocol (BGP) errors are a relatively common issue but usually last just a few minutes. China Telecom has still not implemented some basic routing safeguards to detect and remediate them in a timely manner. Summary On June 6, a routing incident led to over 70 000 routes used for European mobile networks being redirected through China Telecom for over two hours. The incident began at 09:43 UTC when Swiss data centre colocation company Safe Host (AS21217) unintentionally leaked over 70 000 routes to China Telecom (AS4134) in Frankfurt, Germany. China Telecom then announced these routes on to the global internet redirecting large amounts of traffic destined for some of the largest European mobile networks through China Telecom’s network. Some of the most impacted European networks included Swisscom (AS3303) of Switzerland, KPN (AS1136) of Holland, Bouygues Telecom (AS5410) and Numericable-SFR (AS21502) of France. Often routing incidents only last for a few minutes, but in this case, many of the leaked routes were in circulation for over two hours. Comments China Telecom, a major international carrier, has still not implemented neither the basic routing safeguards necessary to prevent propagation of routing leaks nor the processes and procedures necessary to detect and remediate them in a timely manner when they inevitably occur.
    [Show full text]
  • Analysis of SSL Certificate Reissues And
    Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed Liang Zhang David Choffnes Dave Levin Tudor Dumitra¸s Northeastern University Northeastern University University of Maryland University of Maryland [email protected] [email protected] [email protected] [email protected] Alan Mislove Aaron Schulman Christo Wilson Northeastern University Stanford University Northeastern University [email protected] [email protected] [email protected] ABSTRACT Categories and Subject Descriptors Central to the secure operation of a public key infrastruc- C.2.2 [Computer-Communication Networks]: Net- ture (PKI) is the ability to revoke certificates. While much work Protocols; C.2.3 [Computer-Communication Net- of users' security rests on this process taking place quickly, works]: Network Operations; E.3 [Data Encryption]: in practice, revocation typically requires a human to decide Public Key Cryptosystems, Standards to reissue a new certificate and revoke the old one. Thus, having a proper understanding of how often systems admin- istrators reissue and revoke certificates is crucial to under- Keywords standing the integrity of a PKI. Unfortunately, this is typi- Heartbleed; SSL; TLS; HTTPS; X.509; Certificates; Reissue; cally difficult to measure: while it is relatively easy to deter- Revocation; Extended validation mine when a certificate is revoked, it is difficult to determine whether and when an administrator should have revoked. In this paper, we use a recent widespread security vul- 1. INTRODUCTION nerability as a natural experiment. Publicly announced in Secure Sockets Layer (SSL) and Transport Layer Secu- April 2014, the Heartbleed OpenSSL bug, potentially (and rity (TLS)1 are the de-facto standards for securing Internet undetectably) revealed servers' private keys.
    [Show full text]
  • Certificate Transparency Using Blockchain
    Certicate Transparency Using Blockchain D S V Madala1, Mahabir Prasad Jhanwar1, and Anupam Chattopadhyay2 1Department of Computer Science. Ashoka University, India 2School of Computer Science and Engineering. NTU, Singapore Abstract The security of web communication via the SSL/TLS protocols relies on safe distribu- tions of public keys associated with web domains in the form of X:509 certicates. Certicate authorities (CAs) are trusted third parties that issue these certicates. However, the CA ecosystem is fragile and prone to compromises. Starting with Google's Certicate Trans- parency project, a number of research works have recently looked at adding transparency for better CA accountability, eectively through public logs of all certicates issued by certica- tion authorities, to augment the current X:509 certicate validation process into SSL/TLS. In this paper, leveraging recent progress in blockchain technology, we propose a novel system, called CTB, that makes it impossible for a CA to issue a certicate for a domain without obtaining consent from the domain owner. We further make progress to equip CTB with certicate revocation mechanism. We implement CTB using IBM's Hyperledger Fabric blockchain platform. CTB's smart contract, written in Go, is provided for complete reference. 1 Introduction The overwhelming adoption of SSL/TLS (Secure Socket Layer/Transport Layer Security Proto- cols) [4, 33] for most HTTP trac has transformed the Internet into a communication platform with strong measures of condentiality and integrity. It is one
    [Show full text]
  • Public Key Distribution (And Certifications)
    Lecture 12 Public Key Distribution (and Certifications) (Chapter 15 in KPS) 1 A Typical KDC-based Key Distribution Scenario KDC = Key Distribution Center KDC EK[X] = Encryption of X with key K (1) Request|B|N1 (2) E [K |Request|N |E (K ,A)] Ka s 1 Kb s (3) E [K ,A] Kb s A (4) E [A,N ] Ks 2 B Notes: (5) E [f(N )] Ks 2 • Msg2 is tied to Msg1 • Msg2 is fresh/new • Msg3 is possibly old * • Msg1 is possibly old (KDC doesn’t authenticate Alice) • Bob authenticates Alice • Bob authenticates KDC 2 • Alice DOES NOT authenticate Bob Public Key Distribution • General Schemes: • Public announcement (e.g., in a newsgroup or email message) • Can be forged • Publicly available directory • Can be tampered with • Public-key certificates (PKCs) issued by trusted off-line Certification Authorities (CAs) 3 Certification Authorities • Certification Authority (CA): binds public key to a specific entity • Each entity (user, host, etc.) registers its public key with CA. • Bob provides “proof of identity” to CA. • CA creates certificate binding Bob to this public key. • Certificate containing Bob’s public key digitally signed by CA: CA says: “this is Bob’s public key” Bob’s digital PK public signature B key PK B certificate for Bob’s CA Bob’s private SK public key, signed by identifying key CA CA information 4 Certification Authority • When Alice wants to get Bob’s public key: • Get Bob’s certificate (from Bob or elsewhere) • Using CA’s public key verify the signature on Bob’s certificate • Check for expiration • Check for revocation (we’ll talk about this later) • Extract Bob’s public key Bob’s PK B digital Public signature Key PK B CA Public PK Key CA 5 A Certificate Contains • Serial number (unique to issuer) • Info about certificate owner, including algorithm and key value itself (not shown) • info about certificate issuer • valid dates • digital signature by issuer 6 Reflection Attack and a Fix • Original Protocol 1.
    [Show full text]
  • Certificate Transparency Description
    Certificate Transparency Description Certificate Transparency is an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. (q.v. IETF RFC 6962) The objectives are described as: Make it very difficult for a CA to issue a TLS certificate for a domain without the certificate being visible to the owner of that domain. Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued. Protect users from being duped by certificates that were mistakenly or maliciously issued. (q.v. https://www.certificate-transparency.org/what-is-ct) Note that end user TLS clients are not responsible for validating CT logs, all they need to do is enforce a requirement that certificates must have extensions that show that they were issued under these procedures by validating a Signed Certificate Timestamp (SCT) data object presented with the TLS server certificate. Monitors and Auditors have the primary responsibility of detecting anomalous certificates that were never submitted to the logs. According to wikipedia, the implementation status of the standard is as follows: Google launched its first certificate transparency log in March 2013.
    [Show full text]
  • Trust Me, I'm a Root CA! Analyzing SSL Root Cas in Modern Browsers
    Trust me, I’m a Root CA! Analyzing SSL Root CAs in modern Browsers and Operating Systems Tariq Fadai, Sebastian Schrittwieser Peter Kieseberg, Martin Mulazzani Josef Ressel Center for Unified Threat Intelligence SBA Research, on Targeted Attacks, Austria St. Poelten University of Applied Sciences, Austria Email: [pkieseberg,mmulazzani]@sba-research.org Email: [is101005,sebastian.schrittwieser]@fhstp.ac.at Abstract—The security and privacy of our online communi- tected communications is dependent on the trustworthiness cations heavily relies on the entity authentication mechanisms of various companies and governments. It is therefore of provided by SSL. Those mechanisms in turn heavily depend interest to find out which companies we implicitly trust just on the trustworthiness of a large number of companies and governmental institutions for attestation of the identity of SSL by using different operating system platforms or browsers. services providers. In order to offer a wide and unobstructed In this paper an analysis of the root certificates included in availability of SSL-enabled services and to remove the need various browsers and operating systems is introduced. Our to make a large amount of trust decisions from their users, main contributions are: operating systems and browser manufactures include lists of certification authorities which are trusted for SSL entity • We performed an in-depth analysis of Root Certifi- authentication by their products. This has the problematic cate Authorities in modern operating systems and web effect that users of such browsers and operating systems browsers implicitly trust those certification authorities with the privacy • We correlated them against a variety of trust indexes of their communications while they might not even realize it.
    [Show full text]
  • The Most Dangerous Code in the World: Validating SSL Certificates In
    The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software Martin Georgiev Subodh Iyengar Suman Jana The University of Texas Stanford University The University of Texas at Austin at Austin Rishita Anubhai Dan Boneh Vitaly Shmatikov Stanford University Stanford University The University of Texas at Austin ABSTRACT cations. The main purpose of SSL is to provide end-to-end security SSL (Secure Sockets Layer) is the de facto standard for secure In- against an active, man-in-the-middle attacker. Even if the network ternet communications. Security of SSL connections against an is completely compromised—DNS is poisoned, access points and active network attacker depends on correctly validating public-key routers are controlled by the adversary, etc.—SSL is intended to certificates presented when the connection is established. guarantee confidentiality, authenticity, and integrity for communi- We demonstrate that SSL certificate validation is completely bro- cations between the client and the server. Authenticating the server is a critical part of SSL connection es- ken in many security-critical applications and libraries. Vulnerable 1 software includes Amazon’s EC2 Java library and all cloud clients tablishment. This authentication takes place during the SSL hand- based on it; Amazon’s and PayPal’s merchant SDKs responsible shake, when the server presents its public-key certificate. In order for transmitting payment details from e-commerce sites to payment for the SSL connection to be secure, the client must carefully verify gateways; integrated shopping carts such as osCommerce, ZenCart, that the certificate has been issued by a valid certificate authority, Ubercart, and PrestaShop; AdMob code used by mobile websites; has not expired (or been revoked), the name(s) listed in the certifi- Chase mobile banking and several other Android apps and libraries; cate match(es) the name of the domain that the client is connecting Java Web-services middleware—including Apache Axis, Axis 2, to, and perform several other checks [14, 15].
    [Show full text]