mirror of
https://github.com/OMGeeky/google-apis-rs.git
synced 2026-02-23 15:49:49 +01:00
127 lines
16 KiB
HTML
127 lines
16 KiB
HTML
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><meta name="generator" content="rustdoc"><meta name="description" content="API documentation for the Rust `_02_tls_vulnerabilities` mod in crate `rustls`."><meta name="keywords" content="rust, rustlang, rust-lang, _02_tls_vulnerabilities"><title>rustls::manual::_02_tls_vulnerabilities - Rust</title><link rel="stylesheet" type="text/css" href="../../../normalize.css"><link rel="stylesheet" type="text/css" href="../../../rustdoc.css" id="mainThemeStyle"><link rel="stylesheet" type="text/css" href="../../../light.css" id="themeStyle"><link rel="stylesheet" type="text/css" href="../../../dark.css" disabled ><link rel="stylesheet" type="text/css" href="../../../ayu.css" disabled ><script id="default-settings"></script><script src="../../../storage.js"></script><noscript><link rel="stylesheet" href="../../../noscript.css"></noscript><link rel="icon" type="image/svg+xml" href="../../../favicon.svg">
|
||
<link rel="alternate icon" type="image/png" href="../../../favicon-16x16.png">
|
||
<link rel="alternate icon" type="image/png" href="../../../favicon-32x32.png"><style type="text/css">#crate-search{background-image:url("../../../down-arrow.svg");}</style></head><body class="rustdoc mod"><!--[if lte IE 8]><div class="warning">This old browser is unsupported and will most likely display funky things.</div><![endif]--><nav class="sidebar"><div class="sidebar-menu">☰</div><a href='../../../rustls/index.html'><div class='logo-container rust-logo'><img src='../../../rust-logo.png' alt='logo'></div></a><p class="location">Module _02_tls_vulnerabilities</p><div class="sidebar-elems"><p class="location"><a href="../../index.html">rustls</a>::<wbr><a href="../index.html">manual</a></p><div id="sidebar-vars" data-name="_02_tls_vulnerabilities" data-ty="mod" data-relpath="../"></div><script defer src="../sidebar-items.js"></script></div></nav><div class="theme-picker"><button id="theme-picker" aria-label="Pick another theme!" aria-haspopup="menu"><img src="../../../brush.svg" width="18" alt="Pick another theme!"></button><div id="theme-choices" role="menu"></div></div><script src="../../../theme.js"></script><nav class="sub"><form class="search-form"><div class="search-container"><div><select id="crate-search"><option value="All crates">All crates</option></select><input class="search-input" name="search" disabled autocomplete="off" spellcheck="false" placeholder="Click or press ‘S’ to search, ‘?’ for more options…" type="search"></div><button type="button" class="help-button">?</button>
|
||
<a id="settings-menu" href="../../../settings.html"><img src="../../../wheel.svg" width="18" alt="Change settings"></a></div></form></nav><section id="main" class="content"><h1 class="fqn"><span class="in-band">Module <a href="../../index.html">rustls</a>::<wbr><a href="../index.html">manual</a>::<wbr><a class="mod" href="">_02_tls_vulnerabilities</a></span><span class="out-of-band"><span id="render-detail"><a id="toggle-all-docs" href="javascript:void(0)" title="collapse all docs">[<span class="inner">−</span>]</a></span><a class="srclink" href="../../../src/rustls/manual/tlsvulns.rs.html#1-173" title="goto source code">[src]</a></span></h1><div class="docblock"><p>This section discusses vulnerabilities and design errors in the TLS protocol.</p>
|
||
<h1 id="a-review-of-protocol-vulnerabilities" class="section-header"><a href="#a-review-of-protocol-vulnerabilities">A review of protocol vulnerabilities</a></h1><h2 id="cbc-mac-then-encrypt-ciphersuites" class="section-header"><a href="#cbc-mac-then-encrypt-ciphersuites">CBC MAC-then-encrypt ciphersuites</a></h2>
|
||
<p>Back in 2000 <a href="https://eprint.iacr.org/2000/025">Bellare and Namprempre</a> discussed how to make authenticated
|
||
encryption by composing separate encryption and authentication primitives. That paper included this table:</p>
|
||
<table><thead><tr><th>Composition Method</th><th>Privacy</th><th></th><th>Integrity</th><th></th></tr></thead><tbody>
|
||
<tr><td></td><td>IND-CPA</td><td>IND-CCA</td><td>NM-CPA</td><td>INT-PTXT</td></tr>
|
||
<tr><td>Encrypt-and-MAC</td><td>insecure</td><td>insecure</td><td>insecure</td><td>secure</td></tr>
|
||
<tr><td>MAC-then-encrypt</td><td>secure</td><td>insecure</td><td>insecure</td><td>secure</td></tr>
|
||
<tr><td>Encrypt-then-MAC</td><td>secure</td><td>secure</td><td>secure</td><td>secure</td></tr>
|
||
</tbody></table>
|
||
<p>One may assume from this fairly clear result that encrypt-and-MAC and MAC-then-encrypt compositions would be quickly abandoned
|
||
in favour of the remaining proven-secure option. But that didn't happen, not in TLSv1.1 (2006) nor in TLSv1.2 (2008). Worse,
|
||
both RFCs included incorrect advice on countermeasures for implementers, suggesting that the flaw was "not believed to be large
|
||
enough to be exploitable".</p>
|
||
<p><a href="http://www.isg.rhul.ac.uk/tls/Lucky13.html">Lucky 13</a> (2013) exploited this flaw and affected all implementations, including
|
||
those written <a href="https://aws.amazon.com/blogs/security/s2n-and-lucky-13/">after discovery</a>. OpenSSL even had a
|
||
<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2107">memory safety vulnerability in the fix for Lucky 13</a>, which
|
||
gives a flavour of the kind of complexity required to remove the side channel.</p>
|
||
<p>rustls does not implement CBC MAC-then-encrypt ciphersuites for these reasons. TLSv1.3 removed support for these
|
||
ciphersuites in 2018.</p>
|
||
<p>There are some further rejected options worth mentioning: <a href="https://tools.ietf.org/html/rfc7366">RFC7366</a> defines
|
||
Encrypt-then-MAC for TLS, but unfortunately cannot be negotiated without also supporting MAC-then-encrypt
|
||
(clients cannot express "I offer CBC, but only EtM and not MtE").</p>
|
||
<h2 id="rsa-pkcs1-encryption" class="section-header"><a href="#rsa-pkcs1-encryption">RSA PKCS#1 encryption</a></h2>
|
||
<p>"RSA key exchange" in TLS involves the client choosing a large random value and encrypting it using the server's
|
||
public key. This has two overall problems:</p>
|
||
<ol>
|
||
<li>It provides no <em>forward secrecy</em>: later compromise of the server's private key breaks confidentiality of
|
||
<em>all</em> past sessions using that key. This is a crucial property in the presence of software that is often
|
||
<a href="http://heartbleed.com/">poor at keeping a secret</a>.</li>
|
||
<li>The padding used in practice in TLS ("PKCS#1", or fully "RSAES-PKCS1-v1_5") has been known to be broken since
|
||
<a href="http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf">1998</a>.</li>
|
||
</ol>
|
||
<p>In a similar pattern to the MAC-then-encrypt problem discussed above, TLSv1.0 (1999), TLSv1.1 (2006) and TLSv1.2 (2008)
|
||
continued to specify use of PKCS#1 encryption, again with incrementally more complex and incorrect advice on countermeasures.</p>
|
||
<p><a href="https://robotattack.org/">ROBOT</a> (2018) showed that implementations were still vulnerable to these attacks twenty years later.</p>
|
||
<p>rustls does not support RSA key exchange. TLSv1.3 also removed support.</p>
|
||
<h2 id="beast" class="section-header"><a href="#beast">BEAST</a></h2>
|
||
<p><a href="https://vnhacker.blogspot.com/2011/09/beast.html">BEAST</a> (<a href="https://nvd.nist.gov/vuln/detail/CVE-2011-3389">CVE-2011-3389</a>)
|
||
was demonstrated in 2011 by Thai Duong and Juliano Rizzo,
|
||
and was another vulnerability in CBC-based ciphersuites in SSLv3.0 and TLSv1.0. CBC mode is vulnerable to adaptive
|
||
chosen-plaintext attacks if the IV is predictable. In the case of these protocol versions, the IV was the previous
|
||
block of ciphertext (as if the entire TLS session was one CBC ciphertext, albeit revealed incrementally). This was
|
||
obviously predictable, since it was published on the wire.</p>
|
||
<p>OpenSSL contained a countermeasure for this problem from 2002 onwards: it encrypts an empty message before each real
|
||
one, so that the IV used in the real message is unpredictable. This was turned off by default due to bugs in IE6.</p>
|
||
<p>TLSv1.1 fix this vulnerability, but not any of the other deficiencies of CBC mode (see above).</p>
|
||
<p>rustls does not support these ciphersuites.</p>
|
||
<h2 id="crime" class="section-header"><a href="#crime">CRIME</a></h2>
|
||
<p>In 2002 <a href="https://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf">John Kelsey</a> discussed the length side channel
|
||
as applied to compression of combined secret and attacker-chosen strings.</p>
|
||
<p>Compression continued to be an option in TLSv1.1 (2006) nor in TLSv1.2 (2008). Support in libraries was widespread.</p>
|
||
<p><a href="http://netifera.com/research/crime/CRIME_ekoparty2012.pdf">CRIME</a> (<a href="https://nvd.nist.gov/vuln/detail/CVE-2012-4929">CVE-2012-4929</a>)
|
||
was demonstrated in 2012, again by Thai Duong and Juliano Rizzo. It attacked several protocols offering transparent
|
||
compression of application data, allowing quick adaptive chosen-plaintext attacks against secret values like cookies.</p>
|
||
<p>rustls does not implement compression. TLSv1.3 also removed support.</p>
|
||
<h2 id="logjam--freak" class="section-header"><a href="#logjam--freak">Logjam / FREAK</a></h2>
|
||
<p>Way back when SSL was first being born, circa 1995, the US government considered cryptography a munition requiring
|
||
export control. SSL contained specific ciphersuites with dramatically small key sizes that were not subject
|
||
to export control. These controls were dropped in 2000.</p>
|
||
<p>Since the "export-grade" ciphersuites no longer fulfilled any purpose, and because they were actively harmful to users,
|
||
one may have expected software support to disappear quickly. This did not happen.</p>
|
||
<p>In 2015 <a href="https://mitls.org/pages/attacks/SMACK#freak">the FREAK attack</a> (<a href="https://nvd.nist.gov/vuln/detail/CVE-2015-0204">CVE-2015-0204</a>)
|
||
and <a href="https://weakdh.org/">the Logjam attack</a> (<a href="https://nvd.nist.gov/vuln/detail/CVE-2015-4000">CVE-2015-4000</a>) both
|
||
demonstrated total breaks of security in the presence of servers that accepted export ciphersuites. FREAK factored
|
||
512-bit RSA keys, while Logjam optimised solving discrete logs in the 512-bit group used by many different servers.</p>
|
||
<p>Naturally, rustls does not implement any of these ciphersuites.</p>
|
||
<h2 id="sweet32" class="section-header"><a href="#sweet32">SWEET32</a></h2>
|
||
<p>Block ciphers are vulnerable to birthday attacks, where the probability of repeating a block increases dramatically
|
||
once a particular key has been used for many blocks. For block ciphers with 64-bit blocks, this becomes probable
|
||
once a given key encrypts the order of 32GB of data.</p>
|
||
<p><a href="https://sweet32.info/">Sweet32</a> (<a href="https://nvd.nist.gov/vuln/detail/CVE-2016-2183">CVE-2016-2183</a>) attacked this fact
|
||
in the context of TLS support for 3DES, breaking confidentiality by analysing a large amount of attacker-induced traffic
|
||
in one session.</p>
|
||
<p>rustls does not support any 64-bit block ciphers.</p>
|
||
<h2 id="drown" class="section-header"><a href="#drown">DROWN</a></h2>
|
||
<p><a href="https://drownattack.com/">DROWN</a> (<a href="https://nvd.nist.gov/vuln/detail/CVE-2016-0800">CVE-2016-0800</a>) is a cross-protocol
|
||
attack that breaks the security of TLSv1.2 and earlier (when used with RSA key exchange) by using SSLv2. It is required
|
||
that the server uses the same key for both protocol versions.</p>
|
||
<p>rustls naturally does not support SSLv2, but most importantly does not support RSA key exchange for TLSv1.2.</p>
|
||
<h2 id="poodle" class="section-header"><a href="#poodle">Poodle</a></h2>
|
||
<p><a href="https://www.openssl.org/%7Ebodo/ssl-poodle.pdf">POODLE</a> (<a href="https://nvd.nist.gov/vuln/detail/CVE-2014-3566">CVE-2014-3566</a>)
|
||
is an attack against CBC mode ciphersuites in SSLv3. This was possible in most cases because some clients willingly
|
||
downgraded to SSLv3 after failed handshakes for later versions.</p>
|
||
<p>rustls does not support CBC mode ciphersuites, or SSLv3. Note that rustls does not need to implement <code>TLS_FALLBACK_SCSV</code>
|
||
introduced as a countermeasure because it contains no ability to downgrade to earlier protocol versions.</p>
|
||
<h2 id="gcm-nonces" class="section-header"><a href="#gcm-nonces">GCM nonces</a></h2>
|
||
<p><a href="https://tools.ietf.org/html/rfc5288">RFC5288</a> introduced GCM-based ciphersuites for use in TLS. Unfortunately
|
||
the design was poor; it reused design for an unrelated security setting proposed in RFC5116.</p>
|
||
<p>GCM is a typical nonce-based AEAD: it requires a unique (but not necessarily unpredictable) 96-bit nonce for each encryption
|
||
with a given key. The design specified by RFC5288 left two-thirds of the nonce construction up to implementations:</p>
|
||
<ul>
|
||
<li>wasting 8 bytes per TLS ciphertext,</li>
|
||
<li>meaning correct operation cannot be tested for (eg, in protocol-level test vectors).</li>
|
||
</ul>
|
||
<p>There were no trade-offs here: TLS has a 64-bit sequence number that is not allowed to wrap and would make an ideal nonce.</p>
|
||
<p>As a result, a <a href="https://eprint.iacr.org/2016/475.pdf">2016 study</a> found:</p>
|
||
<ul>
|
||
<li>implementations from IBM, A10 and Citrix used randomly-chosen nonces, which are unlikely to be unique over long connections,</li>
|
||
<li>an implementation from Radware used the same nonce for the first two messages.</li>
|
||
</ul>
|
||
<p>rustls uses a counter from a random starting point for GCM nonces. TLSv1.3 and the Chacha20-Poly1305 TLSv1.2 ciphersuite
|
||
standardise this method.</p>
|
||
<h2 id="renegotiation" class="section-header"><a href="#renegotiation">Renegotiation</a></h2>
|
||
<p>In 2009 Marsh Ray and Steve Dispensa <a href="https://kryptera.se/Renegotiating%20TLS.pdf">discovered</a> that the renegotiation
|
||
feature of all versions of TLS allows a MitM to splice a request of their choice onto the front of the client's real HTTP
|
||
request. A countermeasure was proposed and widely implemented to bind renegotiations to their previous negotiations;
|
||
unfortunately this was insufficient.</p>
|
||
<p>rustls does not support renegotiation in TLSv1.2. TLSv1.3 also no longer supports renegotiation.</p>
|
||
<h2 id="3shake" class="section-header"><a href="#3shake">3SHAKE</a></h2>
|
||
<p><a href="https://www.mitls.org/pages/attacks/3SHAKE">3SHAKE</a> (2014) described a complex attack that broke the "Secure Renegotiation" extension
|
||
introduced as a countermeasure to the previous protocol flaw.</p>
|
||
<p>rustls does not support renegotiation for TLSv1.2 connections, or RSA key exchange, and both are required for this attack
|
||
to work. rustls implements the "Extended Master Secret" (RFC7627) extension for TLSv1.2 which was standardised as a countermeasure.</p>
|
||
<p>TLSv1.3 no longer supports renegotiation and RSA key exchange. It also effectively incorporates the improvements made in RFC7627.</p>
|
||
<h2 id="kci" class="section-header"><a href="#kci">KCI</a></h2>
|
||
<p><a href="https://kcitls.org/">This vulnerability</a> makes use of TLS ciphersuites (those offering static DH) which were standardised
|
||
yet not widely used. However, they were implemented by libraries, and as a result enabled for various clients. It coupled
|
||
this with misconfigured certificates (on services including facebook.com) which allowed their misuse to MitM connections.</p>
|
||
<p>rustls does not support static DH/EC-DH ciphersuites. We assert that it is misissuance to sign an EC certificate
|
||
with the keyUsage extension allowing both signatures and key exchange. That it isn't is probably a failure
|
||
of CAB Forum baseline requirements.</p>
|
||
</div></section><section id="search" class="content hidden"></section><section class="footer"></section><div id="rustdoc-vars" data-root-path="../../../" data-current-crate="rustls"></div>
|
||
<script src="../../../main.js"></script><script defer src="../../../search-index.js"></script></body></html> |