Hi Michael,
On Do, 2019-02-14 at 11:31 +0000, Michael Tremer wrote:
Hey,
I am getting this when I am connecting:
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384 Server public key is 384 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-ECDSA-AES256-GCM-SHA384
I did not configure anything else than the defaults.
OK, this is a little strange too since one machine uses the 25519 curve :-) . Also i have had this conversation --> https://lists.ipfire.org/pipermail/development/2018-December/005059.html in mind so i was searching for this.
But this is also a beneath one, the TLSv1.3 is in my main focus, will need a little until the build is finished. It might neverthless help very much if someone else can also went in some testings !
Best,
Erik
-Michael
On 14 Feb 2019, at 11:28, ummeegge ummeegge@ipfire.org wrote:
Hi Michael,
On Do, 2019-02-14 at 11:08 +0000, Michael Tremer wrote:
Hi,
Just for the protocol. The Lightning Wire Labs resolver currently only supports TLS 1.2.
yes i know but the strange thing is -->
Just in case you were expecting TLS 1.3 from it.
No not TLS 1.3 but 'ECDHE-X25519' . Strangely on the origin/next machine where no TLSv1.3 is used it offers also only 'ECDHE-ECDSA- SECP256R1' have wrote you that already in the 'Kicking of DoT' topic. It seems somehow related to another. The other machine (old patch <-- not sure if it has something to do with this) have no problems with TLSv1.3 but uses also TLSv1.2 with 'ECDHE-X25519' for Lightningwirelabs.
Smells a little fishy and am not sure if it is a fate of an individual.
Best,
Erik
Best, -Michael
On 14 Feb 2019, at 06:57, ummeegge ummeegge@ipfire.org wrote:
Hi Michael,
On Mi, 2019-02-13 at 18:05 +0000, Michael Tremer wrote:
Hi,
This is a bit weird.
Indeed.
Does the version of unbound support TLS 1.3? We had to update Apache to support TLS 1.3 and we had to just rebuild haproxy to support it, too. Since you are running a build of unbound that was built against OpenSSL 1.1.1 I would say the latter isn’t likely.
Yes unbound is linked agains OpenSSL-1.1.1a
Version 1.8.3 linked libs: libevent 2.1.8-stable (it uses epoll), OpenSSL 1.1.1a 20 Nov 2018 linked modules: dns64 respip validator iterator
Have two machines here running which already includes the new OpenSSL. One machine uses the OpenSSL-1.1.1a from the first testing days with the old OpenSSL cipher patch and the other machine is on current origin/next state with the OpenSSL patch from Peter.
Have tried it today again and the old testing environment (old patch) seems to work now with TLSv1.3 even the last days it does not...
Output from (let´s call it) the old machine (with the old OpenSSL patch) with testing results from Quad9 Cloudflare and Lightningwirelabs:
;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP) ;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca- bundle.crt' ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, C=US,ST=California,L=San Francisco,O=Cloudflare, Inc.,CN=cloudflare-dns.com ;; DEBUG: SHA-256 PIN: V6zes8hHBVwUECsHf7uV5xGM7dj3uMXIS9//7qC8+jU= ;; DEBUG: #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA ;; DEBUG: SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted. ;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1- SHA256)- (AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 53912 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(9.9.9.9), port(853), protocol(TCP) ;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca- bundle.crt' ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, C=US,ST=California,L=Berkeley,O=Quad9,CN=*.quad9.net ;; DEBUG: SHA-256 PIN: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg= ;; DEBUG: #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA ;; DEBUG: SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted. ;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1- SHA256)- (AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 7085 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL:
;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(81.3.27.54), port(853), protocol(TCP) ;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca- bundle.crt' ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, CN=rec1.dns.lightningwirelabs.com ;; DEBUG: SHA-256 PIN: V3z1Ap2nDKAr7Htam2jLeVejkva3BA+vFJBEJpEemrc= ;; DEBUG: #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3 ;; DEBUG: SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted. ;; TLS session (TLS1.2)-(ECDHE-X25519)-(ECDSA-SHA512)- (CHACHA20- POLY1305) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 33376 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
===============================================================
===
Tests with the new machine (new OpenSSL patch):
;; DEBUG: Querying for owner(www.isoc.org.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP) ;; DEBUG: TLS, imported 135 certificates from '/etc/ssl/certs/ca- bundle.crt' ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, C=US,ST=California,L=San Francisco,O=Cloudflare, Inc.,CN=cloudflare-dns.com ;; DEBUG: SHA-256 PIN: V6zes8hHBVwUECsHf7uV5xGM7dj3uMXIS9//7qC8+jU= ;; DEBUG: #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA ;; DEBUG: SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted. ;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 11817 ;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1
;; DEBUG: Querying for owner(www.isoc.org.), class(1), type(1), server(9.9.9.9), port(853), protocol(TCP) ;; DEBUG: TLS, imported 135 certificates from '/etc/ssl/certs/ca- bundle.crt' ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, C=US,ST=California,L=Berkeley,O=Quad9,CN=*.quad9.net ;; DEBUG: SHA-256 PIN: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg= ;; DEBUG: #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA ;; DEBUG: SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted. ;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(CHACHA20- POLY1305) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 4679 ;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1
;; DEBUG: Querying for owner(www.isoc.org.), class(1), type(1), server(81.3.27.54), port(853), protocol(TCP) ;; DEBUG: TLS, imported 135 certificates from '/etc/ssl/certs/ca- bundle.crt' ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, CN=rec1.dns.lightningwirelabs.com ;; DEBUG: SHA-256 PIN: V3z1Ap2nDKAr7Htam2jLeVejkva3BA+vFJBEJpEemrc= ;; DEBUG: #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3 ;; DEBUG: SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted. ;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(CHACHA20- POLY1305) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 5685 ;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1
Lightningwirelabs uses on the old machine also ECDHE-X25519 , the new one only ECDHE-ECDSA-SECP256R1 .
What it makes even more worse is that i´d compiled origin/next a couple of days ago with the old OpenSSL patch to see if the problem comes from there but with the same results (no TLSv1.3).
May the providers did disabled TLSv1.3 for a couple of days since at that time my old machine have had the same TLSv1.2 results ???
Am currently not sure what happens here.
Best,
Erik
-Michael
On 10 Feb 2019, at 14:15, ummeegge ummeegge@ipfire.org wrote:
Hi all, did an fresh install from origin/next of Core 128 with the new OpenSSL- 1.1.1a . Have checked also DNS-over-TLS which works well but kdig points out that the TLS sessions operates only with TLSv1.2 instaed of the new delivered TLSv1.3 .
A test with Cloudflair (which uses TLSv1.3) looks like this -->
kdig Test:
;; DEBUG: Querying for owner(www.isoc.org.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP) ;; DEBUG: TLS, imported 135 certificates from '/etc/ssl/certs/ca- bundle.crt' ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, C=US,ST=California,L=San Francisco,O=Cloudflare, Inc.,CN=cloudflare-dns.com ;; DEBUG: SHA-256 PIN: V6zes8hHBVwUECsHf7uV5xGM7dj3uMXIS9//7qC8+jU= ;; DEBUG: #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA ;; DEBUG: SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted. ;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256- GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 51175 ;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 1452 B; ext-rcode: NOERROR ;; PADDING: 239 B
;; QUESTION SECTION: ;; www.isoc.org. IN A
;; ANSWER SECTION: www.isoc.org. 300 IN A 46.43.36.22 2 www.isoc.org. 300 IN RRSIG A 7 3 300 20190224085001 20190210085001 45830 isoc.org. g64C7zJUL1zqUBbcZVDcEKO05EHz19ZHwxr4i8kTieW8XgX63lLZwhJTL1U K0Nx OGCP OZSVthWBp9HF9WnFjPsxsfkrxkOoz/Hcl1ZuTpWUTBLfBKqnpPJm2NJ2yoR 7hPe rUvt l0sHJnIOczrHnAlCwZBo8OOw9tlW0va+706ZQ=
;; Received 468 B ;; Time 2019-02-10 12:40:19 CET ;; From 1.1.1.1@853(TCP) in 18.0 ms
And a test with s_client:
[root@ipfire tmp]# openssl s_client -connect 1.1.1.1:853 CONNECTED(00000003) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com verify return:1
Certificate chain 0 s:C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com i:C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA 1 s:C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
Server certificate -----BEGIN CERTIFICATE----- MIIFxjCCBUygAwIBAgIQAczjGN6fVn+rKySQH62nHTAKBggqhkjOPQQDAjB MMQs w CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1 EaWd p Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xOTAxMjgwMDAwMDBaFw0 yMTA y MDExMjAwMDBaMHIxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybml hMRY w FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCB JbmM u MRswGQYDVQQDExJjbG91ZGZsYXJlLWRucy5jb20wWTATBgcqhkjOPQIBBgg qhkj O PQMBBwNCAATFIHCMIEJQKB59REF8MHkpHGNeHUSbxfdxOive0qKksWw9ash 3uMu P LlBT/fQYJn9hN+3/wr7pC125fuHfHOJ0o4ID6DCCA+QwHwYDVR0jBBgwFoA Uo53 m H/naOU/AbuiRy5Wl2jHiCp8wHQYDVR0OBBYEFHCV3FyjjmYH28uBEMar58O oRX+ g MIGsBgNVHREEgaQwgaGCEmNsb3VkZmxhcmUtZG5zLmNvbYIUKi5jbG91ZGZ sYXJ l LWRucy5jb22CD29uZS5vbmUub25lLm9uZYcEAQEBAYcEAQAAAYcEop+ENYc QJgZ H AEcAAAAAAAAAAAAREYcQJgZHAEcAAAAAAAAAAAAQAYcQJgZHAEcAAAAAAAA AAAA A ZIcQJgZHAEcAAAAAAAAAAABkAIcEop8kAYcEop8uATAOBgNVHQ8BAf8EBAM CB4A w HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMGkGA1UdHwRiMGAwLqA soCq G KGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9zc2NhLWVjYy1nMS5jcmwwLqA soCq G KGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9zc2NhLWVjYy1nMS5jcmwwTAY DVR0 g BEUwQzA3BglghkgBhv1sAQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3c uZGl n aWNlcnQuY29tL0NQUzAIBgZngQwBAgIwewYIKwYBBQUHAQEEbzBtMCQGCCs GAQU F BzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRQYIKwYBBQUHMAKGOWh 0dHA 6 Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEVDQ1NlY3VyZVNlcnZ lckN B LmNydDAMBgNVHRMBAf8EAjAAMIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWg AdgC k uQmQtBhYFIe7E6LMZ3AKPDWYBPkb37jjd80OyA3cEAAAAWiVHhSLAAAEAwB HMEU C IQDlnoPeMXtFkRsy3Vs0eovk3ILKt01x6bgUdMlmQTFIvAIgcAn0lFSjiGz Hm2e O jDZJzMiP5Uaj0Jwub9GO8RkxkkoAdQCHdb/nWXz4jEOZX73zbv9WjUdWNv9 KtWD B tOr/XqCDDwAAAWiVHhVsAAAEAwBGMEQCIFC0n0JModeol8b/Qicxd5Blf/o 7xOs / Bk0j9hdc5N7jAiAQocYnHL9iMqTtFkh0vmSsII5NbiakM/2yDEXnwkPRvAB 3ALv Z 37wfinG1k5Qjl6qSe0c4V5UKq1LoGpCWZDaOHtGFAAABaJUeFJEAAAQDAEg wRgI h AL3OPTBzOZpS5rS/uLzqMOiACCFQyY+mTJ+L0I9TcB3RAiEA4+SiPz0/5kF xvrk 7 AKYKdvelgV1hiiPbM2YHY+/0BIkwCgYIKoZIzj0EAwIDaAAwZQIwez76hX2 HTMu r /I3XRuwfdmVoa8J6ZVEVq+AZsE7DyQh7AV4WNLU+092BrPbnyVUFAjEAzUf 5jdz 1 pyc74lgOunC7LBE6cPtWbzfGpJiYyT/T+c5eIAwRYziKT0DKbaql7tiZ -----END CERTIFICATE----- subject=C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
issuer=C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits
SSL handshake has read 2787 bytes and written 421 bytes Verification: OK
New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256 Server public key is 256 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)
Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_CHACHA20_POLY1305_SHA256 Session-ID: FAA394DF4959235034E350399A968F5C945D413F68CC5D29191B2099007 35C0 1 Session-ID-ctx: Resumption PSK: 414F9C16B3D4845BC0592B35CC2D28DBD9B807BCBCB95125870379E1AAA 480C 7 PSK identity: None PSK identity hint: None TLS session ticket lifetime hint: 21600 (seconds) TLS session ticket: 0000 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0010 - 8f 9b bb d1 0a 9e a6 0d-df d3 9d 7d 8f c1 f1 6b ...........}...k 0020 - 00 80 31 55 77 a3 b3 5c-fe 90 11 fb 8c ef b1 23 ..1Uw.........# 0030 - 9c 88 83 b0 33 5d 84 d6-1a 75 db 68 67 fb 57 3d ....3]...u.hg.W= 0040 - ef 71 6b 7f 22 ae fa bf-d7 0d 12 37 62 69 01 ff .qk."......7bi.. 0050 - 5a 78 29 97 8e ab a4 8e-e0 83 ab 0f 63 fa b4 d9 Zx).........c... 0060 - 3b 08 70 38 56 db 6a 43-8c d3 e4 de 5d 1e 7e cb ;.p8V.jC....].~. 0070 - 82 63 08 cd 31 71 61 17-44 a1 98 87 8a a5 43 06 .c..1qa.D.....C. 0080 - d1 f8 aa a7 ba 3e 99 32-a9 f8 a6 14 46 bd a2 0e .....>.2....F... 0090 - 74 79 fa 24 c5 5c a2 12-81 cb 2c 85 4b 91 c1 1b ty.$.....,.K... 00a0 - 7d c3 3d c9 6a 58 12 4e-41 b7 eb 29 9e b6 90 07 }.=.jX.NA..).... 00b0 - e1 92 dd 8d 44 69 ....Di
Start Time: 1549799117 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0
read R BLOCK closed
Which seems strange to me since Cloudflair offers TLSv1.3 but unbound initializes only TLSv1.2 .
Have check all working DoT servers from here -->
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers
too, but no TLSv1.3 at all...
Did someone have similar behaviors ?
Best,
Erik