rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

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

rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

OpenSSL - Dev mailing list
Hi all,

Doing some testing with a snapshot of master (s_client with -tls1_2 and
optionally a cipherspec that prefers ECDHE ciphers), we're running into
a sizeable number of servers that are sending extension 0xa (formerly
"elliptic_curves", now "supported_groups") in the ServerHello.  This is
not supported by RFC 7919 or RFC 4492 (the server is supposed to
indicate it's selected curve/group in the ServerKeyExchange message
instead), or by the TLS 1.3 draft spec (which permits "supported_groups"
in EncryptedExtensions, so the client can update a cache of groups
supported by the server).

In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension
in a ServerHello as an extension unknown to the library code and passed
it off to the custom extension handler.  With the extension processing
rework in master done to support TLS 1.3, which admits extensions in
many more contexts than previously, we now check that a received
extension is allowable in the context at hand.  In the table of
extensions, supported_groups is marked only as allowable in the
ClientHello and TLS 1.3 EncryptedExtensions, per the spec.  However,
this new strict behavior causes connection failures when talking to
these buggy servers.  So far we've seen this behavior from servers that
send a Server: header indicating Microsoft-IIS/7.5 and just "Apache".

This raises some question of what behavioral compatibility is desired
between 1.1.0 and 1.1.1 -- do we need to disable the "extension context"
verification for ServerHello processing entirely, or maybe just for the
one extension known to cause trouble in practice?  Or should we have an
SSL/SSL_CTX option to control the behavior (and which behavior should be
the default)?

Also, I'd be interested in hearing whether anyone else has observed this
sort of behavior.

Thanks,

Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

OpenSSL - Dev mailing list
It's just that extension in our experience. Enforcing that servers don't send extensions they aren't supposed to generally works fine and is good for the ecosystem. But that particular extension needs a quirk.

I suspect there was some confusion because ec_point_format_list can be server-sent in TLS 1.2 while elliptic_curves cannot. To be honest, I think that was just a mistake in RFC 4492. TLS 1.2 has no way for the server to tell the client what curves are acceptable for client certificates while the converse is possible. (TLS 1.3 avoids this mess entirely with SignatureScheme.)

I do not know how widespread this one is. It looks like we coincidentally retained the quirk for this extension in BoringSSL when we first rewrote our extension-handling from the 1.0.2 code. Later on, I encountered the issue unrelatedly (I was probing some servers with some custom Go code), noticed we were already tolerant of this, and merely added a clarifying comment:

(Speaking of which, I think I forgot to inform the vendor. I'll send them a note.)

David

On Tue, Oct 3, 2017 at 11:16 AM Benjamin Kaduk via openssl-dev <[hidden email]> wrote:
Hi all,

Doing some testing with a snapshot of master (s_client with -tls1_2 and
optionally a cipherspec that prefers ECDHE ciphers), we're running into
a sizeable number of servers that are sending extension 0xa (formerly
"elliptic_curves", now "supported_groups") in the ServerHello.  This is
not supported by RFC 7919 or RFC 4492 (the server is supposed to
indicate it's selected curve/group in the ServerKeyExchange message
instead), or by the TLS 1.3 draft spec (which permits "supported_groups"
in EncryptedExtensions, so the client can update a cache of groups
supported by the server).

In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension
in a ServerHello as an extension unknown to the library code and passed
it off to the custom extension handler.  With the extension processing
rework in master done to support TLS 1.3, which admits extensions in
many more contexts than previously, we now check that a received
extension is allowable in the context at hand.  In the table of
extensions, supported_groups is marked only as allowable in the
ClientHello and TLS 1.3 EncryptedExtensions, per the spec.  However,
this new strict behavior causes connection failures when talking to
these buggy servers.  So far we've seen this behavior from servers that
send a Server: header indicating Microsoft-IIS/7.5 and just "Apache".

This raises some question of what behavioral compatibility is desired
between 1.1.0 and 1.1.1 -- do we need to disable the "extension context"
verification for ServerHello processing entirely, or maybe just for the
one extension known to cause trouble in practice?  Or should we have an
SSL/SSL_CTX option to control the behavior (and which behavior should be
the default)?

Also, I'd be interested in hearing whether anyone else has observed this
sort of behavior.

Thanks,

Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

Matt Caswell-2
In reply to this post by OpenSSL - Dev mailing list


On 03/10/17 16:15, Benjamin Kaduk via openssl-dev wrote:

> Hi all,
>
> Doing some testing with a snapshot of master (s_client with -tls1_2 and
> optionally a cipherspec that prefers ECDHE ciphers), we're running into
> a sizeable number of servers that are sending extension 0xa (formerly
> "elliptic_curves", now "supported_groups") in the ServerHello.  This is
> not supported by RFC 7919 or RFC 4492 (the server is supposed to
> indicate it's selected curve/group in the ServerKeyExchange message
> instead), or by the TLS 1.3 draft spec (which permits "supported_groups"
> in EncryptedExtensions, so the client can update a cache of groups
> supported by the server).
>
> In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension
> in a ServerHello as an extension unknown to the library code and passed
> it off to the custom extension handler.  With the extension processing
> rework in master done to support TLS 1.3, which admits extensions in
> many more contexts than previously, we now check that a received
> extension is allowable in the context at hand.  In the table of
> extensions, supported_groups is marked only as allowable in the
> ClientHello and TLS 1.3 EncryptedExtensions, per the spec.  However,
> this new strict behavior causes connection failures when talking to
> these buggy servers.  So far we've seen this behavior from servers that
> send a Server: header indicating Microsoft-IIS/7.5 and just "Apache".
>
> This raises some question of what behavioral compatibility is desired
> between 1.1.0 and 1.1.1 -- do we need to disable the "extension context"
> verification for ServerHello processing entirely, or maybe just for the
> one extension known to cause trouble in practice?  Or should we have an
> SSL/SSL_CTX option to control the behavior (and which behavior should be
> the default)?
>
> Also, I'd be interested in hearing whether anyone else has observed this
> sort of behavior.

Looks like we should have an exception for this case (with a suitable
comment explaining why). Will you create a PR?

Matt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

OpenSSL - Dev mailing list
On 10/04/2017 04:30 AM, Matt Caswell wrote:
>
> Looks like we should have an exception for this case (with a suitable
> comment explaining why). Will you create a PR?
>

Yes, I was planning to.  I was just taking some time to ponder whether
it's worth burning an option bit on, to allow an opt-out (probably not).

-Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

Mahesh Bhoothapuri
In reply to this post by OpenSSL - Dev mailing list

    if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) {
           //error
    }
   
    The client and server both use SSL_CTX_set1_groups-list to set the supported group list.  Right now,  the server always
    has P-256 in the supported groups extension. 
    When the the groups list is changed to add X25519,  the server responds with P-256.   Is there a way to have the server support
    multiple specified groups.

    Section 9.1 of the rfc states:
    "
A TLS-compliant application MUST support digital signatures with
   rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
   CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
   TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].
  "

  So, having the server support P-256 satisfies the MUST part.  How can we support X25519 on the server, or
  a list of different groups. 
Thanks,
Mahesh

On Tue, Oct 3, 2017 at 8:15 AM, Benjamin Kaduk via openssl-dev <[hidden email]> wrote:
Hi all,

Doing some testing with a snapshot of master (s_client with -tls1_2 and
optionally a cipherspec that prefers ECDHE ciphers), we're running into
a sizeable number of servers that are sending extension 0xa (formerly
"elliptic_curves", now "supported_groups") in the ServerHello.  This is
not supported by RFC 7919 or RFC 4492 (the server is supposed to
indicate it's selected curve/group in the ServerKeyExchange message
instead), or by the TLS 1.3 draft spec (which permits "supported_groups"
in EncryptedExtensions, so the client can update a cache of groups
supported by the server).

In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension
in a ServerHello as an extension unknown to the library code and passed
it off to the custom extension handler.  With the extension processing
rework in master done to support TLS 1.3, which admits extensions in
many more contexts than previously, we now check that a received
extension is allowable in the context at hand.  In the table of
extensions, supported_groups is marked only as allowable in the
ClientHello and TLS 1.3 EncryptedExtensions, per the spec.  However,
this new strict behavior causes connection failures when talking to
these buggy servers.  So far we've seen this behavior from servers that
send a Server: header indicating Microsoft-IIS/7.5 and just "Apache".

This raises some question of what behavioral compatibility is desired
between 1.1.0 and 1.1.1 -- do we need to disable the "extension context"
verification for ServerHello processing entirely, or maybe just for the
one extension known to cause trouble in practice?  Or should we have an
SSL/SSL_CTX option to control the behavior (and which behavior should be
the default)?

Also, I'd be interested in hearing whether anyone else has observed this
sort of behavior.

Thanks,

Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

Dr. Stephen Henson
On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:

>     if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) {
>            //error
>     }
>

If you have the above line you're telling the client to advertise support for
P-521:P-384:P-256 in that order and the server to only use them.

>     The client and server both use SSL_CTX_set1_groups-list to set the
> supported group list.  Right now,  the server always
>     has P-256 in the supported groups extension.
>     When the the groups list is changed to add X25519,  the server responds
> with P-256.   Is there a way to have the server support
>     multiple specified groups.
>
>     Section 9.1 of the rfc states:
>     "
>
> A TLS-compliant application MUST support digital signatures with
>    rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
>    CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
>    TLS-compliant application MUST support key exchange with secp256r1
>    (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748
> <https://tools.ietf.org/html/rfc7748>].
>   "
>

Yes and OpenSSL does support those but there is nothing stopping a server or
client being configured to support a different set of groups.

>   So, having the server support P-256 satisfies the MUST part.  How
> can we support X25519 on the server, or
>

Use X25519 in the supported group list.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

Mahesh Bhoothapuri
I am attaching a pcap where I set the supported list to contain X25519.  The client extension contains X25519.  However, the server still responds with keyshare extension secp256r1 in a hello retry request.

This is the case for all the 5 TLS 1.3 ciphers.  Is there another setting for the server to enable the supported groups?


Thanks,
Mahesh

On Wed, Oct 4, 2017 at 8:02 AM, Dr. Stephen Henson <[hidden email]> wrote:
On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:

>     if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) {
>            //error
>     }
>

If you have the above line you're telling the client to advertise support for
P-521:P-384:P-256 in that order and the server to only use them.

>     The client and server both use SSL_CTX_set1_groups-list to set the
> supported group list.  Right now,  the server always
>     has P-256 in the supported groups extension.
>     When the the groups list is changed to add X25519,  the server responds
> with P-256.   Is there a way to have the server support
>     multiple specified groups.
>
>     Section 9.1 of the rfc states:
>     "
>
> A TLS-compliant application MUST support digital signatures with
>    rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
>    CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
>    TLS-compliant application MUST support key exchange with secp256r1
>    (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748
> <https://tools.ietf.org/html/rfc7748>].
>   "
>

Yes and OpenSSL does support those but there is nothing stopping a server or
client being configured to support a different set of groups.

>   So, having the server support P-256 satisfies the MUST part.  How
> can we support X25519 on the server, or
>

Use X25519 in the supported group list.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

x25519_trace0.pcap (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

Dr. Stephen Henson
On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:

> I am attaching a pcap where I set the supported list to contain X25519.
> The client extension contains X25519.  However, the server still responds
> with keyshare extension secp256r1 in a hello retry request.
>

Are you calling SSL_CTX_set1_groups_list() including X25519 on the server too?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

Mahesh Bhoothapuri
Thanks for the hint.  The problem is fixed.

Server was setting:

if (SSL_CTX_set1_groups_list(ctx, "X25519:P-256") == 0) {
//
}

The call succeeds.

But the old TLS 1.2 code was setting:

            int nid = NID_X9_62_prime256v1;
            EC_KEY* ecdh = EC_KEY_new_by_curve_name(nid);
            if (ecdh == NULL)
            {
               //error
            }
            SSL_CTX_set_tmp_ecdh(ctx, ecdh);

After disabling this, the server responds with the right group - X25519.

Thanks,
Mahesh




--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

Dr. Stephen Henson
On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:

> Thanks for the hint.  The problem is fixed.
>
> Server was setting:
>
> if (SSL_CTX_set1_groups_list(ctx, "X25519:P-256") == 0) {
> //
> }
>
> The call succeeds.
>
> But the old TLS 1.2 code was setting:
>
>             int nid = NID_X9_62_prime256v1;
>             EC_KEY* ecdh = EC_KEY_new_by_curve_name(nid);
>             if (ecdh == NULL)
>             {
>                //error
>             }
>             SSL_CTX_set_tmp_ecdh(ctx, ecdh);
>
> After disabling this, the server responds with the right group - X25519.
>

Yes that's the problem. By doing that you're replacing the groups list with a
single curve.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev