You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Dennis Clarke <dc...@blastwave.org> on 2018/06/15 01:06:06 UTC
[users@httpd] Difficulties with testing TLS 1.3
Hello Apache folks :
So the process of testing TLS 1.3 shouldn't be black magic but here
I am wondering what is wrong. I have a beta site up running Apache trunk
build and OpenSSL 1.1.1-pre7 ( the latest atm ) and everything seems to
be just fine. I have Mozilla beta browser with security.tls.* settings
ready to handle TLS 1.3 and I can reach, render and see the test site at
https://tls13.crypto.mozilla.org/ just fine. It claims TLS 1.3 (draft
28) using NSS whereas my site https://beta.tls13.net can not be "seen"
via the same browser. The openssl s_client has no issues contacting both
sites and in both cases I do see TLS 1.3 protocol as supported however
cipher suite ( see https://wiki.mozilla.org/Security/Server_Side_TLS )
may be the issue. Not sure.
Here is what I see when using "s_client" to access the mozilla site :
$ openssl s_client -connect tls13.crypto.mozilla.org:443 -tls1_3
CONNECTED(00000003)
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.crypto.mozilla.org
verify return:1
---
Certificate chain
0 s:CN = tls13.crypto.mozilla.org
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-----
MIIFEzCCA/ugAwIBAgISBPOVEnB/CqyqLondZWg55Uz8MA0GCSqGSIb3DQEBCwUA
.
.<snip>
.
Ad+yYggR2Q==
-----END CERTIFICATE-----
subject=CN = tls13.crypto.mozilla.org
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 2974 bytes and written 316 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
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_128_GCM_SHA256
Session-ID:
Session-ID-ctx:
Master-Key:
7A97B0747961C13DDF4A533C8174262F9500157007EED04A98B5BCAA314D56A5
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1529024212
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
read R BLOCK
GET
HTTP/1.1 400 Bad Request
Date: Fri, 15 Jun 2018 00:57:36 GMT
Server: Apache
Strict-Transport-Security: max-age=63072000; includeSubdomains;
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
closed
tls13 $
All looks fine. The nice 400 error message is very okay.
The exact same thing to my test trunk Apache server claims odd
results :
$ openssl s_client -connect beta.tls13.net:443 -tls1_3
CONNECTED(00000003)
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
.
.<snip>
.
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 322 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:
42F400653B4C20603D96D1180E345439B941F696160A0B7BD7FF23077A111A1A899A6A43BCEE6172D00641597111FF39
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1529024399
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
read:errno=0
$
Well other than cipher what is the difference here ? Nothing obvious.
The ssl error_log ( set at level debug ) isn't helping here :
[Fri Jun 15 00:59:59.753533 2018] [ssl:info] [pid 2250:tid 27] [client
68.179.116.201:34466] AH01964: Connection to child 152 established
(server beta.tls13.net:443)
[Fri Jun 15 00:59:59.755714 2018] [ssl:debug] [pid 2250:tid 27]
ssl_engine_kernel.c(2297): [client 68.179.116.201:34466] AH02043: SSL
virtual host for servername beta.tls13.net found
[Fri Jun 15 00:59:59.788701 2018] [ssl:debug] [pid 2250:tid 27]
ssl_engine_kernel.c(2222): [client 68.179.116.201:34466] AH02041:
Protocol: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384 (256/256 bits)
[Fri Jun 15 00:59:59.788742 2018] [ssl:error] [pid 2250:tid 27] [client
68.179.116.201:34466] AH02042: rejecting client initiated renegotiation
[Fri Jun 15 00:59:59.789151 2018] [ssl:debug] [pid 2250:tid 27]
ssl_engine_io.c(1400): (130)Software caused connection abort: [client
68.179.116.201:34466] AH02007: SSL handshake interrupted by system
[Hint: Stop button pressed in browser?!]
[Fri Jun 15 00:59:59.789341 2018] [ssl:info] [pid 2250:tid 27] [client
68.179.116.201:34466] AH01998: Connection closed to child 152 with
abortive shutdown (server beta.tls13.net:443)
beta #
Weird.
Any thoughts would be greatly appreciated.
Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
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.
TLS 1.3 seems to OVERwork with httpd-trunk rev 1833619
Posted by Dennis Clarke <dc...@blastwave.org>.
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: [users@httpd] Difficulties with testing TLS 1.3
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Jun 15, 2018 at 10:09 AM, Yann Ylavic <yl...@gmail.com> wrote:
>> On Fri, Jun 15, 2018 at 9:38 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>> On Fri, Jun 15, 2018 at 8:59 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>>>> On Fri, Jun 15, 2018 at 3:06 AM, Dennis Clarke <dc...@blastwave.org> wrote:
>>>>>>
>>>>>> [Fri Jun 15 00:59:59.788742 2018] [ssl:error] [pid 2250:tid 27] [client
>>>>>> 68.179.116.201:34466] AH02042: rejecting client initiated renegotiation
>>>>
>>>> This suggests that with TLS 1.3, unlike with previous protocols, the
>>>> ssl_callback_Info callback is always called by openssl (some specific
>>>> extension only?). httpd is not prepared to that and thinks it's a
>>>> client renegotiation.
>>>>
>>>> I didn't look at TLS 1.3 yet, but something along this looks seems plausible.
>>>
>>> For instance, multiple session tickets might call the callback more than once:
>>> https://github.com/openssl/openssl/blob/master/ssl/statem/statem_srvr.c#L3785
>>>
>>> Since renegotiations are forbidden by TLS 1.3 in the first place
>>> (enforced by openssl probably), I think that the check for
>>> renegotiations should be disabled in our ssl_callback_Info (for TLS
>>> 1.3).
>
> Dennis, does the attached patch help?
Committed in http://svn.apache.org/r1833588 so updating to latest
trunk should be enough.
Re: [users@httpd] Difficulties with testing TLS 1.3
Posted by Yann Ylavic <yl...@gmail.com>.
> On Fri, Jun 15, 2018 at 9:38 AM, Yann Ylavic <yl...@gmail.com> wrote:
>> On Fri, Jun 15, 2018 at 8:59 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>>> On Fri, Jun 15, 2018 at 3:06 AM, Dennis Clarke <dc...@blastwave.org> wrote:
>>>>>
>>>>> [Fri Jun 15 00:59:59.788742 2018] [ssl:error] [pid 2250:tid 27] [client
>>>>> 68.179.116.201:34466] AH02042: rejecting client initiated renegotiation
>>>
>>> This suggests that with TLS 1.3, unlike with previous protocols, the
>>> ssl_callback_Info callback is always called by openssl (some specific
>>> extension only?). httpd is not prepared to that and thinks it's a
>>> client renegotiation.
>>>
>>> I didn't look at TLS 1.3 yet, but something along this looks seems plausible.
>>
>> For instance, multiple session tickets might call the callback more than once:
>> https://github.com/openssl/openssl/blob/master/ssl/statem/statem_srvr.c#L3785
>>
>> Since renegotiations are forbidden by TLS 1.3 in the first place
>> (enforced by openssl probably), I think that the check for
>> renegotiations should be disabled in our ssl_callback_Info (for TLS
>> 1.3).
Dennis, does the attached patch help?
Re: [users@httpd] Difficulties with testing TLS 1.3
Posted by Yann Ylavic <yl...@gmail.com>.
[CC-ing Dennis since he does not seem to be subscribed to dev@]
On Fri, Jun 15, 2018 at 9:38 AM, Yann Ylavic <yl...@gmail.com> wrote:
> On Fri, Jun 15, 2018 at 8:59 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>> On Fri, Jun 15, 2018 at 3:06 AM, Dennis Clarke <dc...@blastwave.org> wrote:
>>>>
>>>> [Fri Jun 15 00:59:59.788742 2018] [ssl:error] [pid 2250:tid 27] [client
>>>> 68.179.116.201:34466] AH02042: rejecting client initiated renegotiation
>>
>> This suggests that with TLS 1.3, unlike with previous protocols, the
>> ssl_callback_Info callback is always called by openssl (some specific
>> extension only?). httpd is not prepared to that and thinks it's a
>> client renegotiation.
>>
>> I didn't look at TLS 1.3 yet, but something along this looks seems plausible.
>
> For instance, multiple session tickets might call the callback more than once:
> https://github.com/openssl/openssl/blob/master/ssl/statem/statem_srvr.c#L3785
>
> Since renegotiations are forbidden by TLS 1.3 in the first place
> (enforced by openssl probably), I think that the check for
> renegotiations should be disabled in our ssl_callback_Info (for TLS
> 1.3).
Re: [users@httpd] Difficulties with testing TLS 1.3
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Jun 15, 2018 at 8:59 AM, Yann Ylavic <yl...@gmail.com> wrote:
>> On Fri, Jun 15, 2018 at 3:06 AM, Dennis Clarke <dc...@blastwave.org> wrote:
>>>
>>> [Fri Jun 15 00:59:59.788742 2018] [ssl:error] [pid 2250:tid 27] [client
>>> 68.179.116.201:34466] AH02042: rejecting client initiated renegotiation
>
> This suggests that with TLS 1.3, unlike with previous protocols, the
> ssl_callback_Info callback is always called by openssl (some specific
> extension only?). httpd is not prepared to that and thinks it's a
> client renegotiation.
>
> I didn't look at TLS 1.3 yet, but something along this looks seems plausible.
For instance, multiple session tickets might call the callback more than once:
https://github.com/openssl/openssl/blob/master/ssl/statem/statem_srvr.c#L3785
Since renegotiations are forbidden by TLS 1.3 in the first place
(enforced by openssl probably), I think that the check for
renegotiations should be disabled in our ssl_callback_Info (for TLS
1.3).
Re: [users@httpd] Difficulties with testing TLS 1.3
Posted by Yann Ylavic <yl...@gmail.com>.
> On Fri, Jun 15, 2018 at 3:06 AM, Dennis Clarke <dc...@blastwave.org> wrote:
>>
>> [Fri Jun 15 00:59:59.788742 2018] [ssl:error] [pid 2250:tid 27] [client
>> 68.179.116.201:34466] AH02042: rejecting client initiated renegotiation
This suggests that with TLS 1.3, unlike with previous protocols, the
ssl_callback_Info callback is always called by openssl (some specific
extension only?). httpd is not prepared to that and thinks it's a
client renegotiation.
I didn't look at TLS 1.3 yet, but something along this looks seems plausible.
Regards,
Yann.
Re: [users@httpd] Difficulties with testing TLS 1.3
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Dennis,
moving to dev@, more suited I think here.
On Fri, Jun 15, 2018 at 3:06 AM, Dennis Clarke <dc...@blastwave.org> wrote:
>
> Hello Apache folks :
>
> So the process of testing TLS 1.3 shouldn't be black magic but here
> I am wondering what is wrong. I have a beta site up running Apache trunk
> build and OpenSSL 1.1.1-pre7 ( the latest atm ) and everything seems to
> be just fine. I have Mozilla beta browser with security.tls.* settings
> ready to handle TLS 1.3 and I can reach, render and see the test site at
> https://tls13.crypto.mozilla.org/ just fine. It claims TLS 1.3 (draft
> 28) using NSS whereas my site https://beta.tls13.net can not be "seen"
> via the same browser. The openssl s_client has no issues contacting both
> sites and in both cases I do see TLS 1.3 protocol as supported however
> cipher suite ( see https://wiki.mozilla.org/Security/Server_Side_TLS )
> may be the issue. Not sure.
>
> Here is what I see when using "s_client" to access the mozilla site :
>
> $ openssl s_client -connect tls13.crypto.mozilla.org:443 -tls1_3
> CONNECTED(00000003)
> 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.crypto.mozilla.org
> verify return:1
> ---
> Certificate chain
> 0 s:CN = tls13.crypto.mozilla.org
> 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-----
> MIIFEzCCA/ugAwIBAgISBPOVEnB/CqyqLondZWg55Uz8MA0GCSqGSIb3DQEBCwUA
> .
> .<snip>
> .
> Ad+yYggR2Q==
> -----END CERTIFICATE-----
> subject=CN = tls13.crypto.mozilla.org
>
> 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 2974 bytes and written 316 bytes
> Verification: OK
> ---
> New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
> 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_128_GCM_SHA256
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> 7A97B0747961C13DDF4A533C8174262F9500157007EED04A98B5BCAA314D56A5
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1529024212
> Timeout : 7200 (sec)
> Verify return code: 0 (ok)
> Extended master secret: no
> ---
> read R BLOCK
> GET
> HTTP/1.1 400 Bad Request
> Date: Fri, 15 Jun 2018 00:57:36 GMT
> Server: Apache
> Strict-Transport-Security: max-age=63072000; includeSubdomains;
> Content-Length: 226
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>400 Bad Request</title>
> </head><body>
> <h1>Bad Request</h1>
> <p>Your browser sent a request that this server could not understand.<br />
> </p>
> </body></html>
> closed
> tls13 $
>
>
> All looks fine. The nice 400 error message is very okay.
>
>
> The exact same thing to my test trunk Apache server claims odd
> results :
>
>
> $ openssl s_client -connect beta.tls13.net:443 -tls1_3
> CONNECTED(00000003)
> 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
> .
> .<snip>
> .
> 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 322 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:
> 42F400653B4C20603D96D1180E345439B941F696160A0B7BD7FF23077A111A1A899A6A43BCEE6172D00641597111FF39
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1529024399
> Timeout : 7200 (sec)
> Verify return code: 0 (ok)
> Extended master secret: no
> ---
> read:errno=0
> $
>
>
> Well other than cipher what is the difference here ? Nothing obvious.
>
> The ssl error_log ( set at level debug ) isn't helping here :
>
>
> [Fri Jun 15 00:59:59.753533 2018] [ssl:info] [pid 2250:tid 27] [client
> 68.179.116.201:34466] AH01964: Connection to child 152 established (server
> beta.tls13.net:443)
>
> [Fri Jun 15 00:59:59.755714 2018] [ssl:debug] [pid 2250:tid 27]
> ssl_engine_kernel.c(2297): [client 68.179.116.201:34466] AH02043: SSL
> virtual host for servername beta.tls13.net found
>
> [Fri Jun 15 00:59:59.788701 2018] [ssl:debug] [pid 2250:tid 27]
> ssl_engine_kernel.c(2222): [client 68.179.116.201:34466] AH02041: Protocol:
> TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384 (256/256 bits)
>
> [Fri Jun 15 00:59:59.788742 2018] [ssl:error] [pid 2250:tid 27] [client
> 68.179.116.201:34466] AH02042: rejecting client initiated renegotiation
>
> [Fri Jun 15 00:59:59.789151 2018] [ssl:debug] [pid 2250:tid 27]
> ssl_engine_io.c(1400): (130)Software caused connection abort: [client
> 68.179.116.201:34466] AH02007: SSL handshake interrupted by system [Hint:
> Stop button pressed in browser?!]
>
> [Fri Jun 15 00:59:59.789341 2018] [ssl:info] [pid 2250:tid 27] [client
> 68.179.116.201:34466] AH01998: Connection closed to child 152 with abortive
> shutdown (server beta.tls13.net:443)
> beta #
>
>
> Weird.
>
>
> Any thoughts would be greatly appreciated.
>
>
> Dennis
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Difficulties with testing TLS 1.3
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Dennis,
moving to dev@, more suited I think here.
On Fri, Jun 15, 2018 at 3:06 AM, Dennis Clarke <dc...@blastwave.org> wrote:
>
> Hello Apache folks :
>
> So the process of testing TLS 1.3 shouldn't be black magic but here
> I am wondering what is wrong. I have a beta site up running Apache trunk
> build and OpenSSL 1.1.1-pre7 ( the latest atm ) and everything seems to
> be just fine. I have Mozilla beta browser with security.tls.* settings
> ready to handle TLS 1.3 and I can reach, render and see the test site at
> https://tls13.crypto.mozilla.org/ just fine. It claims TLS 1.3 (draft
> 28) using NSS whereas my site https://beta.tls13.net can not be "seen"
> via the same browser. The openssl s_client has no issues contacting both
> sites and in both cases I do see TLS 1.3 protocol as supported however
> cipher suite ( see https://wiki.mozilla.org/Security/Server_Side_TLS )
> may be the issue. Not sure.
>
> Here is what I see when using "s_client" to access the mozilla site :
>
> $ openssl s_client -connect tls13.crypto.mozilla.org:443 -tls1_3
> CONNECTED(00000003)
> 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.crypto.mozilla.org
> verify return:1
> ---
> Certificate chain
> 0 s:CN = tls13.crypto.mozilla.org
> 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-----
> MIIFEzCCA/ugAwIBAgISBPOVEnB/CqyqLondZWg55Uz8MA0GCSqGSIb3DQEBCwUA
> .
> .<snip>
> .
> Ad+yYggR2Q==
> -----END CERTIFICATE-----
> subject=CN = tls13.crypto.mozilla.org
>
> 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 2974 bytes and written 316 bytes
> Verification: OK
> ---
> New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
> 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_128_GCM_SHA256
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> 7A97B0747961C13DDF4A533C8174262F9500157007EED04A98B5BCAA314D56A5
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1529024212
> Timeout : 7200 (sec)
> Verify return code: 0 (ok)
> Extended master secret: no
> ---
> read R BLOCK
> GET
> HTTP/1.1 400 Bad Request
> Date: Fri, 15 Jun 2018 00:57:36 GMT
> Server: Apache
> Strict-Transport-Security: max-age=63072000; includeSubdomains;
> Content-Length: 226
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>400 Bad Request</title>
> </head><body>
> <h1>Bad Request</h1>
> <p>Your browser sent a request that this server could not understand.<br />
> </p>
> </body></html>
> closed
> tls13 $
>
>
> All looks fine. The nice 400 error message is very okay.
>
>
> The exact same thing to my test trunk Apache server claims odd
> results :
>
>
> $ openssl s_client -connect beta.tls13.net:443 -tls1_3
> CONNECTED(00000003)
> 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
> .
> .<snip>
> .
> 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 322 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:
> 42F400653B4C20603D96D1180E345439B941F696160A0B7BD7FF23077A111A1A899A6A43BCEE6172D00641597111FF39
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1529024399
> Timeout : 7200 (sec)
> Verify return code: 0 (ok)
> Extended master secret: no
> ---
> read:errno=0
> $
>
>
> Well other than cipher what is the difference here ? Nothing obvious.
>
> The ssl error_log ( set at level debug ) isn't helping here :
>
>
> [Fri Jun 15 00:59:59.753533 2018] [ssl:info] [pid 2250:tid 27] [client
> 68.179.116.201:34466] AH01964: Connection to child 152 established (server
> beta.tls13.net:443)
>
> [Fri Jun 15 00:59:59.755714 2018] [ssl:debug] [pid 2250:tid 27]
> ssl_engine_kernel.c(2297): [client 68.179.116.201:34466] AH02043: SSL
> virtual host for servername beta.tls13.net found
>
> [Fri Jun 15 00:59:59.788701 2018] [ssl:debug] [pid 2250:tid 27]
> ssl_engine_kernel.c(2222): [client 68.179.116.201:34466] AH02041: Protocol:
> TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384 (256/256 bits)
>
> [Fri Jun 15 00:59:59.788742 2018] [ssl:error] [pid 2250:tid 27] [client
> 68.179.116.201:34466] AH02042: rejecting client initiated renegotiation
>
> [Fri Jun 15 00:59:59.789151 2018] [ssl:debug] [pid 2250:tid 27]
> ssl_engine_io.c(1400): (130)Software caused connection abort: [client
> 68.179.116.201:34466] AH02007: SSL handshake interrupted by system [Hint:
> Stop button pressed in browser?!]
>
> [Fri Jun 15 00:59:59.789341 2018] [ssl:info] [pid 2250:tid 27] [client
> 68.179.116.201:34466] AH01998: Connection closed to child 152 with abortive
> shutdown (server beta.tls13.net:443)
> beta #
>
>
> Weird.
>
>
> Any thoughts would be greatly appreciated.
>
>
> Dennis
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>