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(a)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(a)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(a)853(TCP) in 18.0 ms
> > > > > 
> > > > > 
> > > > > 
> > > > > And a test with s_client:
> > > > > 
> > > > > [root(a)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
> 
>