[erlang-questions] ssl: TLS-1.2 signature extension

[Dániel Szoboszlay]

Hi,

I was backporting the patch (edab501fe
<https://github.com/erlang/otp/commit/edab501fe7bffe3f19871157ebd1851e6dad1bc5>)
for this issue (ERL-206 <https://bugs.erlang.org/browse/ERL-206>) to OTP
18. The patch itself does 3 things:

   1. Fixes a bug in how TLS version numbers are compared (this part is
   clear and easy).
   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).
   3. Sets the record layer version to 0x0301 (TLS 1.2) when the client
   supports TLS 1.2 (the old behaviour was to use the lowest supported
   protocol's version number).

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:

   - In ERL-206 <https://bugs.erlang.org/browse/ERL-206>:

   E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0

   [...]

   A TLS 1.2 client who wishes to negotiate with such older servers will
   send a normal TLS 1.2 ClientHello, containing
   { 3, 3 }

   (TLS 1.2) in
   ClientHello.client_version. If the server does not support this
   version, it will respond with a ServerHello containing an older
   version number. If the client agrees to use this version, the
   negotiation will proceed as appropriate for the negotiated protocol.

   However, this section of the RFC talks about the version number in the
   ClientHello, not the record layer version.

   - In an email
   <http://erlang.org/pipermail/erlang-questions/2016-August/089899.html>
   from the 9th of August:

   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.


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:

   1. OpenSSL (and therefore wget and curl) does ignore the MUST NOT
   sending:
      - 0x0301 record layer version
      - 0x0303 ClientHello version
      - The signature algorithm extensions

      2. The quote from the RFC continues like this:

      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
[TLSEXT <https://tools.ietf.org/html/rfc5246#ref-TLSEXT>]
      require servers to ignore extensions they do not understand.


   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.

   3. 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.

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.

What do you think?

Daniel

On Mon, 3 Apr 2017 at 12:46 Andreas Schultz <aschultz@REDACTED> wrote:

> Hi,
>
> I've come across a curious TLS 1.2 connection problem. Erlang 19.x will
> not connect to https://validator5.addressdoctor.com/ in the default
> configuration or when more than TLS 1.2 is offered.
>
> After some digging I found out that the server (IIS-8.0) would attempt
> to use TLS 1.2, but chokes on the *missing* Signature Algorithms extension.
> This is clearly a bug in the server implementation, as it should assume
> a default value for the supported signature algorithms. Nevertheless,
> every other TLS client works normally.
>
> Erlang SSL behavior is 100% compliant with RFC-5246:
>
> > Note: this extension is not meaningful for TLS versions prior to 1.2.
> >       Clients MUST NOT offer it if they are offering prior versions.
>
> Tests with OpenSSL and GNU-TLS show that they ignore the "MUST NOT"
> from the above clause and include the Signature Algorithms extension
> whenever they offer TLS 1.2 regardless of a possible fallback to a
> lower version.
>
> I think Erlang's SSL should do the same.
>
> There is also an alternative way to understand the clause. It's meaning
> depends on "offering prior version". The version offered is the value
> from ClientHello.client_version, so as soon as this value is {3, 3},
> a Signature Algorithms extension should be sent.
>
>
> Regards
> Andreas
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170907/316796fb/attachment.htm>