public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: ummeegge <ummeegge@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: OpenSSL-1.1.1a - No TLSv1.3 with unbound
Date: Thu, 14 Feb 2019 12:28:02 +0100	[thread overview]
Message-ID: <6ea468fb09729b2d51ffc9cb01b101163b7d062a.camel@ipfire.org> (raw)
In-Reply-To: <76D6FBA7-1644-4C8A-8816-51E73A22E396@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 17239 bytes --]

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(a)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(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.
> > > > g64C7zJUL1zqUBbcZVDcEKO05EHz19ZHwxr4i8kTieW8XgX63lLZwhJTL1UK0Nx
> > > > OGCP
> > > > OZSVthWBp9HF9WnFjPsxsfkrxkOoz/Hcl1ZuTpWUTBLfBKqnpPJm2NJ2yoR7hPe
> > > > rUvt
> > > > l0sHJnIOczrHnAlCwZBo8OOw9tlW0va+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+rKySQH62nHTAKBggqhkjOPQQDAjBMMQs
> > > > w
> > > > CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWd
> > > > p
> > > > Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xOTAxMjgwMDAwMDBaFw0yMTA
> > > > y
> > > > MDExMjAwMDBaMHIxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRY
> > > > w
> > > > FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmM
> > > > u
> > > > MRswGQYDVQQDExJjbG91ZGZsYXJlLWRucy5jb20wWTATBgcqhkjOPQIBBggqhkj
> > > > O
> > > > PQMBBwNCAATFIHCMIEJQKB59REF8MHkpHGNeHUSbxfdxOive0qKksWw9ash3uMu
> > > > P
> > > > LlBT/fQYJn9hN+3/wr7pC125fuHfHOJ0o4ID6DCCA+QwHwYDVR0jBBgwFoAUo53
> > > > m
> > > > H/naOU/AbuiRy5Wl2jHiCp8wHQYDVR0OBBYEFHCV3FyjjmYH28uBEMar58OoRX+
> > > > g
> > > > MIGsBgNVHREEgaQwgaGCEmNsb3VkZmxhcmUtZG5zLmNvbYIUKi5jbG91ZGZsYXJ
> > > > l
> > > > LWRucy5jb22CD29uZS5vbmUub25lLm9uZYcEAQEBAYcEAQAAAYcEop+ENYcQJgZ
> > > > H
> > > > AEcAAAAAAAAAAAAREYcQJgZHAEcAAAAAAAAAAAAQAYcQJgZHAEcAAAAAAAAAAAA
> > > > A
> > > > ZIcQJgZHAEcAAAAAAAAAAABkAIcEop8kAYcEop8uATAOBgNVHQ8BAf8EBAMCB4A
> > > > w
> > > > HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMGkGA1UdHwRiMGAwLqAsoCq
> > > > G
> > > > KGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9zc2NhLWVjYy1nMS5jcmwwLqAsoCq
> > > > G
> > > > KGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9zc2NhLWVjYy1nMS5jcmwwTAYDVR0
> > > > g
> > > > BEUwQzA3BglghkgBhv1sAQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGl
> > > > n
> > > > aWNlcnQuY29tL0NQUzAIBgZngQwBAgIwewYIKwYBBQUHAQEEbzBtMCQGCCsGAQU
> > > > F
> > > > BzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRQYIKwYBBQUHMAKGOWh0dHA
> > > > 6
> > > > Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEVDQ1NlY3VyZVNlcnZlckN
> > > > B
> > > > LmNydDAMBgNVHRMBAf8EAjAAMIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAdgC
> > > > k
> > > > uQmQtBhYFIe7E6LMZ3AKPDWYBPkb37jjd80OyA3cEAAAAWiVHhSLAAAEAwBHMEU
> > > > C
> > > > IQDlnoPeMXtFkRsy3Vs0eovk3ILKt01x6bgUdMlmQTFIvAIgcAn0lFSjiGzHm2e
> > > > O
> > > > jDZJzMiP5Uaj0Jwub9GO8RkxkkoAdQCHdb/nWXz4jEOZX73zbv9WjUdWNv9KtWD
> > > > B
> > > > tOr/XqCDDwAAAWiVHhVsAAAEAwBGMEQCIFC0n0JModeol8b/Qicxd5Blf/o7xOs
> > > > /
> > > > Bk0j9hdc5N7jAiAQocYnHL9iMqTtFkh0vmSsII5NbiakM/2yDEXnwkPRvAB3ALv
> > > > Z
> > > > 37wfinG1k5Qjl6qSe0c4V5UKq1LoGpCWZDaOHtGFAAABaJUeFJEAAAQDAEgwRgI
> > > > h
> > > > AL3OPTBzOZpS5rS/uLzqMOiACCFQyY+mTJ+L0I9TcB3RAiEA4+SiPz0/5kFxvrk
> > > > 7
> > > > AKYKdvelgV1hiiPbM2YHY+/0BIkwCgYIKoZIzj0EAwIDaAAwZQIwez76hX2HTMu
> > > > r
> > > > /I3XRuwfdmVoa8J6ZVEVq+AZsE7DyQh7AV4WNLU+092BrPbnyVUFAjEAzUf5jdz
> > > > 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:
> > > > FAA394DF4959235034E350399A968F5C945D413F68CC5D29191B209900735C0
> > > > 1
> > > >   Session-ID-ctx: 
> > > >   Resumption PSK:
> > > > 414F9C16B3D4845BC0592B35CC2D28DBD9B807BCBCB95125870379E1AAA480C
> > > > 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
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> 
> 


  reply	other threads:[~2019-02-14 11:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-10 14:15 ummeegge
2019-02-13 18:05 ` Michael Tremer
2019-02-13 19:40   ` Peter Müller
2019-02-14  7:24     ` ummeegge
2019-02-14 11:11       ` Michael Tremer
2019-02-14 11:31         ` ummeegge
2019-03-07  4:16           ` ummeegge
2019-03-07  8:54             ` Michael Tremer
2019-03-07  9:05               ` ummeegge
2019-05-24  5:50                 ` ummeegge
2019-02-14  6:57   ` ummeegge
2019-02-14 11:08     ` Michael Tremer
2019-02-14 11:28       ` ummeegge [this message]
2019-02-14 11:31         ` Michael Tremer
2019-02-14 14:18           ` ummeegge
2019-02-14 15:01             ` Michael Tremer
2019-02-14 15:18               ` ummeegge
2019-02-15 14:17 ` ummeegge
2019-03-05 17:17 ` ummeegge
2019-03-05 17:23   ` Michael Tremer
     [not found] <5DEFDAC6-908C-43EB-BC66-A7BD5835626A@ipfire.org>
2019-03-05 17:56 ` ummeegge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6ea468fb09729b2d51ffc9cb01b101163b7d062a.camel@ipfire.org \
    --to=ummeegge@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox