| <!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="This section discusses vulnerabilities in other TLS implementations, theorising their root cause and how we aim to avoid them in rustls."><meta name="keywords" content="rust, rustlang, rust-lang, _01_impl_vulnerabilities"><title>rustls::manual::_01_impl_vulnerabilities - Rust</title><link rel="preload" as="font" type="font/woff2" crossorigin href="../../../SourceSerif4-Regular.ttf.woff2"><link rel="preload" as="font" type="font/woff2" crossorigin href="../../../FiraSans-Regular.woff2"><link rel="preload" as="font" type="font/woff2" crossorigin href="../../../FiraSans-Medium.woff2"><link rel="preload" as="font" type="font/woff2" crossorigin href="../../../SourceCodePro-Regular.ttf.woff2"><link rel="preload" as="font" type="font/woff2" crossorigin href="../../../SourceSerif4-Bold.ttf.woff2"><link rel="preload" as="font" type="font/woff2" crossorigin href="../../../SourceCodePro-Semibold.ttf.woff2"><link rel="stylesheet" href="../../../normalize.css"><link rel="stylesheet" href="../../../rustdoc.css" id="mainThemeStyle"><link rel="stylesheet" href="../../../ayu.css" disabled><link rel="stylesheet" href="../../../dark.css" disabled><link rel="stylesheet" href="../../../light.css" id="themeStyle"><script id="default-settings" ></script><script src="../../../storage.js"></script><script defer src="../../../main.js"></script><noscript><link rel="stylesheet" href="../../../noscript.css"></noscript><link rel="alternate icon" type="image/png" href="../../../favicon-16x16.png"><link rel="alternate icon" type="image/png" href="../../../favicon-32x32.png"><link rel="icon" type="image/svg+xml" href="../../../favicon.svg"></head><body class="rustdoc mod"><!--[if lte IE 11]><div class="warning">This old browser is unsupported and will most likely display funky things.</div><![endif]--><nav class="mobile-topbar"><button class="sidebar-menu-toggle">☰</button><a class="sidebar-logo" href="../../../rustls/index.html"><div class="logo-container"><img class="rust-logo" src="../../../rust-logo.svg" alt="logo"></div></a><h2></h2></nav><nav class="sidebar"><a class="sidebar-logo" href="../../../rustls/index.html"><div class="logo-container"><img class="rust-logo" src="../../../rust-logo.svg" alt="logo"></div></a><h2 class="location"><a href="#">Module _01_impl_vulnerabilities</a></h2><div class="sidebar-elems"></div></nav><main><div class="width-limiter"><nav class="sub"><form class="search-form"><div class="search-container"><span></span><input class="search-input" name="search" autocomplete="off" spellcheck="false" placeholder="Click or press ‘S’ to search, ‘?’ for more options…" type="search"><div id="help-button" title="help" tabindex="-1"><a href="../../../help.html">?</a></div><div id="settings-menu" tabindex="-1"><a href="../../../settings.html" title="settings"><img width="22" height="22" alt="Change settings" src="../../../wheel.svg"></a></div></div></form></nav><section id="main-content" class="content"><div class="main-heading"><h1 class="fqn">Module <a href="../../index.html">rustls</a>::<wbr><a href="../index.html">manual</a>::<wbr><a class="mod" href="#">_01_impl_vulnerabilities</a><button id="copy-path" onclick="copy_path(this)" title="Copy item path to clipboard"><img src="../../../clipboard.svg" width="19" height="18" alt="Copy item path"></button></h1><span class="out-of-band"><a class="srclink" href="../../../src/rustls/manual/implvulns.rs.html#1-104">source</a> · <a id="toggle-all-docs" href="javascript:void(0)" title="collapse all docs">[<span class="inner">−</span>]</a></span></div><details class="rustdoc-toggle top-doc" open><summary class="hideme"><span>Expand description</span></summary><div class="docblock"><p>This section discusses vulnerabilities in other TLS implementations, theorising their |
| root cause and how we aim to avoid them in rustls.</p> |
| <h2 id="a-review-of-tls-implementation-vulnerabilities"><a href="#a-review-of-tls-implementation-vulnerabilities">A review of TLS Implementation Vulnerabilities</a></h2> |
| <p>An important part of engineering involves studying and learning from the mistakes of the past. |
| It would be tremendously unfortunate to spend effort re-discovering and re-fixing the same |
| vulnerabilities that were discovered in the past.</p> |
| <h3 id="memory-safety"><a href="#memory-safety">Memory safety</a></h3> |
| <p>Being written entirely in the safe-subset of Rust immediately offers us freedom from the entire |
| class of memory safety vulnerabilities. There are too many to exhaustively list, and there will |
| certainly be more in the future.</p> |
| <p>Examples:</p> |
| <ul> |
| <li>Heartbleed <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160">CVE-2014-0160</a> (OpenSSL)</li> |
| <li>Memory corruption in ASN.1 decoder <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2108">CVE-2016-2108</a> (OpenSSL)</li> |
| <li>Buffer overflow in read_server_hello <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3466">CVE-2014-3466</a> (GnuTLS)</li> |
| </ul> |
| <h3 id="goto-fail"><a href="#goto-fail"><code>goto fail</code></a></h3> |
| <p>This is the name of a vulnerability in Apple Secure Transport <a href="https://nvd.nist.gov/vuln/detail/CVE-2014-1266">CVE-2014-1266</a>. |
| This boiled down to the following code, which validates the server’s signature on the key exchange:</p> |
| <div class="example-wrap"><pre class="language-c"><code> if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) |
| goto fail; |
| if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) |
| goto fail; |
| > goto fail; |
| if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) |
| goto fail;</code></pre></div> |
| <p>The marked line was duplicated, likely accidentally during a merge. This meant |
| the remaining part of the function (including the actual signature validation) |
| was unconditionally skipped.</p> |
| <p>Ultimately the one countermeasure to this type of bug is basic testing: that a |
| valid signature returns success, and that an invalid one does not. rustls |
| has such testing, but this is really table stakes for security code.</p> |
| <p>Further than this, though, we could consider that the <em>lack</em> of an error from |
| this function is a poor indicator that the signature was valid. rustls, instead, |
| has zero-size and non-copyable types that indicate a particular signature validation |
| has been performed. These types can be thought of as <em>capabilities</em> originated only |
| by designated signature verification functions – such functions can then be a focus |
| of manual code review. Like capabilities, values of these types are otherwise unforgeable, |
| and are communicable only by Rust’s move semantics.</p> |
| <p>Values of these types are threaded through the protocol state machine, leading to terminal |
| states that look like:</p> |
| |
| <div class="example-wrap ignore"><div class='tooltip'>ⓘ</div><pre class="rust rust-example-rendered"><code><span class="kw">struct </span>ExpectTraffic { |
| (...) |
| _cert_verified: verify::ServerCertVerified, |
| _sig_verified: verify::HandshakeSignatureValid, |
| _fin_verified: verify::FinishedMessageVerified, |
| }</code></pre></div> |
| <p>Since this state requires a value of these types, it will be a compile-time error to |
| reach that state without performing the requisite security-critical operations.</p> |
| <p>This approach is not infallible, but it has zero runtime cost.</p> |
| <h3 id="state-machine-attacks-earlyccs-and-smackskipfreak"><a href="#state-machine-attacks-earlyccs-and-smackskipfreak">State machine attacks: EarlyCCS and SMACK/SKIP/FREAK</a></h3> |
| <p>EarlyCCS <a href="https://nvd.nist.gov/vuln/detail/CVE-2014-0224">CVE-2014-0224</a> was a vulnerability in OpenSSL |
| found in 2014. The TLS <code>ChangeCipherSpec</code> message would be processed at inappropriate times, leading |
| to data being encrypted with the wrong keys (specifically, keys which were not secret). This resulted |
| from OpenSSL taking a <em>reactive</em> strategy to incoming messages (“when I get a message X, I should do Y”) |
| which allows it to diverge from the proper state machine under attacker control.</p> |
| <p><a href="https://mitls.org/pages/attacks/SMACK">SMACK</a> is a similar suite of vulnerabilities found in JSSE, |
| CyaSSL, OpenSSL, Mono and axTLS. “SKIP-TLS” demonstrated that some implementations allowed handshake |
| messages (and in one case, the entire handshake!) to be skipped leading to breaks in security. “FREAK” |
| found that some implementations incorrectly allowed export-only state transitions (ie, transitions that |
| were only valid when an export ciphersuite was in use).</p> |
| <p>rustls represents its protocol state machine carefully to avoid these defects. We model the handshake, |
| CCS and application data subprotocols in the same single state machine. Each state in this machine is |
| represented with a single struct, and transitions are modelled as functions that consume the current state |
| plus one TLS message<sup id="fnref1"><a href="#fn1">1</a></sup> and return a struct representing the next state. These functions fully validate |
| the message type before further operations.</p> |
| <p>A sample sequence for a full TLSv1.2 handshake by a client looks like:</p> |
| <ul> |
| <li><code>hs::ExpectServerHello</code> (nb. ClientHello is logically sent before this state); transition to <code>tls12::ExpectCertificate</code></li> |
| <li><code>tls12::ExpectCertificate</code>; transition to <code>tls12::ExpectServerKX</code></li> |
| <li><code>tls12::ExpectServerKX</code>; transition to <code>tls12::ExpectServerDoneOrCertReq</code></li> |
| <li><code>tls12::ExpectServerDoneOrCertReq</code>; delegates to <code>tls12::ExpectCertificateRequest</code> or <code>tls12::ExpectServerDone</code> depending on incoming message. |
| <ul> |
| <li><code>tls12::ExpectServerDone</code>; transition to <code>tls12::ExpectCCS</code></li> |
| </ul> |
| </li> |
| <li><code>tls12::ExpectCCS</code>; transition to <code>tls12::ExpectFinished</code></li> |
| <li><code>tls12::ExpectFinished</code>; transition to <code>tls12::ExpectTraffic</code></li> |
| <li><code>tls12::ExpectTraffic</code>; terminal state; transitions to <code>tls12::ExpectTraffic</code></li> |
| </ul> |
| <p>In the future we plan to formally prove that all possible transitions modelled in this system of types |
| are correct with respect to the standard(s). At the moment we rely merely on exhaustive testing.</p> |
| <div class="footnotes"><hr><ol><li id="fn1"><p>a logical TLS message: post-decryption, post-fragmentation. <a href="#fnref1">↩</a></p></li></ol></div></div></details></section></div></main><div id="rustdoc-vars" data-root-path="../../../" data-current-crate="rustls" data-themes="ayu,dark,light" data-resource-suffix="" data-rustdoc-version="1.66.0-nightly (5c8bff74b 2022-10-21)" ></div></body></html> |
