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

2018-06-20 Thread Yann Ylavic 
On Wed, Jun 20, 2018 at 8:29 PM, Yann Ylavic  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

2018-06-20 Thread Yann Ylavic 
On Fri, Jun 15, 2018 at 10:03 PM, Dennis Clarke  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.

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

2018-06-17 Thread Dennis Clarke 

On 06/17/2018 04:35 PM, Apache Lounge wrote:


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





Clearly there is a loop somewhere which is happening twice and may be
 because of some state variable not set corrected on entry to the loop.

Difficult to trace.

Dennis

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

2018-06-17 Thread Apache Lounge 



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(0004)
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
...
...
...
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

   
"http://www.w3.org/TR/html4/strict.dtd"; >



   
   
   

   
   
   content="max-age=0,  must-revalidate">

   error code 400 bad request


error code 400 bad request ... that is all for now


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))
 - 17 03 03 01 23#
read from 0x100851cd0 [0x100857988] (291 bytes => 291 (0x123))
 - 90 61 65 22 28 de ed 16-48 01 c4 c9 24 c4 95 c3
.ae"(...H...$...

...
...
...
0110 - 02 57 51 bc d7 0d 2c 64-a3 9d db 21 cc 2e 7b 1c
.WQ...,d...!..{.

0120 - a8 a7 ba