Bug 62413

Summary: SSLProtocol: TLSv1.3 appears to loop and issue "read R BLOCK" twice
Product: Apache httpd-2 Reporter: Dennis Clarke <dclarke>
Component: mod_sslAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P2    
Version: 2.5-HEAD   
Target Milestone: ---   
Hardware: Sun   
OS: Solaris   

Description Dennis Clarke 2018-05-28 08:00:54 UTC
Not sure if this is not yet allowed however I am trying to do some
testing with openssl 1.1.1 beta thus : 

# /usr/local/bin/openssl version 
OpenSSL 1.1.1-pre6 (beta) 1 May 2018

Which does support TLS 1.3 class ciphers : 

# /usr/local/bin/openssl ciphers -V -tls1_3 -s 
          0x13,0x02 - TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
          0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
          0x13,0x01 - TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD


However an attempt to do so results in : 

AH00526: Syntax error on line 19 of /usr/local/www/conf/extra/httpd-ssl.conf:
SSLProtocol: Illegal protocol 'TLSv1.3'


Perhaps I need to rebuild apr, apr-util and httpd again ?
Comment 1 Eric Covener 2018-05-28 11:11:51 UTC
Does it work with All instead of naming TLS1.3?

2.4 is not aware of 1.3, but when you specify All there's a chance it will be in there at runtime. In trunk, it is only aware of 1.3 as an arg if compiled against a 1.3-capable openssl.
Comment 2 Dennis Clarke 2018-05-28 18:18:34 UTC
Reasonable idea however using "SSLProtocol All" now allows TLS 1.0 and
TLS 1.1 and also TLS 1.2 but nothing for TLS 1.3 : 

$ /usr/local/bin/openssl s_client -connect www.tls13.net:443 -tls1_3


no connection at all.


However TLS 1.2 is fine : 

$ /usr/local/bin/openssl s_client -connect www.tls13.net:443 -tls1_2
CONNECTED(00000004)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
---
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-----
.
.
.
-----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 3396 bytes and written 309 bytes
Verification error: unable to get local issuer certificate
---
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 

I get similar responses using -tls1_1 and just -tls1 and in every case the
exact same cipher ECDHE-RSA-AES256-SHA.
Comment 3 Dennis Clarke 2018-05-28 19:20:05 UTC
OKay .. so "SSLProtocol All" really didn't help much and what I see in the
logs is fairly clear if I try to connect with TLS 1.3 :


[Mon May 28 19:15:47.338475 2018] [ssl:info] [pid 21764:tid 27] [client 66.225.xxx.xxx:35350] AH01964: Connection to child 216 established (server www.tls13.net:443)

[Mon May 28 19:15:47.339328 2018] [ssl:info] [pid 21764:tid 27] [client 66.225.xxx.xxx:35350] AH02008: SSL library error 1 in handshake (server www.tls13.net:443)

[Mon May 28 19:15:47.339478 2018] [ssl:info] [pid 21764:tid 27] SSL Library Error: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol

[Mon May 28 19:15:47.339507 2018] [ssl:info] [pid 21764:tid 27] [client 66.225.xxx.xxx:35350] AH01998: Connection closed to child 216 with abortive shutdown (server www.tls13.net:443)


So TLS 1.3 is not supported at all even with OpenSSL 1.1.1
Comment 4 Dennis Clarke 2018-05-28 19:38:14 UTC
OKay .. even better I see the changes in trunk from Thu Mar 29 2018 :

https://svn.apache.org/viewvc?view=revision&revision=1827992

I will do a compile from the trunk and retest.
Comment 5 Dennis Clarke 2018-06-01 06:44:28 UTC
per 62417 I have a running apache 2.5.1 trunk with OpenSSL 1.1.1-pre6 and that
seems to support TLS v1.3 however I have yet to get a browser to connect with
it. Maybe a ciphersuite issue as my Mozilla browser connects to the test
site https://tls13.crypto.mozilla.org/  just fine. 

So this may be a config issue with httpd-ssl.conf 

I note that SSLProtocol +TLSv1.3 -TLSv1.2 -SSLv3 -SSLv2 -TLSv1.1 -TLSv1  seems
to work fine but only the openssl s_client can reach the server and not a 
Mozilla browser.
Comment 6 Dennis Clarke 2018-06-01 17:03:09 UTC
changing this to ver 2.5-head given that I am running a build from the trunk.
Comment 7 Dennis Clarke 2018-06-19 19:07:42 UTC
Must update this given that I have some help from Yann Ylavic and 
now https://beta.tls13.net seems to be serving TLS v1.3 well and 
fine with one exception.

---- from the maillist dev@httpd.apache.org ----

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
Comment 8 Dennis Clarke 2018-06-21 02:51:02 UTC

Yann Ylavic and Rich Salz discussed this in the OpenSSL ml and 
this is a "feature" of the specification, not a bug :

https://mta.openssl.org/pipermail/openssl-users/2018-June/008237.html

Thus I will assume that httpd-trunk with OpenSSL 1.1.1-pre7 and whatever
follows is doing exactly what it is supposed to do with TLS v1.3.