<div dir="ltr">Hi,<div><br></div><div>I was backporting the patch (<a href="https://github.com/erlang/otp/commit/edab501fe7bffe3f19871157ebd1851e6dad1bc5">edab501fe</a>) for this issue (<a href="https://bugs.erlang.org/browse/ERL-206">ERL-206</a>) to OTP 18. The patch itself does 3 things:</div><div><ol><li><font size="2">Fixes a bug in how TLS version numbers are compared (this part is clear and easy).</font></li><li><font size="2">Makes sure to always send the signature algorithms client hello extension when the client supports TLS 1.2 (this alone is enough to fix interoperability with Microsoft IIS).</font></li><li><font size="2">Sets the record layer version to 0x0301 (TLS 1.2) </font>when the client supports TLS 1.2 (the old behaviour was to use the lowest supported protocol's version number).</li></ol><div>Personally, I'm not convinced that change 3 is a good idea. I found Ingela quoting RFC 5246 in two places for why is it both necessary and backward compatible:</div></div><div><ul><li><font size="2">In </font><a href="https://bugs.erlang.org/browse/ERL-206">ERL-206</a>:<br><p style="margin:10px 0px 0px;padding:0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;background-color:rgb(245,245,245)">E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0</p><p style="margin:10px 0px 0px;padding:0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;background-color:rgb(245,245,245)"><span class="inbox-inbox-error">[...]</span></p><p style="margin:10px 0px 0px;padding:0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;background-color:rgb(245,245,245)">A TLS 1.2 client who wishes to negotiate with such older servers will<br>send a normal TLS 1.2 ClientHello, containing</p><span style="color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;background-color:rgb(245,245,245)">{ 3, 3 }</span><p style="margin:10px 0px 0px;padding:0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;background-color:rgb(245,245,245)">(TLS 1.2) in<br>ClientHello.client_version. If the server does not support this<br>version, it will respond with a ServerHello containing an older<br>version number. If the client agrees to use this version, the<br>negotiation will proceed as appropriate for the negotiated protocol.<br></p><br>However, this section of the RFC talks about the version number in the ClientHello, not the record layer version.<br><br></li><li>In an <a href="http://erlang.org/pipermail/erlang-questions/2016-August/089899.html">email</a> from the 9th of August:<br><br><pre style="white-space:pre-wrap">I investigated it and as it turns out it is not a bug. RFC 5246 says,
7.4.1.4.1 Signature Algorithms[...]
Note: this extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions.
However the initial client hello will now be sent with the TLS record
protocol with lowest version supported, which it failed to do before and
that is
why it happened to work before. Extensions are sent for the wanted version
and should be ignored if a lower version is negotiated with exception of
signature algorithms, due to the sentence above.</pre></li></ul><div>I understand that the MUST NOT clause says a client cannot both send a signature algorithms extension and offer older versions of TLS (via the record version number). However, I am on the side of Andreas, that violating the RFC seems to be the correct thing to do:</div></div><div><ol><li><font size="2">OpenSSL (and therefore wget and curl) does ignore the MUST NOT sending:</font></li><ul><li><font size="2">0x0301 record layer version</font></li><li><font size="2">0x0303 ClientHello version</font></li><li><font size="2">The signature algorithm extensions<br><br></font></li></ul><li><font size="2">The quote from the RFC continues like this:<br><br><pre class="inbox-inbox-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px"> Note: this extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions.
However, even if clients do offer it, the rules specified in [<a href="https://tools.ietf.org/html/rfc5246#ref-TLSEXT" title=""Transport Layer Security (TLS) Extensions: Extension Definitions"">TLSEXT</a>]
require servers to ignore extensions they do not understand.
</pre><br class="inbox-inbox-Apple-interchange-newline">The second sentence pretty much contradicts the first one: clients must not do this, but if they do, it should still work, even with older servers. This explains on what grounds OpenSSL could decide to ignore the MUST NOT clause.<br><br></font></li><li><font size="2">We've already encountered some "broken" servers that drop TLS 1.2 connection attempts if they don't contain this specific hello extension. I have a bad feeling that there can be some old and broken servers on the internet too, that do not support TLS 1.2 and would drop a connection attempt if we send version number 0x0303 in the record layer.</font></li></ol><div><span style="font-size:small">I couldn't figure out why OpenSSL decided to use the old record layer version and violate the MUST NOT clause, but it would feel safer to do what they do when the RFC is this ambiguous. There are way more OpenSSL users than OTP 20 users, so if their strategy would cause interoperability problems, we would probably know about it already.</span><br></div></div><div><span style="font-size:small"><br></span></div><div><span style="font-size:small">What do you think?</span></div><div><span style="font-size:small"><br></span></div><div><span style="font-size:small">Daniel</span></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 3 Apr 2017 at 12:46 Andreas Schultz <<a href="mailto:aschultz@tpip.net">aschultz@tpip.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I've come across a curious TLS 1.2 connection problem. Erlang 19.x will<br>
not connect to <a href="https://validator5.addressdoctor.com/" rel="noreferrer" target="_blank">https://validator5.addressdoctor.com/</a> in the default<br>
configuration or when more than TLS 1.2 is offered.<br>
<br>
After some digging I found out that the server (IIS-8.0) would attempt<br>
to use TLS 1.2, but chokes on the *missing* Signature Algorithms extension.<br>
This is clearly a bug in the server implementation, as it should assume<br>
a default value for the supported signature algorithms. Nevertheless,<br>
every other TLS client works normally.<br>
<br>
Erlang SSL behavior is 100% compliant with RFC-5246:<br>
<br>
> Note: this extension is not meaningful for TLS versions prior to 1.2.<br>
> Clients MUST NOT offer it if they are offering prior versions.<br>
<br>
Tests with OpenSSL and GNU-TLS show that they ignore the "MUST NOT"<br>
from the above clause and include the Signature Algorithms extension<br>
whenever they offer TLS 1.2 regardless of a possible fallback to a<br>
lower version.<br>
<br>
I think Erlang's SSL should do the same.<br>
<br>
There is also an alternative way to understand the clause. It's meaning<br>
depends on "offering prior version". The version offered is the value<br>
from ClientHello.client_version, so as soon as this value is {3, 3},<br>
a Signature Algorithms extension should be sent.<br>
<br>
<br>
Regards<br>
Andreas<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>