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 ?
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.
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.
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
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.
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.
changing this to ver 2.5-head given that I am running a build from the trunk.
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
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.