git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TLS 1.3 seems to OVERwork with httpd-trunk rev 1833619



Same behavior "read R BLOCK" twice on Windows with trunk from today (1833659):




On Friday 15/06/2018 at 22:03, Dennis Clarke  wrote:


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










( ! ) Warning: include(msgfooter.php): failed to open stream: No such file or directory in /var/www/git/apache2-developers/msg04197.html on line 328
Call Stack
#TimeMemoryFunctionLocation
10.0008372664{main}( ).../msg04197.html:0

( ! ) Warning: include(): Failed opening 'msgfooter.php' for inclusion (include_path='.:/var/www/git') in /var/www/git/apache2-developers/msg04197.html on line 328
Call Stack
#TimeMemoryFunctionLocation
10.0008372664{main}( ).../msg04197.html:0