https://wiki.openssl.org/index.php?title=SSL_MODE_SEND_FALLBACK_SCSV&feed=atom&action=historySSL MODE SEND FALLBACK SCSV - Revision history2024-03-29T12:05:03ZRevision history for this page on the wikiMediaWiki 1.35.6https://wiki.openssl.org/index.php?title=SSL_MODE_SEND_FALLBACK_SCSV&diff=1977&oldid=prevJwalton: Added page with examples.2014-10-17T22:59:00Z<p>Added page with examples.</p>
<p><b>New page</b></p><div>[http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-02 TLS_FALLBACK_SCSV] is a TLS Signaling Cipher Suite Value (SCSV) that can be used to guard against protocol downgrade attacks. The extension can be useful for clients like web browsers, which fall back to a lesser protocol version if attempts to use a higher protocol version fail.<br />
<br />
In the attack, the adversary would force a negotiation failure of a higher protocol like TLS 1.2 or 1.1 in hopes the client will retry with TLS 1.0 or SSLv3. Then, the adversary will use defects in the down level protocols to carry out other attacks. Table 1 below lists some of the losses that could occur when traversing down protocol versions.<br />
<br />
{| class="wikitable" border="1"<br />
|+ Protocols, Downgrades and Features<br />
|-<br />
! width="150" | Desired Protocol<br />
! width="150" | Downgraded Protocol<br />
! width="250" | Loss on Downgrade<br />
|-<br />
| TLS 1.2<br />
| TLS 1.1<br />
| [[EVP Authenticated Encryption and Decryption | AEAD cipher suites]] (CCM, GCM, etc)<br />
|-<br />
| TLS 1.1<br />
| TLS 1.0<br />
| Perfect Forward Secrecy (PFS)<br />
|-<br />
| TLS 1.0<br />
| SSL v3<br />
| Too many to list<sup>[1]</sup><br />
|}<br />
<br />
<sup>[1]</sup> See [http://yaksman.org/~lweith/ssl.pdf Differences Between SSLv2, SSLv3, and TLS] and [http://www.openssl.org/~bodo/ssl-poodle.pdf This POODLE Bites: Exploiting The SSL 3.0 Fallback].<br />
<br />
The SSL_MODE_SEND_FALLBACK_SCSV extension can be used to remediate the [http://www.openssl.org/~bodo/ssl-poodle.pdf POODLE bug] by ensuring clients don't fall back to SSLv3 '''''if''''' the client performs fallbacks. However, the extension does not fix the underlying padding oracle. Rather, it just avoids the defective protocol version.<br />
<br />
SCSV means TLS_FALLBACK_SCSV shows up as a cipher suite in the <tt>ClientHello</tt>. The spurious cipher is added to the cipher suites if the [[SSL_MODE_SEND_FALLBACK_SCSV]] option is present.<br />
<br />
'''''Note Well''''': if the client does not perform fallbacks, then the TLS_FALLBACK_SCSV extension is not needed.<br />
<br />
== Reason for the Extension ==<br />
<br />
Browsers and other similar software attempt to support every server created on {God|Allah|Brahman|...}'s green earth. If the browser attempts to connect to 1990s era server and the connection fails, then the browser will fallback to a lesser protocol. It falls back to a lesser protocol by initiating a new connection with the down level protocol.<br />
<br />
Its curious why the browsers chose to compromise the security of the dominant/standard use cases for a trivial minority. The W3C clearly states two design principals: [http://www.w3.org/TR/html-design-principles/#secure-by-design Secure By Design] and [http://www.w3.org/TR/html-design-principles/#priority-of-constituencies Priority of Constituencies]. When a browser falls back to insecure protocols when the user asks for a secure scheme, they violate both principals.<br />
<br />
The browsers could have provided modern TLS support with 15 or 20 reasonable ciphers (or let the users choose their vanity ciphers); and then require a plug-in to achieve the existing insecure behavior. Browsers seem more than happy to require plug-ins for the most basic functionality, like opening a homepage (try to get [http://productforums.google.com/forum/#!topic/chrome/JPLugnTBiMQ Chrome], [http://support.mozilla.org/en-US/questions/962910 Firefox] or [http://addons.opera.com/en/extensions/details/homepage-in-new-tab Opera] to open your homepage on a new tab).<br />
<br />
Even more befuddling, the <tt>SSL_MODE_SEND_FALLBACK_SCSV</tt> is not needed now that SSLv3 is insecure due to the padding oracle (as if Loern Weith was not clear that [http://yaksman.org/~lweith/ssl.pdf SSLv3 was insecure in 2006]). In fact, the down level software that is part of the problem likely won't be updated to understand the TLS extension anyway.<br />
<br />
== Avoiding the Extension ==<br />
<br />
As stated earlier, <tt>SSL_MODE_SEND_FALLBACK_SCSV</tt> is '''''not''''' needed if the client does not perform fallbacks. The easiest way to avoid use of the <tt>SSL_MODE_SEND_FALLBACK_SCSV</tt> is to always specify the protocols you are willing to accept. The detail is you '''''always''''' send the highest protocol version with the <tt>ClientHello</tt>.<br />
<br />
For example, suppose you want to accept TLS 1.0 through TLS 1.2. In this case, you send a <tt>ClientHello</tt> with that information, and you don't include <tt>SSL_MODE_SEND_FALLBACK_SCSV</tt>. Below is a portion of the code to do so (its likely similar to the code you have been using for years):<br />
<br />
<pre>const SSL_METHOD* method = SSLv23_method();<br />
if(method == NULL)) handleFailure();<br />
<br />
SSL_CTX* ctx = SSL_CTX_new(method);<br />
if(ctx == NULL) handleFailure();<br />
<br />
const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION;<br />
SSL_CTX_set_options(ctx, flags);</pre><br />
<br />
In the code above, the <tt>SSLv23_method</tt> enables all protocol version - from SSLv2 through TLS 1.2. The method is then used to create a context object. After the context object is created, weak/wounded/broken protocols and options are removed by setting <tt>SSL_OP_NO_SSLv2</tt>, <tt>SSL_OP_NO_SSLv3</tt> and <tt>SSL_OP_NO_COMPRESSION</tt>.<br />
<br />
The <tt>ClientHello</tt> will set a minimum protocol version of TLS 1.0 and a maximum protocol version of TLS 1.2 in the <tt>ClientHello</tt>. The TLS protocol ensures TLS 1.2 is used if available; and TLS 1.1 is used is TLS 1.2 is ''not'' available; and TLS 1.0 is used if TLS 1.2 and 1.1 are ''not'' available. During key exchange, the <tt>ClientHello</tt> is MAC'd and used (in part) to derive the <tt>premaster_secret</tt>, so tampering with protocol versions will be detected.<br />
<br />
When TLS 1.3 is added to OpenSSL, it will include TLS 1.3. You won't have to change your code.<br />
<br />
== Using the Extension ==<br />
<br />
If you need to use the extension, then the following is an example of how to use it:<br />
<br />
<pre>const SSL_METHOD* method = TLSv1_2_method();<br />
if(method == NULL)) handleFailure();<br />
<br />
SSL_CTX* ctx = SSL_CTX_new(method);<br />
if(ctx == NULL) handleFailure();<br />
<br />
#ifdef SSL_MODE_SEND_FALLBACK_SCSV<br />
SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV)<br />
#endif</pre><br />
<br />
Some folks on the OpenSSL mailing list recommend using TLS_FALLBACK_SCSV and <tt>SSL_MODE_SEND_FALLBACK_SCSV</tt> whenever available. See, for example, [http://www.mail-archive.com/openssl-users@openssl.org/msg75278.html Use of TLS_FALLBACK_SCSV] on the OpenSSL mailing list.<br />
<br />
== Related Discussions ==<br />
<br />
Below are some discussions that occurred on the OpenSSL and IETF mailing lists and around the web.<br />
<br />
* [http://www.mail-archive.com/openssl-users@openssl.org/ Context options and SSL_MODE_SEND_FALLBACK_SCSV]<br />
* [http://www.mail-archive.com/openssl-users@openssl.org/ Use of TLS_FALLBACK_SCSV]<br />
* [http://www.mail-archive.com/openssl-users@openssl.org/ Please document the new SSL_MODE_SEND_FALLBACK_SCSV]<br />
* [http://www.ietf.org/mail-archive/web/tls/current/msg13713.html Working Group Last Call for draft-ietf-tls-downgrade-scsv-00]<br />
* [http://www.ietf.org/mail-archive/web/tls/current/msg13945.html The TLS_FALLBACK_SCSV time bomb]<br />
* [http://blogs.akamai.com/2014/10/ssl-is-dead-long-live-tls.html SSL is dead, long live TLS]</div>Jwalton