Is X25519/X448 supported for TLSv1.2?

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

Is X25519/X448 supported for TLSv1.2?

John Jiang
Hi,
Using OpenSSL 1.1.1.
Just want to confirm that if OpenSSL supports curves X25519 and X448 for TLSv1.2.

Tried below commands,
openssl s_server -trace -state -cert server.cer -key server.key -accept port
openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519 -connect localhost:port

the server side raised the below error,
140735913575296:error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:ssl/statem/statem_srvr.c:2253:

If using -groups P-256, the handshaking was fine.
Reply | Threaded
Open this post in threaded view
|

Re: Is X25519/X448 supported for TLSv1.2?

Viktor Dukhovni
On Wed, Jun 12, 2019 at 03:45:12PM +0800, John Jiang wrote:

> Using OpenSSL 1.1.1.
> Just want to confirm that if OpenSSL supports curves X25519 and X448 for
> TLSv1.2.

Yes, it does.

> Tried below commands,
> openssl s_server -trace -state -cert server.cer -key server.key -accept port
> openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519 -connect localhost:port

With same commands, using OpenSSL 1.1.1c, I get:

    CONNECTION ESTABLISHED
    Protocol version: TLSv1.2
    Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
    Peer certificate:
    Hash used: SHA256
    Signature type: RSA-PSS
    Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
    Server Temp Key: X25519, 253 bits

Perhaps your s_client is not the one from 1.1.1 or it is dynamically
linked against 1.1.0 libraries...

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Is X25519/X448 supported for TLSv1.2?

John Jiang
On Wed, Jun 12, 2019 at 4:34 PM Viktor Dukhovni <[hidden email]> wrote:
On Wed, Jun 12, 2019 at 03:45:12PM +0800, John Jiang wrote:

> Using OpenSSL 1.1.1.
> Just want to confirm that if OpenSSL supports curves X25519 and X448 for
> TLSv1.2.

Yes, it does.

> Tried below commands,
> openssl s_server -trace -state -cert server.cer -key server.key -accept port
> openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519 -connect localhost:port

With same commands, using OpenSSL 1.1.1c, I get:

    CONNECTION ESTABLISHED
    Protocol version: TLSv1.2
    Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
    Peer certificate:
    Hash used: SHA256
    Signature type: RSA-PSS
    Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
    Server Temp Key: X25519, 253 bits

Perhaps your s_client is not the one from 1.1.1 or it is dynamically
linked against 1.1.0 libraries...
My s_client can support TLSv1.3, so it should not be from any pre-1.1.1 version.
Reply | Threaded
Open this post in threaded view
|

Re: Is X25519/X448 supported for TLSv1.2?

Viktor Dukhovni
On Wed, Jun 12, 2019 at 05:31:30PM +0800, John Jiang wrote:

> > > Tried below commands,
> > > openssl s_server -trace -state -cert server.cer -key server.key -accept port
> > > openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519 -connect localhost:port
> >
> > With same commands, using OpenSSL 1.1.1c, I get:
> >
> >     CONNECTION ESTABLISHED
> >     Protocol version: TLSv1.2
> >     Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
> >     Peer certificate:
> >     Hash used: SHA256
> >     Signature type: RSA-PSS
> >     Supported Elliptic Curve Point Formats: ...
> >     Server Temp Key: X25519, 253 bits
> >
> > Perhaps your s_client is not the one from 1.1.1 or it is dynamically
> > linked against 1.1.0 libraries...
> >
> My s_client can support TLSv1.3, so it should not be from any pre-1.1.1
> version.

You say that, but the evidence suggests otherwise.  In each of
whatever shells you're using to start the client and server,
it would be prudent to run:

    $ openssl version -v

Here's an example with the command and library at the same version:

    $ /usr/local/bin/openssl version -v
    OpenSSL 1.1.1c  28 May 2019

And here's another where they differ in the patchlevel:

    $ LD_PRELOAD=/lib/libcrypto.so.111:/usr/lib/libssl.so.111 /usr/local/bin/openssl version -v
    OpenSSL 1.1.1c  28 May 2019 (Library: OpenSSL 1.1.1a-freebsd  20 Nov 2018)

Without forcing anything with LD_PRELOAD, ... are your client and
server in fact 1.1.1 in both the executable and the library?

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Is X25519/X448 supported for TLSv1.2?

John Jiang
I got the point: the server certificate is ECDSA with curve secp256r1.
It works with RSA certificate and curves sepc256r1/sepc384r1/sepc521r1/x25519/x448.

On Thu, Jun 13, 2019 at 3:00 AM Viktor Dukhovni <[hidden email]> wrote:
On Wed, Jun 12, 2019 at 05:31:30PM +0800, John Jiang wrote:

> > > Tried below commands,
> > > openssl s_server -trace -state -cert server.cer -key server.key -accept port
> > > openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519 -connect localhost:port
> >
> > With same commands, using OpenSSL 1.1.1c, I get:
> >
> >     CONNECTION ESTABLISHED
> >     Protocol version: TLSv1.2
> >     Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
> >     Peer certificate:
> >     Hash used: SHA256
> >     Signature type: RSA-PSS
> >     Supported Elliptic Curve Point Formats: ...
> >     Server Temp Key: X25519, 253 bits
> >
> > Perhaps your s_client is not the one from 1.1.1 or it is dynamically
> > linked against 1.1.0 libraries...
> >
> My s_client can support TLSv1.3, so it should not be from any pre-1.1.1
> version.

You say that, but the evidence suggests otherwise.  In each of
whatever shells you're using to start the client and server,
it would be prudent to run:

    $ openssl version -v

Here's an example with the command and library at the same version:

    $ /usr/local/bin/openssl version -v
    OpenSSL 1.1.1c  28 May 2019

And here's another where they differ in the patchlevel:

    $ LD_PRELOAD=/lib/libcrypto.so.111:/usr/lib/libssl.so.111 /usr/local/bin/openssl version -v
    OpenSSL 1.1.1c  28 May 2019 (Library: OpenSSL 1.1.1a-freebsd  20 Nov 2018)

Without forcing anything with LD_PRELOAD, ... are your client and
server in fact 1.1.1 in both the executable and the library?

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Is X25519/X448 supported for TLSv1.2?

Viktor Dukhovni
On Thu, Jun 13, 2019 at 10:49:14AM +0800, John Jiang wrote:

> I got the point: the server certificate is ECDSA with curve secp256r1.
> It works with RSA certificate and curves
> sepc256r1/sepc384r1/sepc521r1/x25519/x448.

See https://github.com/openssl/openssl/issues/4175#issuecomment-322915924

When using ECDSA with TLSv1.2, the group list MUST include the group
used in the certificate.  Otherwise, you get no shared cipher as
you reported.  You can *prefer* X25519, but you cannot only offer
X25519.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Is X25519/X448 supported for TLSv1.2?

John Jiang


On Thu, Jun 13, 2019 at 12:28 PM Viktor Dukhovni <[hidden email]> wrote:
On Thu, Jun 13, 2019 at 10:49:14AM +0800, John Jiang wrote:

> I got the point: the server certificate is ECDSA with curve secp256r1.
> It works with RSA certificate and curves
> sepc256r1/sepc384r1/sepc521r1/x25519/x448.

See https://github.com/openssl/openssl/issues/4175#issuecomment-322915924

When using ECDSA with TLSv1.2, the group list MUST include the group
used in the certificate.  Otherwise, you get no shared cipher as
you reported.
How about this point in TLSv1.3?
With my testing, the case "ECDSA certificate with curve secp256r1 + named group secp521r1" work fine with OpenSSL s_server and s_client.
 
You can *prefer* X25519, but you cannot only offer
X25519.
Just an intentional test.
Reply | Threaded
Open this post in threaded view
|

Re: Is X25519/X448 supported for TLSv1.2?

Viktor Dukhovni
On Fri, Jun 14, 2019 at 09:05:32AM +0800, John Jiang wrote:

> > See https://github.com/openssl/openssl/issues/4175#issuecomment-322915924
> >
> > When using ECDSA with TLSv1.2, the group list MUST include the group
> > used in the certificate.  Otherwise, you get no shared cipher as
> > you reported.
>
> How about this point in TLSv1.3?
> With my testing, the case "ECDSA certificate with curve secp256r1 + named
> group secp521r1" work fine with OpenSSL s_server and s_client.

In TLS 1.3, the "supported groups" extension restricts the curves
used in the key exchange:

  https://tools.ietf.org/html/rfc8446#section-4.2.7

The curves used for signing are covered by "signature algorithms":

    https://tools.ietf.org/html/rfc8446#section-4.2.3

Which should, if I am not mistaken, allow an ECDSA certificate to
be used with a "supported groups" list that does not list the curve
associated with the certificate.

--
        Viktor.