Enforcing group / key_share order in TLS1.3

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Enforcing group / key_share order in TLS1.3

Sebastian Andrzej Siewior-2
Hi,

gnutls-cli sends by default (in the supported groups extension)
`secp256r1' first and later `x25519'. The key_share extension contains a
key for both types. The server has both types configured both groups and
`x25519' comes first.
The handshake however ends up with `secp256r1'. Is there a way to tell
openssl to prefer `x25519' over `secp256r1'?

Sebastian
Reply | Threaded
Open this post in threaded view
|

Re: Enforcing group / key_share order in TLS1.3

Matt Caswell-2


On 10/01/2020 22:41, Sebastian Andrzej Siewior wrote:
> gnutls-cli sends by default (in the supported groups extension)
> `secp256r1' first and later `x25519'. The key_share extension contains a
> key for both types. The server has both types configured both groups and
> `x25519' comes first.
> The handshake however ends up with `secp256r1'. Is there a way to tell
> openssl to prefer `x25519' over `secp256r1'?

The current behaviour is that the first key share we see that also
exists in our supported groups list is the one that we use. There isn't
a way at the moment to configure things in order to specify a preference
order.

https://github.com/openssl/openssl/blob/bbe486cf6154df3d3aaedbae6c5b82d4ed31a5f8/ssl/statem/extensions_srvr.c#L662-L720

It wouldn't be too difficult to amend the above logic to select the key
share that is highest in the server's supported group list. But that
would be a new feature and wouldn't be backported to 1.1.1.

PRs to make that change welcome.

Matt


Reply | Threaded
Open this post in threaded view
|

Re: Enforcing group / key_share order in TLS1.3

Hubert Kario
In reply to this post by Sebastian Andrzej Siewior-2
On Friday, 10 January 2020 23:41:20 CET, Sebastian Andrzej Siewior wrote:
> Hi,
>
> gnutls-cli sends by default (in the supported groups extension)
> `secp256r1' first and later `x25519'. The key_share extension contains a
> key for both types. The server has both types configured both groups and
> `x25519' comes first.
> The handshake however ends up with `secp256r1'. Is there a way to tell
> openssl to prefer `x25519' over `secp256r1'?

use the server preference setting? for s_server it's the -serverpref switch

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 115, 612 00  Brno, Czech Republic

Reply | Threaded
Open this post in threaded view
|

Re: Enforcing group / key_share order in TLS1.3

Sebastian Andrzej Siewior-2
In reply to this post by Matt Caswell-2
On 2020-01-13 11:23:35 [+0000], Matt Caswell wrote:
> The current behaviour is that the first key share we see that also
> exists in our supported groups list is the one that we use. There isn't
> a way at the moment to configure things in order to specify a preference
> order.
>
> https://github.com/openssl/openssl/blob/bbe486cf6154df3d3aaedbae6c5b82d4ed31a5f8/ssl/statem/extensions_srvr.c#L662-L720

Okay so there isn't a knob yet. Thank you for confirming.

> It wouldn't be too difficult to amend the above logic to select the key
> share that is highest in the server's supported group list. But that
> would be a new feature and wouldn't be backported to 1.1.1.
>
> PRs to make that change welcome.

Thanks, done.

> Matt
>
Sebastian