Call for testing TLS 1.3

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
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