getdnsapi
SNI is not being sent
I have Stubby configured like this on Windows 10
upstream_recursive_servers:
- address_data: 45.90.28.220
tls_auth_name: "xxxx.dns.nextdns.io"
- address_data: 45.90.30.220
tls_auth_name: "xxxx.dns.nextdns.io"
When i inspect the TLS Client hello there is not SNI extension
Im using nextdns.io which needs the SNI Extension to identify devices.
I too have the same issue - also using NextDNS. I see that the Stubby webpage references use of openssl version: 1.0.2s in version 0.3.0.6 https://dnsprivacy.org/wiki/display/DP/Windows+installer+for+Stubby
However in the readme of version 0.3.0.6 - it mentions openssl version: 1.1.1.b
Can someone confim openssl version in use?
We see in conblems wireshark that TLS1.2 is in use, if we were using openssl 1.1.1 - TLS 1.3 should be available and used?
NOTE - NextDNS only supports use of openssl 1.1.1 or above
Ok, I'll create a SNI switch for upstreams that need it. For he ones that don't, I'd rather not have that enabled since it leaks Privacy sensitive info and ESNI is not for DoT unfortunately.
@wtoorop thanks where can we find it? I guess this would be a case for DoH where you can just pass parameters as URL Queryparts because ESNI would not work for DoT
@conblem Sorry, haven't gotten to this yet, but I intend to implement it coming Friday
@conblem Hey, NP! It's nice too get a feel for the interest in a thing and also good to be remembered of something you
@conblem @DanielSpindler83 I could not reproduce with the default build on my system. I see SNI being send with TLS1.3 but also with TLS1.2. This was with OpenSSL 1.1.1c. Could you do a stubby -i for me to see against which version of OpenSSL (or GnuTLS) it is linked? Thanks!
Strangely I do have trouble with builds linked against GNUTLS. It appears authentication is always required, and also for NextDNS I need to restrict the maximum TLS version to 1.2. However, despite these settings, SNI was sent in all occasions.