ssl: TLS-1.2 signature extension

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ssl: TLS-1.2 signature extension

Andreas Schultz
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ssl: TLS-1.2 signature extension

Dániel Szoboszlay
Hi,

I was backporting the patch (edab501fe) for this issue (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:

    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 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]
       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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions