On Do, 2019-02-14 at 11:11 +0000, Michael Tremer wrote:
Hey Erik,
Did you try Matthias’ patch for unbound 1.9.0?
Yes, and have currently no problems with it. As a beneath one, all TLSv1.3 tests/problems has been made with 1.8.3 but they appears also with 1.9.0 .
On 14 Feb 2019, at 07:24, ummeegge ummeegge@ipfire.org wrote:
Hi Peter,
On Mi, 2019-02-13 at 19:40 +0000, Peter Müller wrote:
Hello Michael, hello Erik,
sorry for the long delay here. :-\
I noticed the AESCCM issue with Unbound, and will have a look at it (never observed these ciphers in the wild - i.e. web and mail traffic - but that does not mean anything here).
I think the disabled AESCCM should not be the problem since on the first testing days TLSv1.3 did worked without problems on my machine. It worked at that time with the old cipher patch but also only with the three TLSv1.3 defaults ciphers:
# TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD # TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD # TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
so the other two CCM ciphers wasn´t enabled there.
In unbound´s example conf the tls-ciphersuites are:
# cipher setting for TLSv1.3 # tls-ciphersuites: "TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SH A256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
which differs very much to that one which i´d see the last time. In my humble opinion, it looks like speed opitimization. I think this settings are server settings.
Yes. The client usually offers everything it supports and the server picks the best cipher according to its own list.
So that does not have anything to do with how unbound connects to an upstream server.
At the moment, I do not have an idea what is going wrong here (currently using 127-stable).
What are you thinking about to go for some OpenSSL checks ? Not sure when Core 128 will be released but as i remember it should come not that long after Core 127 ???
Yes, it should have been in testing by now, but Arne is away. Hence there is a little delay.
OK, i see. Am build nevertheless again a new origin/next image playing around with the OpenSSL cipher patch since it is the only thing i have currently in mind what can causes the TLSv1.3 problem, but again am not sure with this ?!
Since this is a bigger update it might be great if more people comes around to test the new OpenSSL lib...
P.S.: It's CloudFlare, not Cloudflair. :-)
Thanks for finding the bug :D .
P.P.S.: Thank you for the DoT server list. I will update the Wiki page.
Your welcome but keep in mind that a lot of this servers listed in there are testing ones (regular checks points out that there are longer time off or do have problems with certificates). CleanBrowsing, Adguard (not sure which lists they use to filter!) and Google are new listed as regular public resolvers --> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers .
Best,
Erik
Thanks, and best regards, Peter Müller
Hi,
This is a bit weird.
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.
-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.222 www.isoc.org. 300 IN RRSIG A 7 3 300 20190224085001 20190210085001 45830 isoc.org. g64C7zJUL1zqUBbcZVDcEKO05EHz19ZHwxr4i8kTieW8XgX63lLZwhJTL1UK0 NxOG CPOZSVthWBp9HF9WnFjPsxsfkrxkOoz/Hcl1ZuTpWUTBLfBKqnpPJm2NJ2yoR 7hPe rUvtl0sHJnIOczrHnAlCwZBo8OOw9tlW0va+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+rKySQH62nHTAKBggqhkjOPQQDAjBMM Qsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1Ea Wdp Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xOTAxMjgwMDAwMDBaFw0yM TAy MDExMjAwMDBaMHIxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhM RYw FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJb mMu MRswGQYDVQQDExJjbG91ZGZsYXJlLWRucy5jb20wWTATBgcqhkjOPQIBBggqh kjO PQMBBwNCAATFIHCMIEJQKB59REF8MHkpHGNeHUSbxfdxOive0qKksWw9ash3u MuP LlBT/fQYJn9hN+3/wr7pC125fuHfHOJ0o4ID6DCCA+QwHwYDVR0jBBgwFoAUo 53m H/naOU/AbuiRy5Wl2jHiCp8wHQYDVR0OBBYEFHCV3FyjjmYH28uBEMar58OoR X+g MIGsBgNVHREEgaQwgaGCEmNsb3VkZmxhcmUtZG5zLmNvbYIUKi5jbG91ZGZsY XJl LWRucy5jb22CD29uZS5vbmUub25lLm9uZYcEAQEBAYcEAQAAAYcEop+ENYcQJ gZH AEcAAAAAAAAAAAAREYcQJgZHAEcAAAAAAAAAAAAQAYcQJgZHAEcAAAAAAAAAA AAA ZIcQJgZHAEcAAAAAAAAAAABkAIcEop8kAYcEop8uATAOBgNVHQ8BAf8EBAMCB 4Aw HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMGkGA1UdHwRiMGAwLqAso CqG KGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9zc2NhLWVjYy1nMS5jcmwwLqAso CqG KGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9zc2NhLWVjYy1nMS5jcmwwTAYDV R0g BEUwQzA3BglghkgBhv1sAQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZ Gln aWNlcnQuY29tL0NQUzAIBgZngQwBAgIwewYIKwYBBQUHAQEEbzBtMCQGCCsGA QUF BzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRQYIKwYBBQUHMAKGOWh0d HA6 Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEVDQ1NlY3VyZVNlcnZlc kNB LmNydDAMBgNVHRMBAf8EAjAAMIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAd gCk uQmQtBhYFIe7E6LMZ3AKPDWYBPkb37jjd80OyA3cEAAAAWiVHhSLAAAEAwBHM EUC IQDlnoPeMXtFkRsy3Vs0eovk3ILKt01x6bgUdMlmQTFIvAIgcAn0lFSjiGzHm 2eO jDZJzMiP5Uaj0Jwub9GO8RkxkkoAdQCHdb/nWXz4jEOZX73zbv9WjUdWNv9Kt WDB tOr/XqCDDwAAAWiVHhVsAAAEAwBGMEQCIFC0n0JModeol8b/Qicxd5Blf/o7x Os/ Bk0j9hdc5N7jAiAQocYnHL9iMqTtFkh0vmSsII5NbiakM/2yDEXnwkPRvAB3A LvZ 37wfinG1k5Qjl6qSe0c4V5UKq1LoGpCWZDaOHtGFAAABaJUeFJEAAAQDAEgwR gIh AL3OPTBzOZpS5rS/uLzqMOiACCFQyY+mTJ+L0I9TcB3RAiEA4+SiPz0/5kFxv rk7 AKYKdvelgV1hiiPbM2YHY+/0BIkwCgYIKoZIzj0EAwIDaAAwZQIwez76hX2HT Mur /I3XRuwfdmVoa8J6ZVEVq+AZsE7DyQh7AV4WNLU+092BrPbnyVUFAjEAzUf5j dz1 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: FAA394DF4959235034E350399A968F5C945D413F68CC5D29191B209900735 C01 Session-ID-ctx: Resumption PSK: 414F9C16B3D4845BC0592B35CC2D28DBD9B807BCBCB95125870379E1AAA48 0C7 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