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

2019-06-13 Thread 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.


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

2019-06-13 Thread John Jiang
On Thu, Jun 13, 2019 at 12:28 PM Viktor Dukhovni 
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.


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

2019-06-12 Thread 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.


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

2019-06-12 Thread 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 
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.
>


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

2019-06-12 Thread 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.


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

2019-06-12 Thread John Jiang
On Wed, Jun 12, 2019 at 4:34 PM Viktor Dukhovni 
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.


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

2019-06-12 Thread 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.


Is X25519/X448 supported for TLSv1.2?

2019-06-12 Thread 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.