Re: [openssl-dev] 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

Re: [openssl-dev] 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

Re: [openssl-dev] 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 
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
> > ].
> >   "
> >
>
> 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
>


x25519_trace0.pcap
Description: Binary data
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 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
> ].
>   "
> 

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

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

[Benjamin Kaduk via openssl-dev]

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

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

[Matt Caswell]

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

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

[David Benjamin via openssl-dev]

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:
https://boringssl.googlesource.com/boringssl/+/4ac2dc4c0d48ca45da4f66c40e60d6b425fa94a3

(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 <
openssl-dev@openssl.org> 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