You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dennis Clarke <dc...@blastwave.org> on 2018/06/15 20:03:16 UTC
TLS 1.3 seems to OVERwork with httpd-trunk rev 1833619
Thank you Yann Ylavic !
Sure enough no patch was needed and trunk compiles up neatly and just a
bit noisey about a few odd warnings ... nothing too interesting.
So then ... as I reported earlier I can get reasonable handshake and
TLSv1.3 traffic with cipher TLS_AES_128_GCM_SHA256 from the Mozilla
test site. Claims to be Draft 28 of TLS 1.3.
I can now do the exact same with httpd-trunk rev 1833619 and there is no
need to specify "-tls1_3" because nothing else is supported. However we
get a double bounce ( for lack of a better work ) in the transitory
SSL_connect:SSL negotiation finished successfully state of the exchange:
$ openssl s_client -connect beta.tls13.net:443
CONNECTED(00000004)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = *.tls13.net
verify return:1
---
Certificate chain
0 s:CN = *.tls13.net
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGAjCCBOqgAwIBAgISA3lbcjYuS0tUnszwWevJIyQaMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
.
.<snip>
.
ySsGXKitxY8HofArokYLygbwFVe3A1H4cyWwLQk+vHXDyYJWqh78UFhXS2A6kjwg
1vNRzOHTLCQfYIoWw8CePPeKTbxc7sr3zRBhNCYN/5rhzniBymc72wDcPOXpXSB3
PrK8bh7S
-----END CERTIFICATE-----
subject=CN = *.tls13.net
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: X25519, 253 bits
---
SSL handshake has read 3281 bytes and written 400 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 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:
5AABE86A1DE9EA6F2EA88AC980C27DAFFC643B13B3A99D63E24BE7A848C71FBCFBDC8EEDFE93EEF1B7D1AFFA38CFDB27
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1529092107
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
read R BLOCK
read R BLOCK
GET
HTTP/1.1 400 Bad Request
Date: Fri, 15 Jun 2018 19:48:46 GMT
Server: Apache/2.5.1-dev (Unix) OpenSSL/1.1.1-pre7
Strict-Transport-Security: max-age=7776000; includeSubdomains;
Last-Modified: Mon, 28 May 2018 19:03:30 GMT
ETag: "2b0-56d48c600191c"
Accept-Ranges: bytes
Content-Length: 688
Connection: close
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd" >
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Dennis Clarke at Blastwave and
GenUNIX with vi and coffee">
<meta name="CopyRight" content="Copyright 2002-2018 blastwave.org
Inc.">
<meta http-equiv="Pragma" content="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="Tue, 18 Mar 1997 00:00:00 GMT">
<meta http-equiv="Cache-Control" content="max-age=0, must-revalidate">
<title>error code 400 bad request</title>
</head>
<body>
error code 400 bad request ... that is all for now
</body>
</html>
closed
$
So that looks great and the ssl_error_log claims all is happy.
Seems to issue "read R BLOCK" twice for some odd reason.
A closer look with "-state -debug" reveals that we get multiple
"SSL_connect:SSL negotiation finished successfully" before ever
accepting a GET/POST/FOO from the client.
.
.
.
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 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:
7B8968F4FAC7878EDD51482F852CDFB38D95C8D27A8B9B9C6038F031387F34A61EF8DF239B8B38FC4163A2987453E90F
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1529092424
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
read from 0x100851cd0 [0x100857983] (5 bytes => 5 (0x5))
0000 - 17 03 03 01 23 ....#
read from 0x100851cd0 [0x100857988] (291 bytes => 291 (0x123))
0000 - 90 61 65 22 28 de ed 16-48 01 c4 c9 24 c4 95 c3 .ae"(...H...$...
.
.<snip>
.
0110 - 02 57 51 bc d7 0d 2c 64-a3 9d db 21 cc 2e 7b 1c .WQ...,d...!..{.
0120 - a8 a7 ba ...
SSL_connect:SSL negotiation finished successfully
SSL_connect:SSL negotiation finished successfully
SSL_connect:SSLv3/TLS read server session ticket
read R BLOCK
read from 0x100851cd0 [0x100857983] (5 bytes => 5 (0x5))
0000 - 17 03 03 01 23 ....#
read from 0x100851cd0 [0x100857988] (291 bytes => 291 (0x123))
0000 - 0f 7a 1f 3b 88 6d cc 62-a3 03 15 49 e8 10 32 90 .z.;.m.b...I..2.
0010 - dc c4 03 11 60 8f 67 aa-af 63 c8 04 43 4e a7 c1 ....`.g..c..CN..
.
.<snip>
.
0100 - a0 0c de 56 d4 98 19 f2-bc 03 61 da cc d0 e7 4f ...V......a....O
0110 - 33 eb ba 40 21 4f 50 1a-70 3b 9a e4 55 d1 38 8c 3..@!OP.p;..U.8.
0120 - 85 a3 28 ..(
SSL_connect:SSL negotiation finished successfully
SSL_connect:SSL negotiation finished successfully
SSL_connect:SSLv3/TLS read server session ticket
read R BLOCK
GET
write to 0x100851cd0 [0x10085bae3] (26 bytes => 26 (0x1A))
.
.
.
etc etc
That seems odd. The Mozilla test site tls13.crypto.mozilla.org does not
do that behavior.
Dennis
ps: seems to work fine with a Firefox beta browser also provided that
security.tls.version.max support "4".
HTTP_HOST: beta.tls13.net
HTTP_USER_AGENT: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101
Firefox/61.0
SERVER_NAME: beta.tls13.net
SERVER_PORT: 443
SERVER_PROTOCOL: HTTP/1.1
SERVER_SIGNATURE: <address>Apache/2.5.1-dev (Unix) OpenSSL/1.1.1-pre7
Server at beta.tls13.net Port 443</address>
SERVER_SOFTWARE: Apache/2.5.1-dev (Unix) OpenSSL/1.1.1-pre7
SSL_CIPHER: TLS_AES_256_GCM_SHA384
SSL_CIPHER_ALGKEYSIZE: 256
SSL_CIPHER_EXPORT: false
SSL_CIPHER_USEKEYSIZE: 256
SSL_CLIENT_VERIFY: NONE
SSL_COMPRESS_METHOD: NULL
SSL_PROTOCOL: TLSv1.3
SSL_SECURE_RENEG: false
SSL_SERVER_A_KEY: rsaEncryption
SSL_SERVER_A_SIG: sha256WithRSAEncryption
etc etc
Re: TLS 1.3 seems to OVERwork with httpd-trunk rev 1833619
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jun 20, 2018 at 8:29 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> Since it happens with s_client <=> s_server (no third party), maybe
> someone can ask the openssl team why?
I just asked on their users@ list:
https://mta.openssl.org/pipermail/openssl-users/2018-June/008229.html
Re: TLS 1.3 seems to OVERwork with httpd-trunk rev 1833619
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Jun 15, 2018 at 10:03 PM, Dennis Clarke <dc...@blastwave.org> wrote:
>
> Seems to issue "read R BLOCK" twice for some odd reason.
Indeed, same here/
>
> A closer look with "-state -debug" reveals that we get multiple
> "SSL_connect:SSL negotiation finished successfully" before ever
> accepting a GET/POST/FOO from the client.
[]
> SSL_connect:SSLv3/TLS read server session ticket
[]
> SSL_connect:SSLv3/TLS read server session ticket
This happens twice, and in gdb it's entirely in the openssl handshake
state machine, without httpd to take the hand in between.
Btw, same when connecting "openssl s_client" to "openssl s_server"
(-state -debug on both)
It seems to be part of the session ticket mechanism, possibly only
when sessions are not resumed by the client, dunno.
>
> That seems odd. The Mozilla test site tls13.crypto.mozilla.org does not do
> that behavior.
I didn't test that, but it may be an openssl "feature" after all :)
Since it happens with s_client <=> s_server (no third party), maybe
someone can ask the openssl team why?
I've heard/thought that TLS-1.3 sessions were designed for zero
round-trip, but quite possibly I missed something...
Thanks anyway for testing/debugging all this Dennis.
Regards,
Yann.