DOCSLIB.ORG

On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 V1.5 Encryption

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 V1.5 Encryption On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption Tibor Jager Jörg Schwenk Juraj Somorovsky Horst Görtz Institute Horst Görtz Institute Horst Görtz Institute Ruhr University Bochum Ruhr University Bochum Ruhr University Bochum [email protected] [email protected] [email protected] ABSTRACT Categories and Subject Descriptors Encrypted key transport with RSA-PKCS#1 v1.5 is the most com- C.2.2 [Computer-Communication Networks]: Network Proto- monly deployed key exchange method in all current versions of the cols; K.4.4 [Computers and Society]: Electronic Commerce – Transport Layer Security (TLS) protocol, including the most re- Security cent version 1.2. However, it has several well-known issues, most importantly that it does not provide forward secrecy, and that it is prone to side channel attacks that may enable an attacker to learn Keywords the session key used for a TLS session. A long history of attacks Cross-protocol attack; chosen-ciphertext attack; TLS shows that RSA-PKCS#1 v1.5 is extremely difficult to implement securely. The current draft of TLS version 1.3 dispenses with this encrypted key transport method. But is this sufficient to protect 1. INTRODUCTION against weaknesses in RSA-PKCS#1 v1.5? We describe attacks which transfer the potential weakness of TLS and PKCS#1 v1.5 encryption. Transport layer security (TLS) prior TLS versions to two recently proposed protocols that do not is the most important security protocol on the Internet. It is very even support PKCS#1 v1.5 encryption, namely Google’s QUIC pro- flexible, as it allows two communicating parties to negotiate the tocol and TLS 1.3. These attacks enable an attacker to impersonate cryptographic algorithms used for a TLS connection at the begin- a server by using a vulnerable TLS-RSA server implementation as ning of each session. For each new TLS session, the peers may a “signing oracle” to compute valid signatures for messages chosen choose from different selections of cryptographic algorithms for by the attacker. key establishment, symmetric encryption, and message authentica- The first attack (on TLS 1.3) requires a very fast “Bleichenbacher- tion. The current TLS version is 1.2 [12], it was published in 2008. oracle” to create the TLS CertificateVerify message before All current TLS versions include RSA-based PKCS#1 v1.5 en- the client drops the connection. Even though this limits the prac- cryption [24]. Even though this scheme has been updated [21, tical impact of this attack, it demonstrates that simply removing 19] and has been subject to many attacks [7, 22, 9, 18, 4, 28, a legacy algorithm from a standard is not necessarily sufficient to 36] (in TLS and other applications), it is the most commonly used protect against its weaknesses. method for TLS key establishment in practice. Moreover, the only The second attack on Google’s QUIC protocol is much more mandatory-to-implement cipher suite in TLS 1.2 is based on this practical. It can also be applied in settings where forging a sig- encryption scheme. nature with the help of a “Bleichenbacher-oracle” may take an ex- TLS 1.3. Version 1.3 of TLS is currently under development [13]. tremely long time. This is because signed values in QUIC are inde- It is the first version which dispenses with PKCS#1 v1.5 encryp- pendent of the client’s connection request. Therefore the attacker tion. There are several reasons for this, including the lack of for- is able to pre-compute the signature long before the client starts a ward secrecy, that the PremasterSecret of previous TLS ver- connection. This makes the attack practical. Moreover, the impact sions may depend only on client randomness, and that PKCS#1 on QUIC is much more dramatic, because creating a single forged v1.5 encryption has proven to be extremely difficult to implement signature is essentially equivalent to retrieving the long-term secret securely in TLS [7, 22, 4, 28]. key of the server. In this paper, we analyze the security of the current version of the TLS 1.3 draft against weaknesses in PKCS#1 v1.5 encryption. We show that even though this encryption scheme is not even used in TLS 1.3, the coexistence with older TLS versions may enable cross-protocol attacks [33, 26]. Permission to make digital or hard copies of all or part of this work for personal or Google’s QUIC protocol. Quick UDP Internet Connections (QUIC) classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation [32] is a key-exchange protocol based on UDP connections, which on the first page. Copyrights for components of this work owned by others than the aims at reducing the relatively high latency of protocols like TLS. author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or The latency in TLS(-over-TCP) stems from the handshake mes- republish, to post on servers or to redistribute to lists, requires prior specific permission sages (for both TCP and TLS) to be sent before the first encrypted and/or a fee. Request permissions from [email protected]. message can be transmitted. QUIC’s goal is to reduce the number CCS’15, October 12–16, 2015, Denver, Colorado, USA. of “round trips” for key establishment to a minimum, while provid- Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-3832-5/15/10 ...$15.00. ing all security guarantees expected from a key-exchange protocol DOI: http://dx.doi.org/10.1145/2810103.2813657. on the Internet. QUIC is currently considered experimental, but put forward by 3. While Bleichenbacher’s attack and its early applications [7, Google and implemented in recent versions of Google’s Chrome 22] were originally rather inefficient, much faster versions web browser, the Opera browser, and available on Google web are known today [25, 4]. This makes such attacks applicable servers. Google has announced that QUIC will be proposed as an in settings where they were previously considered infeasible. IETF standard.1 Currently, draft version 01 is available.2 Thus, in summary, PKCS#1 v1.5 encryption has proven to be Relevance and recurrence of Bleichenbacher attacks. At Crypto extremely difficult to implement securely. Considering all possible 1998 [7] Bleichenbacher presented a seminal attack on RSA-based side channels (some of which might not even be conceivable today) PKCS#1 v1.5 encryption. Essentially, it assumes the existence of seems virtually impossible. an “oracle” that allows an attacker to distinguish “valid” from “in- valid” PKCS#1 v1.5-padded ciphertexts. Such an oracle may in Transferring the weaknesses of PKCS#1 v1.5 encryption to mod- practice be given by a TLS server, which responds with appropriate ern protocols. For the reasons explained above, it seems a wise de- error messages, or allows in any other way to tell whether a given cision that PKCS#1 v1.5 encryption is not used in QUIC and will ciphertext has a “valid” padding or not (for instance by observing finally be removed from TLS in version 1.3. However, the question the timing behavior of the server when processing the ciphertext). that motivates our research is the following: Bleichenbacher showed that such an oracle is sufficient to decrypt Is this sufficient to protect TLS 1.3 and QUIC against the PKCS#1 v1.5 ciphertexts. Today there exist many variants and re- weaknesses of PKCS#1 v1.5 encryption? finements of this attack [7, 22, 9, 18, 4, 28, 36], the TLS RFCs [10, 11, 12] give recommendations for implementing PKCS#1 v1.5 en- We analyze the security of both protocols under the hypothe- cryption securely (which are however kept quite general). sis that Bleichenbacher-like attacks on PKCS#1 v1.5 encryption in One may think that seventeen years after the publication of Ble- TLS versions prior to 1.3 will remain a realistic threat in the future, ichenbacher’s attack we should have developed a very good under- and study the impact of such attacks on TLS 1.3 and QUIC. standing of this weakness, and that at least important, widely-used For the analysis of TLS 1.3, we consider a setting where there is applications that still use this scheme (possibly for legacy reasons, a TLS client C that supports only TLS 1.3, and thus may expect that like TLS) finally implement it securely. However, there is vast evi- it is immune against weaknesses in PKCS#1 v1.5 encryption. The dence that this belief is false: client connects to a server S, which offers TLS 1.3, and at least one 1. Increasingly sophisticated analysis techniques and new side previous TLS version which allows to use PKCS#1 v1.5 encryp- channels allow one to apply Bleichenbacher-like attacks in tion, say TLS 1.2. Note that today’s TLS servers are typically not settings where these attacks were previously believed to be configured to offer only the most recent TLS version 1.2 (or any impossible. A recent example was described at USENIX Se- other single version), but they usually offer many TLS versions in curity 2014 by Meyer et al. [28]. The authors discover new parallel, to maximize compatibility with different TLS clients. Ac- timing-based side channels that allow one to apply Bleichen- cording to SSL Pulse [1], TLS 1.2 and 1.1 are supported by about bacher’s attack to widely-used TLS implementations, like 60%, and TLS 1.0 is supported by nearly 100% of the TLS servers Java’s JSSE or hardware security appliances using Cavium’s analyzed in April 2015.
Load more

Recommended publications
  • On the Security of the PKCS#1 V1.5 Signature Scheme
    On the Security of the PKCS#1 v1.5 Signature Scheme Tibor Jager1 Saqib A. Kakvi1 Alexander May2 September 10, 2018 1Department of Computer Science, Universitat¨ Paderborn ftibor.jager,[email protected] 2Hortz Gortz¨ Institute, Ruhr Universitat¨ Bochum [email protected] Abstract The RSA PKCS#1 v1.5 signature algorithm is the most widely used digital signature scheme in practice. Its two main strengths are its extreme simplicity, which makes it very easy to implement, and that verification of signatures is significantly faster than for DSA or ECDSA. Despite the huge practical importance of RSA PKCS#1 v1.5 signatures, providing formal evidence for their security based on plausible cryptographic hardness assumptions has turned out to be very difficult. Therefore the most recent version of PKCS#1 (RFC 8017) even recommends a replacement the more complex and less efficient scheme RSA-PSS, as it is provably secure and therefore considered more robust. The main obstacle is that RSA PKCS#1 v1.5 signatures use a deterministic padding scheme, which makes standard proof techniques not applicable. We introduce a new technique that enables the first security proof for RSA-PKCS#1 v1.5 signatures. We prove full existential unforgeability against adaptive chosen-message attacks (EUF-CMA) under the standard RSA assumption. Furthermore, we give a tight proof under the Phi-Hiding assumption. These proofs are in the random oracle model and the parameters deviate slightly from the standard use, because we require a larger output length of the hash function. However, we also show how RSA-PKCS#1 v1.5 signatures can be instantiated in practice such that our security proofs apply.
    [Show full text]
  • The Rocky Road To
    The Rocky Road to Hanno Böck https://hboeck.de @hanno 1 Transport Layer Security A protocol to create an encrypted and authenticated layer around other protocols 2 TLS 1.3 was published in August 2018 3 How did we get there? 4 In 1995 Netscape introduced Secure Socket Layer or SSL version 2 5 In 1996 it was followed up with SSL version 3 6 In 1999 the IETF took over and renamed it to TLS 7 SSL/TLS History 1995: SSL 2 1996: SSL 3 1999: TLS 1.0 2006: TLS 1.1 2008: TLS 1.2 2018: TLS 1.3 8 Vulnerabilities C C S 9 Padding Oracles in CBC mode 10 Plaintext Plaintext Plaintext Initialization Vector (IV) block cipher block cipher block cipher Key Key Key encryption encryption encryption Ciphertext Ciphertext Ciphertext WhiteTimberwolf, Wikimedia Commons, Public Domain 11 CBC Padding for Block Ciphers (AES) Encryption of data blocks means we have to fill up space 12 CBC in TLS MAC-then-Pad-then-Encrypt 13 Valid Padding 00 01 01 02 02 02 03 03 03 03 ... 14 We assume a situation where the attacker can see whether the padding is valid 15 Ciphertext Ciphertext block cipher block cipher Key Key decryption decryption Initialization Vector (IV) ?== 00 -> padding valid Plaintext Plaintext Attacker wants to decrypt Attacker manipulates / XOR with guess 16 Ciphertext Ciphertext block cipher block cipher Key Key decryption decryption Initialization Vector (IV) ?== 01 01 -> padding valid Plaintext Plaintext Attacker knows Attacker manipulates to 01 Attacker wants to know Attacker manipulates to guess 01 17 2002: Serge Vaudenay discovers Padding Oracle Vaudenay,
    [Show full text]
  • An Analysis of the Transport Layer Security Protocol
    An Analysis of the Transport Layer Security Protocol Thyla van der Merwe Thesis submitted to the University of London for the degree of Doctor of Philosophy Information Security Group School of Mathematics and Information Security Royal Holloway, University of London 2018 Declaration These doctoral studies were conducted under the supervision of Professor Kenneth G. Paterson. The work presented in this thesis is the result of original research I conducted, in collabo- ration with others, whilst enrolled in the School of Mathematics and Information Security as a candidate for the degree of Doctor of Philosophy. This work has not been submitted for any other degree or award in any other university or educational establishment. Thyla van der Merwe March, 2018 2 Dedication To my niece, Emma. May you always believe in your abilities, no matter what anybody tells you, and may you draw on the strength of our family for support, as I have done (especially your Gogo, she’s one tough lady). “If you’re going through hell, keep going.” Winston Churchill 3 Abstract The Transport Layer Security (TLS) protocol is the de facto means for securing commu- nications on the World Wide Web. Originally developed by Netscape Communications, the protocol came under the auspices of the Internet Engineering Task Force (IETF) in the mid 1990s and today serves millions, if not billions, of users on a daily basis. The ubiquitous nature of the protocol has, especially in recent years, made the protocol an attractive target for security researchers. Since the release of TLS 1.2 in 2008, the protocol has suffered many high-profile, and increasingly practical, attacks.
    [Show full text]
  • Return of Bleichenbacher's Oracle Threat (ROBOT)
    Return Of Bleichenbacher's Oracle Threat (ROBOT) https://robotattack.org/ Hanno B¨ock , Juraj Somorovsky1,2, and Craig Young3 1Ruhr-Universit¨atBochum 2Hackmanit GmbH 3Tripwire VERT December 12, 2017 Abstract Many web hosts are still vulnerable to one of the oldest attacks against RSA in TLS. We show that Bleichenbacher's RSA vulnerability from 1998 is still very prevalent in the Internet and affects almost a third of the top 100 domains in the Alexa Top 1 Million list, among them Facebook and Paypal. We identified vulnerable products from at least eight differ- ent vendors and open source projects, among them F5, Citrix, Radware, Cisco, Erlang, Bouncy Castle, and WolfSSL. Further we have demon- strated practical exploitation by signing a message with the private key of facebook.com's HTTPS certificate. Finally, we discuss countermeasures against Bleichenbacher attacks in TLS and recommend to deprecate the RSA encryption key exchange in TLS and the PKCS #1 v1.5 standard. This work is licensed under a Creative Commons \Attribution 3.0 Unported" license. 1 Contents 1 Introduction 3 2 TLS-RSA key exchange 4 3 Bleichenbacher's attack 5 3.1 RSA PKCS #1 v1.5 . 5 3.2 Attack intuition . 5 3.3 Attack performance and oracle types . 6 3.4 Creating a signature with Bleichenbacher's attack . 6 4 Scanning methodology 7 4.1 Differently formatted PKCS #1 v1.5 messages . 7 4.2 Different TLS protocol flows . 9 4.3 Cipher suites . 9 4.4 Monitoring different server responses . 9 4.5 Performing a server scan . 10 4.6 More variations .
    [Show full text]
  • 20 Years of Bleichenbacher's Attack
    Royal Holloway University of London ISG MSc Information Security thesis series 2019 20 years of Bleichenbacher’s attack Authors Gage Boyle, MSc (Royal Holloway, 2018) Kenny Paterson, ISG, Royal Holloway Abstract The HTTPS protocol is a vital tool in safeguarding the security of our personal and business lives. This protocol ensures that important data such as financial information, intellectual prop- erty and login credentials are encrypted and integrity protected as they travel across the Inter- net. Ultimately this means that a malicious observer is unable to obtain, view, use or sell this important data. To both technical and non-technical users, the presence of “HTTPS” at the start of the website URL will provide enough confidence to consider entering sensitive information such as bank or credit card details. However, in this article we will explain how even websites owned by the most reputable organisations may be exposed to a 20-year-old attack if HTTPS is not properly implemented. Around 33% of internet servers were found to be vulnerable to this attack in 2016, and both Facebook and PayPal remained vulnerable in 2017. Furthermore, related weaknesses in HTTPS implementations are still regularly being discovered. As a result, a secure TLS im- plementation is imperative for all organisations looking to maintain their business reputations and sensitive intellectual property. a aThis article is published online by Computer Weekly as part of the 2019 Royal Holloway informa- tion security thesis series https://www.computerweekly.com/ehandbook/The-exploitation-of-flaws-in-the- HTTPS-protocol. It is based on an MSc dissertation written as part of the MSc in Information Secu- rity at the ISG, Royal Holloway, University of London.
    [Show full text]
  • Finding and Exploiting Most-Significant-Bit
    Raccoon Attack: Finding and Exploiting Most-Significant-Bit-Oracles in TLS-DH(E) Robert Merget1, Marcus Brinkmann1, Nimrod Aviram2, Juraj Somorovsky3, Johannes Mittmann4, and Jörg Schwenk1 1Ruhr University Bochum 2School of Computer Science, Tel Aviv University 3Paderborn University 4Bundesamt für Sicherheit in der Informationstechnik (BSI), Germany Abstract Diffie-Hellman key exchange (DHKE) is a widely adopted method for exchanging cryptographic key material in real- world protocols like TLS-DH(E). Past attacks on TLS-DH(E) focused on weak parameter choices or missing parameter validation. The confidentiality of the computed DH share, the premaster secret, was never questioned; DHKE is used as a generic method to avoid the security pitfalls of TLS-RSA. We show that due to a subtle issue in the key derivation of all TLS-DH(E) cipher suites in versions up to TLS 1.2, the premaster secret of a TLS-DH(E) session may, under Figure 1: Raccoon attack overview. The attacker passively certain circumstances, be leaked to an adversary. Our main observes the public DH shares of a client-server connection result is a novel side-channel attack, named Raccoon attack, and uses an oracle in the TLS key derivation to calculate which exploits a timing vulnerability in TLS-DH(E), leaking the shared DH secret using a solver for the Hidden Number the most significant bits of the shared Diffie-Hellman secret. Problem. The root cause for this side channel is that the TLS standard encourages non-constant-time processing of the DH secret. If the server reuses ephemeral keys, this side channel may gb mod p to A, while A sends its share ga mod p to B.
    [Show full text]
  • Differentially Analyzing Side-Channel Traces for Detecting SSL/TLS Vulnerabilities in Secure Enclaves
    Stacco: Differentially Analyzing Side-Channel Traces for Detecting SSL/TLS Vulnerabilities in Secure Enclaves Yuan Xiao Mengyuan Li The Ohio State University The Ohio State University [email protected] [email protected] Sanchuan Chen Yinqian Zhang The Ohio State University The Ohio State University [email protected] [email protected] ABSTRACT queries, respectively, to break one block of AES ciphertext. Em- Intel Software Guard Extension (SGX) offers software applications pirical evaluation suggests these man-in-the-kernel attacks can be a shielded execution environment, dubbed enclave, to protect their completed within one or two hours. confidentiality and integrity from malicious operating systems. As processors with this extended feature become commercially available, many new software applications are developed to enrich 1 INTRODUCTION to the SGX-enabled software ecosystem. One important primitive Software applications’ security heavily depends on the security of for these applications is a secure communication channel between the underlying system software. In traditional computing environ- the enclave and a remote trusted party. The SSL/TLS protocol, which ments, if the operating system is compromised, the security of the is the de facto standard for protecting transport-layer network applications it supports is also compromised. Therefore, the trusted communications, has been broadly regarded a natural choice for computing base (TCB) of software applications include not only such purposes. However, in this paper, we show that the marriage the software itself but also the underlying system software and between SGX and SSL may not be a smooth sailing. hardware. Particularly, we consider a category of side-channel attacks To reduce the TCB of some applications that contain sensitive against SSL/TLS implementations in secure enclaves, which we call code and data, academic researchers have proposed many software the control-flow inference attacks.
    [Show full text]
  • Revisiting SSL/TLS Implementations: New Bleichenbacher Side
    Revisiting SSL/TLS Implementations: New Bleichenbacher Side Channels and Attacks Christopher Meyer, Juraj Somorovsky, Eugen Weiss, and Jörg Schwenk, Ruhr-University Bochum; Sebastian Schinzel, Münster University of Applied Sciences; Erik Tews, Technische Universität Darmstadt https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/meyer This paper is included in the Proceedings of the 23rd USENIX Security Symposium. August 20–22, 2014 • San Diego, CA ISBN 978-1-931971-15-7 Open access to the Proceedings of the 23rd USENIX Security Symposium is sponsored by USENIX Revisiting SSL/TLS Implementations: New Bleichenbacher Side Channels and Attacks Christopher Meyer, Juraj Somorovsky, Eugen Weiss, Jorg¨ Schwenk Horst Gortz¨ Institute for IT-Security, Ruhr-University Bochum < christopher.meyer, juraj.somorovsky, eugen.weiss, joerg.schwenk @rub.de> { } Sebastian Schinzel <[email protected]> Department of Computer Science, Munster¨ University of Applied Sciences Erik Tews <[email protected]> European Center for Security and Privacy by Design,Technische Universitat¨ Darmstadt Abstract TLS impl. Side channel Queries & Efficiency Queries Time As a countermeasure against the famous Bleichenbacher OpenSSL timing O(240) n.a. attack on RSA based ciphersuites, all TLS RFCs starting JSSE error message 177,000 12 h from RFC 2246 (TLS 1.0) propose “to treat incorrectly JSSE timing 18,600 19.5 h formatted messages in a manner indistinguishable from Cavium timing 7371 41 h correctly formatted RSA blocks”. In this paper we show
    [Show full text]
  • The Ssl/Tls Protocol
    VULNERABILITIES OF THE SSL/TLS PROTOCOL Jelena Ćurguz Department of IT development and services, Post Office, Banja Luka, BiH [email protected] ABSTRACT This paper analyzes vulnerabilities of the SSL/TLS Handshake protocol , which is responsible for authentication of the parties in the communication and negotiation of security parameters that will be used to protect confidentiality and integrity of the data . It will be analyzed the attacks against the implementation of Handshake protocol, as well as the attacks against the other elements necessary to SSL/TLS protocol to discover security flaws that were exploited, modes of attack, the potential consequences, but also studying methods of defense . All versions of the protocol are going to be the subject of the research but emphasis will be placed on the critical attack that the most endanger the safety of data. The goal of the research is to point out the danger of existence of at least vulnerability in the SSL/TLS protocol , which can be exploited and endanger the safety of the data that should be protected. KEYWORDS SSL/TLS Protocols, Handshake Protocols, Attacks, 1. INTRODUCTION Internet today has become of great importance for the economy, education, business, and almost all other aspects of society, which is becoming an irreplaceable tool for work and for getting of the necessary information. Most companies organize their business via the Internet, all business communications, distribution, purchase, sale, marketing and servicing of products are made via the Internet. Environment such as e-banking, e-commerce, e-business and other offer many benefits to its users. The simplest way to perform a financial transaction is over the Internet.
    [Show full text]