Call for testing TLS 1.3

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

Call for testing TLS 1.3

Kurt Roeckx
The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
1.3 brings a lot of changes that might cause incompatibility. For
an overview see https://wiki.openssl.org/index.php/TLS1.3

We are considering if we should enable TLS 1.3 by default or not,
or when it should be enabled. For that, we would like to know how
applications behave with the latest beta release.

When testing this, it's important that both sides of the
connection support the same TLS 1.3 draft version. OpenSSL
currently implements draft 26. We would like to see tests
for OpenSSL acting as client and server.

https://github.com/tlswg/tls13-spec/wiki/Implementations lists
other TLS 1.3 implementations and the draft they currently
support. Note that the versions listed there might not be for the
latest release. It also lists some https test servers.

We would really like to see a diverse set of applictions being
tested. Please report any results you have to us.


Kurt

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

Re: Call for testing TLS 1.3

Dennis Clarke-2
On 29/04/18 06:43 AM, Kurt Roeckx wrote:
> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> 1.3 brings a lot of changes that might cause incompatibility. For
> an overview see https://wiki.openssl.org/index.php/TLS1.3

Looking at https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites
there are five pure TLSv1.3 ciphersuites listed. At the moment the
OpenSSL 1.1.1-pre5 utters :

n0$ LD_LIBRARY_PATH=`pwd` apps/openssl ciphers -v | grep " TLSv1\.3 "
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any
Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
n0$

So using a client connect test to apache means build up a separate
instance ( and toolchain perhaps ) running with pre4 beta only and a
self cert and then ... isolate to only TLS_AES_256_GCM_SHA384 ( for
example ) in the apache ssl config. This will take some days just for
an initial test framework and then try :

n0$ LD_LIBRARY_PATH=`pwd` apps/openssl s_client -connect
www.tls13.net:443 -tls1_3
CONNECTED(00000004)
4294967296:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure:ssl/record/rec_layer_s3.c:1569:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 239 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
     Protocol  : TLSv1.3
     Cipher    : 0000
     Session-ID:
     Session-ID-ctx:
     Master-Key:
     PSK identity: None
     PSK identity hint: None
     SRP username: None
     Start Time: 1525051962
     Timeout   : 7200 (sec)
     Verify return code: 0 (ok)
     Extended master secret: no
---
n0$

This should be fun to test.

> https://github.com/tlswg/tls13-spec/wiki/Implementations lists
> other TLS 1.3 implementations and the draft they currently
> support. Note that the versions listed there might not be for the
> latest release. It also lists some https test servers.

I'll take a look.

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

Re: Call for testing TLS 1.3

Kurt Roeckx
On Sun, Apr 29, 2018 at 10:05:39PM -0400, Dennis Clarke wrote:

> On 29/04/18 06:43 AM, Kurt Roeckx wrote:
> > The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> > 1.3 brings a lot of changes that might cause incompatibility. For
> > an overview see https://wiki.openssl.org/index.php/TLS1.3
>
> Looking at https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites
> there are five pure TLSv1.3 ciphersuites listed. At the moment the
> OpenSSL 1.1.1-pre5 utters :
>
> n0$ LD_LIBRARY_PATH=`pwd` apps/openssl ciphers -v | grep " TLSv1\.3 "
> TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
> n0$

Yes, by default only 3 are anbled, but there are also 2 other
supported included in ALL.

> So using a client connect test to apache means build up a separate
> instance ( and toolchain perhaps ) running with pre4 beta only and a
> self cert and then ... isolate to only TLS_AES_256_GCM_SHA384 ( for
> example ) in the apache ssl config. This will take some days just for
> an initial test framework and then try :

Note that Apache requires a patch that was commited 4 weeks ago to
support TLS 1.3. It just seems to make TLS 1.3 known to the
configuration files and things like that, I'm not sure why that was
needed in the first place.


Kurt

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

Re: Call for testing TLS 1.3

Dennis Clarke-2

> Yes, by default only 3 are anbled, but there are also 2 other
> supported included in ALL.

I must have done something wrong here as I see these 3 only :


n0$ LD_LIBRARY_PATH=`pwd`/openssl-1.1.1-pre5_SunOS5.10_sparc64vii+.001 \
 > openssl-1.1.1-pre5_SunOS5.10_sparc64vii+.001/apps/openssl \
 > ciphers -V -s -tls1_3 | \
 > awk '{printf("%8s  %10s  %30s  %12s  %10s  %28s  %s\n", $4, $1, $3,
$5, $6, $7, $8 )}' | sort
  TLSv1.3   0x13,0x01          TLS_AES_128_GCM_SHA256        Kx=any
Au=any               Enc=AESGCM(128)  Mac=AEAD
  TLSv1.3   0x13,0x02          TLS_AES_256_GCM_SHA384        Kx=any
Au=any               Enc=AESGCM(256)  Mac=AEAD
  TLSv1.3   0x13,0x03    TLS_CHACHA20_POLY1305_SHA256        Kx=any
Au=any    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
n0$

> Note that Apache requires a patch that was commited 4 weeks ago to
> support TLS 1.3. It just seems to make TLS 1.3 known to the ...

I'll look around for that, thank you!

Dennis



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

Re: Call for testing TLS 1.3

OpenSSL - User mailing list
In reply to this post by Kurt Roeckx
Akamai has had millions of connections with megabytes of data exchanged. This is with partial deployment on our network, and requiring customers to opt in to enable beta-testing.  We have found no issues.  We don't do 0RTT. We are using our own server.

I was surprised by how many connections and how much data we are already seeing.  I think that makes a very strong argument that TLS 1.3 should be enabled by default if it all possible.

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

Re: Call for testing TLS 1.3

OpenSSL - User mailing list
Sorry, typo.  We've had hundreds of millions of connections, with megabytes of data exchanged."

On 4/30/18, 11:52 AM, "Salz, Rich" <[hidden email]> wrote:

    Akamai has had millions of connections with megabytes of data exchanged. This is with partial deployment on our network, and requiring customers to opt in to enable beta-testing.  We have found no issues.  We don't do 0RTT. We are using our own server.
   
    I was surprised by how many connections and how much data we are already seeing.  I think that makes a very strong argument that TLS 1.3 should be enabled by default if it all possible.
   
   

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

Re: Call for testing TLS 1.3

Dennis Clarke-2
On 30/04/18 03:01 PM, Salz, Rich via openssl-users wrote:
> Sorry, typo.  We've had hundreds of millions of connections, with megabytes of data exchanged."
>

The issue is most likely that no one "in the wild" has done any testing
of significance.

I can certainly see tls1.2 exchange but there is nothing for tls1.3 and
so I am working on getting a site up pronto ( in the wild ) to test.

thus :

subject=CN = www.openssl.org

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3136 bytes and written 344 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
     Protocol  : TLSv1.2
     Cipher    : ECDHE-RSA-AES256-GCM-SHA384
etc etc etc

However tls1_3 results in .. not much, yet.


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

Re: Call for testing TLS 1.3

OpenSSL - User mailing list
>    The issue is most likely that no one "in the wild" has done any testing
    of significance.

I thought the Akamai numbers were significant.
   
    I can certainly see tls1.2 exchange but there is nothing for tls1.3 and
    so I am working on getting a site up pronto ( in the wild ) to test.

I am sorry if it wasn't clear, but I was referring to *Akamai* not *OpenSSL.*  Let me repost the whole message edited a bit.

AKAMAI has partially deployed TLS 1.3 on one of its networks using its own server. Customer can opt-in to beta-test.  AKAMAI has already seen hundreds of millions of connections, with [xxx, elided] megabytes of data exchanged.   AKAMAI has found no issues.  AKAMAI does not do 0RTT. This is production traffic, not staging or test. AKAMAI has received no customer complaints.

I was surprised by how many connections and how much data AKAMAI is already seeing.  I think that makes a very strong argument that TLS 1.3 should be enabled by default if it all possible.



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

Re: Call for testing TLS 1.3

Dennis Clarke-2
On 30/04/18 03:48 PM, Salz, Rich via openssl-users wrote:
>   I think that makes a very strong argument that TLS 1.3 should be enabled by default if it all possible.


Question would be "why would it not be?"

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

Re: Call for testing TLS 1.3

Viktor Dukhovni


> On Apr 30, 2018, at 4:55 PM, Dennis Clarke <[hidden email]> wrote:
>
> Question would be "why would it not be?"

Interoperability issues with middle-boxes or existing software written for TLS 1.2.

--
        Viktor.

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

Re: Call for testing TLS 1.3

Matt Caswell-2
In reply to this post by Dennis Clarke-2


On 30/04/18 21:55, Dennis Clarke wrote:
> On 30/04/18 03:48 PM, Salz, Rich via openssl-users wrote:
>>   I think that makes a very strong argument that TLS 1.3 should be
>> enabled by default if it all possible.
>
>
> Question would be "why would it not be?"

TLSv1.3 behaves differently to TLSv1.2. Applications written with
TLSv1.2 in mind might not work as expected when TLSv1.3 is negotiated.

Some of the issues that might be encountered are here:

https://wiki.openssl.org/index.php/TLS1.3

We have already seen a handful of issues. For example in this one an
application has implemented a PSK callback. Due to the way PSK works in
TLSv1.3 the callback can get called earlier in the process than in
TLSv1.2. Suddenly in the presence of TLSv1.3 this particular application
callback has started to crash (we don't know why yet):

https://github.com/openssl/openssl/issues/6110


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

Re: Call for testing TLS 1.3

Dennis Clarke-2
On 30/04/18 05:41 PM, Matt Caswell wrote:

>
>
> On 30/04/18 21:55, Dennis Clarke wrote:
>> On 30/04/18 03:48 PM, Salz, Rich via openssl-users wrote:
>>>    I think that makes a very strong argument that TLS 1.3 should be
>>> enabled by default if it all possible.
>>
>>
>> Question would be "why would it not be?"
>
> TLSv1.3 behaves differently to TLSv1.2. Applications written with
> TLSv1.2 in mind might not work as expected when TLSv1.3 is negotiated.
>
> Some of the issues that might be encountered are here:
>
> https://wiki.openssl.org/index.php/TLS1.3
>
> We have already seen a handful of issues. For example in this one an
> application has implemented a PSK callback. Due to the way PSK works in
> TLSv1.3 the callback can get called earlier in the process than in
> TLSv1.2. Suddenly in the presence of TLSv1.3 this particular application
> callback has started to crash (we don't know why yet):
>
> https://github.com/openssl/openssl/issues/6110
>

I'm having no joy with apache 2.4.33 which just tossed a sigILL :

Reading mod_ssl.so
t@1 (l@1) program terminated by signal ILL (illegal opcode)
0xffffffff70d97320: TLSv1_2_enc_data       :    .word            0xffffffff
Current function is ssl_init_ctx_protocol
   613       ctx = SSL_CTX_new(method);
(dbx) where

current thread: t@1
   [1] 0xffffffff70d97320(0x1002dc9d0, 0x0, 0x0, 0xfffffffffffffff8,
0x0, 0x1002dccf8), at 0xffffffff70d97320
   [2] SSL_CTX_new(0xffffffff70d942b8, 0x1002dc9d0, 0x3b40, 0x2,
0xffffffff742619fc, 0xffffffff74367460), at 0xffffffff7424bc00
=>[3] ssl_init_ctx_protocol(s = 0x10026ddc0, p = 0x1001f8a68, ptemp =
0x100228c68, mctx = 0x1002be698), line 613 in "ssl_engine_init.c"
   [4] ssl_init_ctx(s = 0x10026ddc0, p = 0x1001f8a68, ptemp =
0x100228c68, mctx = 0x1002be698), line 1076 in "ssl_engine_init.c"
   [5] ssl_init_server_ctx(s = 0x10026ddc0, p = 0x1001f8a68, ptemp =
0x100228c68, sc = 0x1002be658, pphrases = 0x1002b51a0), line 1740 in
"ssl_engine_init.c"
   [6] ssl_init_ConfigureServer(s = 0x10026ddc0, p = 0x1001f8a68, ptemp
= 0x100228c68, sc = 0x1002be658, pphrases = 0x1002b51a0), line 1842 in
"ssl_engine_init.c"
   [7] ssl_init_Module(p = 0x1001f8a68, plog = 0x100226c58, ptemp =
0x100228c68, base_server = 0x10022ac78), line 369 in "ssl_engine_init.c"
   [8] ap_run_post_config(pconf = 0x1001f8a68, plog = 0x100226c58, ptemp
= 0x100228c68, s = 0x10022ac78), at 0x10007d094
   [9] main(argc = 3, argv = 0xffffffff7ffff6d8), line 739 in "main.c"
(dbx) list
   613       ctx = SSL_CTX_new(method);
   614
   615       mctx->ssl_ctx = ctx;
   616
   617       SSL_CTX_set_options(ctx, SSL_OP_ALL);
   618
   619   #if OPENSSL_VERSION_NUMBER < 0x10100000L
   620       /* always disable SSLv2, as per RFC 6176 */
   621       SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
   622
(dbx)

I'm digging around in there now ...

(dbx) listi 612, 613
   612   #endif
   613       ctx = SSL_CTX_new(method);
0xffffffff6e689b60: ssl_init_ctx_protocol+0x0330:       ldx      [%fp +
1991], %o0
0xffffffff6e689b64: ssl_init_ctx_protocol+0x0334:       call
_PROCEDURE_LINKAGE_TABLE_+0x1160 [PLT] ! 0xffffffff6e9afa60
0xffffffff6e689b68: ssl_init_ctx_protocol+0x0338:       nop
0xffffffff6e689b6c: ssl_init_ctx_protocol+0x033c:       mov      %o0, %o1
0xffffffff6e689b70: ssl_init_ctx_protocol+0x0340:       stx      %o1,
[%fp + 1999]

(dbx) print method
method = 0xffffffff70d942b8
(dbx) x 0xffffffff70d942b8/8x
0xffffffff70d942b8: DTLSv1_2_enc_data+0x0400:    0x0001 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000 0x0000
(dbx)
(dbx) x 0xffffffff6e9afa60/16x
0xffffffff6e9afa60: _PROCEDURE_LINKAGE_TABLE_+0x1160 [PLT]:      0x0100
0x0000 0x0b22 0xf6d1 0x8239 0x60bf 0x81c0 0x6000
0xffffffff6e9afa70: _PROCEDURE_LINKAGE_TABLE_+0x1170 [PLT]:      0x0100
0x0000 0x0100 0x0000 0x0100 0x0000 0x0100 0x0000
(dbx)

no idea why an illegal opcode slipped into the mix here but I may revert
back to 1.1.0h and do a sanity check, run httpd inside the debugger or
at least the foregorund and then try 1.1.1-pre5 again. I don't want to
have to unwind frames here and try to figure out why that call was sick.

oodles of fun.

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

Re: Call for testing TLS 1.3

OpenSSL - User mailing list
In reply to this post by Viktor Dukhovni
>    Interoperability issues with middle-boxes or existing software written for TLS 1.2.
 
Facebook, Google, and Mozilla did lots of testing with TLS 1.3 and middleboxes.  If something was missed, the whole Internet will have problems.  Existing software is the question we are trying to answer.

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

Re: Call for testing TLS 1.3

John Jiang
In reply to this post by Kurt Roeckx
Hi,
If just using s_server and s_client, can I test the TLS 1.3 features, likes HelloRetryRequest and resumption?

2018-04-29 18:43 GMT+08:00 Kurt Roeckx <[hidden email]>:
The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
1.3 brings a lot of changes that might cause incompatibility. For
an overview see https://wiki.openssl.org/index.php/TLS1.3

We are considering if we should enable TLS 1.3 by default or not,
or when it should be enabled. For that, we would like to know how
applications behave with the latest beta release.

When testing this, it's important that both sides of the
connection support the same TLS 1.3 draft version. OpenSSL
currently implements draft 26. We would like to see tests
for OpenSSL acting as client and server.

https://github.com/tlswg/tls13-spec/wiki/Implementations lists
other TLS 1.3 implementations and the draft they currently
support. Note that the versions listed there might not be for the
latest release. It also lists some https test servers.

We would really like to see a diverse set of applictions being
tested. Please report any results you have to us.


Kurt

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


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

Re: Call for testing TLS 1.3

Matt Caswell-2


On 23/05/18 12:39, John Jiang wrote:
> Hi,
> If just using s_server and s_client, can I test the TLS 1.3 features,
> likes HelloRetryRequest and resumption?

Yes.

To create a normal (full handshake) TLSv1.3 connection just use
s_server/s_client in the normal way, e.g.

$ openssl s_server -cert cert.pem -key key.pem
$ openssl s_client

To test resumption first create a full handshake TLSv1.3 connection and
save the session:

$ openssl s_server -cert cert.pem -key key.pem
$ openssl s_client -sess_out session.pem

Close the s_client instance by entering "Q" followed by enter. Then
(without closing the s_server instance) resume the session:

$ openssl s_client -sess_in session.pem


A HelloRetryRequest will occur if the key share provided by the client
is not acceptable to the server. By default the client will send an
X25519 key share, so if the server does not accept that group then an
HRR will result, e.g.

$ openssl s_server -cert cert.pem -key key.pem -groups P-256
$ openssl s_client


Of course a HelloRetryRequest all happens at the protocol layer and is
invisible as far as a user of the command line apps is concerned. You
will have to look at what happens "on the wire" to actually see it in
action - for example by using wireshark. Alternatively you can compile
OpenSSL with the "enable-ssl-trace" option, and pass the "-trace" flag
to s_server or s_client to see what protocol messages are being exchanged.

Matt



>
> 2018-04-29 18:43 GMT+08:00 Kurt Roeckx <[hidden email]
> <mailto:[hidden email]>>:
>
>     The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
>     1.3 brings a lot of changes that might cause incompatibility. For
>     an overview see https://wiki.openssl.org/index.php/TLS1.3
>     <https://wiki.openssl.org/index.php/TLS1.3>
>
>     We are considering if we should enable TLS 1.3 by default or not,
>     or when it should be enabled. For that, we would like to know how
>     applications behave with the latest beta release.
>
>     When testing this, it's important that both sides of the
>     connection support the same TLS 1.3 draft version. OpenSSL
>     currently implements draft 26. We would like to see tests
>     for OpenSSL acting as client and server.
>
>     https://github.com/tlswg/tls13-spec/wiki/Implementations
>     <https://github.com/tlswg/tls13-spec/wiki/Implementations> lists
>     other TLS 1.3 implementations and the draft they currently
>     support. Note that the versions listed there might not be for the
>     latest release. It also lists some https test servers.
>
>     We would really like to see a diverse set of applictions being
>     tested. Please report any results you have to us.
>
>
>     Kurt
>
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Call for testing TLS 1.3

John Jiang
Hi Matt,
Thanks for your reply!

2018-05-23 20:33 GMT+08:00 Matt Caswell <[hidden email]>:

To test resumption first create a full handshake TLSv1.3 connection and
save the session:

$ openssl s_server -cert cert.pem -key key.pem
$ openssl s_client -sess_out session.pem

Close the s_client instance by entering "Q" followed by enter. Then
(without closing the s_server instance) resume the session:

$ openssl s_client -sess_in session.pem
This way looks the same to test resumption on TLS 1.2.

The followings are some logs from my test.
The first connection:
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID:
    Session-ID-ctx:
    Master-Key: B4A20A467729A8179ECE5912AD87A0E5A784B8573A6F98CB414498142A10A37593B10DE254197A98E05CE65BDD664776
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1527153377
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

The second connection:
---
Reused, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 601F249C2033D5E5DF23D3380E6A2D81B335AF420D59849BB2023C415D0553C5
    Session-ID-ctx:
    Master-Key: 68695BD547856C14E04C747CE884F876B1564DADC66F28CD24B95DF3240FE0C0F93F59ED650B5EE45F6D3EA40A71C993
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 54 03 c8 0e e6 75 f3 ef-3f 7a 73 89 bc 87 69 ab   T....u..?zs...i.
    0010 - cf e6 ff d1 f9 d8 24 36-0d e5 67 52 30 7c ea 0c   ......$6..gR0|..
    0020 - c8 a2 67 ad 24 f6 29 cc-2c 95 48 36 e8 87 f6 4e   ..g.$.).,.H6...N
    0030 - c1 e8 44 a7 49 9d d6 61-36 32 37 80 01 1a 67 38   ..D.I..a627...g8
    0040 - ee b7 fb 83 d8 fc 66 69-51 29 3e c4 81 38 c5 2f   ......fiQ)>..8./
    0050 - 62 a2 fe 65 76 20 91 b4-fb 7b e3 eb 06 fa b7 d6   b..ev ...{......
    0060 - 1a 1e 2e b5 e0 ea c1 a3-d2 bf 12 bf 38 94 29 10   ............8.).
    0070 - 79 52 de 5d ef 30 d6 a7-01 a5 74 05 69 d1 31 61   yR.].0....t.i.1a
    0080 - a8 05 ac 83 d1 ab 17 82-c0 cc 1d 23 96 4e d2 af   ...........#.N..
    0090 - 74 56 aa f2 24 8c 02 f9-90 b3 e1 65 8f 81 12 a1   tV..$......e....
    00a0 - 79 36 72 a1 cf 0e a7 f0-fb b5 d0 42 81 5f ca 13   y6r........B._..
    00b0 - 24 97 a3 92 40 07 bd 5b-2c 3e 9d e8 af 3e f0 56   $...@..[,>...>.V
    00c0 - 9d 00 86 b2 30 fe 4b 68-c0 2e 17 d6 aa a7 5f 5b   ....0.Kh......_[
    00d0 - 3f 0f 30 81 a4 2b a1 fd-f6 b5 8c 3c 4e 03 cb de   ?.0..+.....<N...

    Start Time: 1527153377
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

Should I see PSK identity here? Or, it is the TLS session ticket.

 
A HelloRetryRequest will occur if the key share provided by the client
is not acceptable to the server. By default the client will send an
X25519 key share, so if the server does not accept that group then an
HRR will result, e.g.

$ openssl s_server -cert cert.pem -key key.pem -groups P-256
$ openssl s_client
It looks option "-groups" just specifies the most preferable named groups,
but other groups still could be negotiated. Right?


Of course a HelloRetryRequest all happens at the protocol layer and is
invisible as far as a user of the command line apps is concerned. You
will have to look at what happens "on the wire" to actually see it in
action - for example by using wireshark. Alternatively you can compile
OpenSSL with the "enable-ssl-trace" option, and pass the "-trace" flag
to s_server or s_client to see what protocol messages are being exchanged.
I found interesting things from trace logs.

BTW, the TLS 1.3 wiki [1] stats that the TLS 1.3 cipher suites are named:
TLS13-AES-256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-128-GCM-SHA256
TLS13-AES-128-CCM-8-SHA256
TLS13-AES-128-CCM-SHA256
But with version 1.1.1-pre6, they are using the formal names,
like TLS_AES_256_GCM_SHA384.

Thanks!
 

Matt



>
> 2018-04-29 18:43 GMT+08:00 Kurt Roeckx <[hidden email]
> <mailto:[hidden email]>>:
>
>     The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
>     1.3 brings a lot of changes that might cause incompatibility. For
>     an overview see https://wiki.openssl.org/index.php/TLS1.3
>     <https://wiki.openssl.org/index.php/TLS1.3>
>
>     We are considering if we should enable TLS 1.3 by default or not,
>     or when it should be enabled. For that, we would like to know how
>     applications behave with the latest beta release.
>
>     When testing this, it's important that both sides of the
>     connection support the same TLS 1.3 draft version. OpenSSL
>     currently implements draft 26. We would like to see tests
>     for OpenSSL acting as client and server.
>
>     https://github.com/tlswg/tls13-spec/wiki/Implementations
>     <https://github.com/tlswg/tls13-spec/wiki/Implementations> lists
>     other TLS 1.3 implementations and the draft they currently
>     support. Note that the versions listed there might not be for the
>     latest release. It also lists some https test servers.
>
>     We would really like to see a diverse set of applictions being
>     tested. Please report any results you have to us.
>
>
>     Kurt
>
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

Re: Call for testing TLS 1.3

Matt Caswell-2


On 24/05/18 10:58, John Jiang wrote:
> Should I see PSK identity here? Or, it is the TLS session ticket.

It's the session ticket.


>     A HelloRetryRequest will occur if the key share provided by the client
>     is not acceptable to the server. By default the client will send an
>     X25519 key share, so if the server does not accept that group then an
>     HRR will result, e.g.
>
>     $ openssl s_server -cert cert.pem -key key.pem -groups P-256
>     $ openssl s_client
>
> It looks option "-groups" just specifies the most preferable named groups,
> but other groups still could be negotiated. Right?

No, it restricts the groups acceptable to the server.

>
> I found interesting things from trace logs.
>
> BTW, the TLS 1.3 wiki [1] stats that the TLS 1.3 cipher suites are named:
> TLS13-AES-256-GCM-SHA384
> TLS13-CHACHA20-POLY1305-SHA256
> TLS13-AES-128-GCM-SHA256
> TLS13-AES-128-CCM-8-SHA256
> TLS13-AES-128-CCM-SHA256
> But with version 1.1.1-pre6, they are using the formal names,
> like TLS_AES_256_GCM_SHA384.

Ah, right thanks - we renamed them to the standard names a while ago. I
fixed the wiki.

Matt



>
> [1] https://wiki.openssl.org/index.php/TLS1.3
>
> Thanks!
>  
>
>
>     Matt
>
>
>
>     >
>     > 2018-04-29 18:43 GMT+08:00 Kurt Roeckx <[hidden email] <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>>:
>     >
>     >     The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
>     >     1.3 brings a lot of changes that might cause incompatibility. For
>     >     an overview see https://wiki.openssl.org/index.php/TLS1.3
>     <https://wiki.openssl.org/index.php/TLS1.3>
>     >     <https://wiki.openssl.org/index.php/TLS1.3
>     <https://wiki.openssl.org/index.php/TLS1.3>>
>     >
>     >     We are considering if we should enable TLS 1.3 by default or not,
>     >     or when it should be enabled. For that, we would like to know how
>     >     applications behave with the latest beta release.
>     >
>     >     When testing this, it's important that both sides of the
>     >     connection support the same TLS 1.3 draft version. OpenSSL
>     >     currently implements draft 26. We would like to see tests
>     >     for OpenSSL acting as client and server.
>     >
>     >     https://github.com/tlswg/tls13-spec/wiki/Implementations
>     <https://github.com/tlswg/tls13-spec/wiki/Implementations>
>     >     <https://github.com/tlswg/tls13-spec/wiki/Implementations
>     <https://github.com/tlswg/tls13-spec/wiki/Implementations>> lists
>     >     other TLS 1.3 implementations and the draft they currently
>     >     support. Note that the versions listed there might not be for the
>     >     latest release. It also lists some https test servers.
>     >
>     >     We would really like to see a diverse set of applictions being
>     >     tested. Please report any results you have to us.
>     >
>     >
>     >     Kurt
>     >
>     >     --
>     >     openssl-users mailing list
>     >     To unsubscribe:
>     >     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>     >     <https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>>
>     >
>     >
>     >
>     >
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Call for testing TLS 1.3

Jouni Malinen-4
In reply to this post by Kurt Roeckx
On Sun, Apr 29, 2018 at 12:43:26PM +0200, Kurt Roeckx wrote:
> We are considering if we should enable TLS 1.3 by default or not,
> or when it should be enabled. For that, we would like to know how
> applications behave with the latest beta release.

It looks like couple of TLS 1.3 changes result in breaking functionality
for various EAP methods that are based on TLS unless significant changes
in both the EAP method definition and implementations are done before
enabling the new TLS version. This seems to have an impact to at least
EAP-TLS, EAP-PEAP, EAP-TTLS, and EAP-FAST.

As far as wpa_supplicant (EAP peer) and hostapd (EAP server)
implementations are concerned, I've prepared changes to make EAP-TLS
work with TLS 1.3, but the other EAP methods are still failing for
various known (and to some extend, unknown) issues. Anyway, I'm
currently explicitly disabling TLS 1.3 support with OpenSSL by default
in these application due to these issues and the expected
interoperability issues and as such, the OpenSSL 1.1.1 release default
behavior regarding TLS 1.3 support should not have impact for these
applications. That said, other EAP implementations may want to do
something similar or face possibility of breaking functionality if
OpenSSL 1.1.1 does go out with TLS 1.3 enabled by default and both ends
of the EAP connection have TLS 1.3 enabled.

--
Jouni Malinen                                            PGP id EFC895FA
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Call for testing TLS 1.3

OpenSSL - User mailing list
(For those who are not Jouni, there is some spec work needed for
TLS 1.3/EAP integration as well, occurring in the IETF EMU working group.
I assume Jouni is on the mailing list and knows this already)

-Ben

On Mon, May 28, 2018 at 03:28:13PM +0300, Jouni Malinen wrote:

> On Sun, Apr 29, 2018 at 12:43:26PM +0200, Kurt Roeckx wrote:
> > We are considering if we should enable TLS 1.3 by default or not,
> > or when it should be enabled. For that, we would like to know how
> > applications behave with the latest beta release.
>
> It looks like couple of TLS 1.3 changes result in breaking functionality
> for various EAP methods that are based on TLS unless significant changes
> in both the EAP method definition and implementations are done before
> enabling the new TLS version. This seems to have an impact to at least
> EAP-TLS, EAP-PEAP, EAP-TTLS, and EAP-FAST.
>
> As far as wpa_supplicant (EAP peer) and hostapd (EAP server)
> implementations are concerned, I've prepared changes to make EAP-TLS
> work with TLS 1.3, but the other EAP methods are still failing for
> various known (and to some extend, unknown) issues. Anyway, I'm
> currently explicitly disabling TLS 1.3 support with OpenSSL by default
> in these application due to these issues and the expected
> interoperability issues and as such, the OpenSSL 1.1.1 release default
> behavior regarding TLS 1.3 support should not have impact for these
> applications. That said, other EAP implementations may want to do
> something similar or face possibility of breaking functionality if
> OpenSSL 1.1.1 does go out with TLS 1.3 enabled by default and both ends
> of the EAP connection have TLS 1.3 enabled.
>
> --
> Jouni Malinen                                            PGP id EFC895FA
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Call for testing TLS 1.3

John Jiang
In reply to this post by Matt Caswell-2
Is it possible to check Key/IV update feature via these tools?
Thanks!

2018-05-23 20:33 GMT+08:00 Matt Caswell <[hidden email]>:


On 23/05/18 12:39, John Jiang wrote:
> Hi,
> If just using s_server and s_client, can I test the TLS 1.3 features,
> likes HelloRetryRequest and resumption?

Yes.

To create a normal (full handshake) TLSv1.3 connection just use
s_server/s_client in the normal way, e.g.

$ openssl s_server -cert cert.pem -key key.pem
$ openssl s_client

To test resumption first create a full handshake TLSv1.3 connection and
save the session:

$ openssl s_server -cert cert.pem -key key.pem
$ openssl s_client -sess_out session.pem

Close the s_client instance by entering "Q" followed by enter. Then
(without closing the s_server instance) resume the session:

$ openssl s_client -sess_in session.pem


A HelloRetryRequest will occur if the key share provided by the client
is not acceptable to the server. By default the client will send an
X25519 key share, so if the server does not accept that group then an
HRR will result, e.g.

$ openssl s_server -cert cert.pem -key key.pem -groups P-256
$ openssl s_client


Of course a HelloRetryRequest all happens at the protocol layer and is
invisible as far as a user of the command line apps is concerned. You
will have to look at what happens "on the wire" to actually see it in
action - for example by using wireshark. Alternatively you can compile
OpenSSL with the "enable-ssl-trace" option, and pass the "-trace" flag
to s_server or s_client to see what protocol messages are being exchanged.

Matt



>
> 2018-04-29 18:43 GMT+08:00 Kurt Roeckx <[hidden email]
> <mailto:[hidden email]>>:
>
>     The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
>     1.3 brings a lot of changes that might cause incompatibility. For
>     an overview see https://wiki.openssl.org/index.php/TLS1.3
>     <https://wiki.openssl.org/index.php/TLS1.3>
>
>     We are considering if we should enable TLS 1.3 by default or not,
>     or when it should be enabled. For that, we would like to know how
>     applications behave with the latest beta release.
>
>     When testing this, it's important that both sides of the
>     connection support the same TLS 1.3 draft version. OpenSSL
>     currently implements draft 26. We would like to see tests
>     for OpenSSL acting as client and server.
>
>     https://github.com/tlswg/tls13-spec/wiki/Implementations
>     <https://github.com/tlswg/tls13-spec/wiki/Implementations> lists
>     other TLS 1.3 implementations and the draft they currently
>     support. Note that the versions listed there might not be for the
>     latest release. It also lists some https test servers.
>
>     We would really like to see a diverse set of applictions being
>     tested. Please report any results you have to us.
>
>
>     Kurt
>
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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