Just to clarify the use of DNS over TLS (DOT)

johnpoz

@marchand-guy said in Just to clarify the use of DNS over TLS (DOT):

with the address 44.199.138.71 using HTTPS.

No that is the server I was making a ssl connection too.. And that is the fqdn I was wanting to talk too.. Sure you can hide that actual dns query from your isp via dot.

But when you actually go to make the connection, the fqdn your wanting to talk to is in the clear inside the ssl handshake.. Your not hiding that you looked up www.amazon.com from your isp, they just need to look in a different place.

Until esni, or now ech (esni died before it went anywhere) and the sni is actually encrypted - your not really hiding anything by using dot.. your just making it a tiny bit harder for them to find the fqdn you are going to..

edit: here is me going to amazon.com - this is part of the ssl handshake, this is the client hello where in the clear its called out what fqdn your wanting to talk too.. Just like your dns query.

until such time that the sni is encrypted - doh and dot are for sure not providing the "privacy" they pretend they are.. But you for sure are doing is handing all your dns over to someone else on a silver platter..

Not saying they don't have uses - but don't kid yourself in thinking that your isp doesn't know where your going, sure hiding where your going in some CDN cloud that hosts 1000's if not 100s of thousands of sites might give you some cover.. But simple sniff of the ssl handshake and they know exactly what fqdn your wanting to talk to..

A Former User

I understand what you are saying.

But again, please understand this: I never can find the fqdn I am wanting to talk to in the clear inside the ssl handshake, using my setup and using the string search function of wireshark. And yes, I capture the whole packets.

johnpoz

@marchand-guy said in Just to clarify the use of DNS over TLS (DOT):

setup and using the string search function of wireshark

to search for it you would have to do something like this.. Here I filter my capture to just client hello's

then I add a colum to just show that specific info

Or directly look in the client hello like I posted.

A Former User

There is an easier method than that called "Find a packet", but there you go:

johnpoz

@marchand-guy that is exactly what I said ;) you just called your colum fqdn dest, vs server name..

that is your packet 443 traffic to yoru dot server.. sniff your other traffic to say amazon.com

Clearly you know how to find the info.. Your just not looking at your other traffic. If your 443 traffic to dot server shows the fqdn, why would you think some other client hello to say amazon.com or google.com or netgate.com would not also show the fqdn in the clear..

Which was my whole point. Where you go is in the clear, until such time that encrypted sni becomes a thing across the internet..

BTW: that is a lot of session setups to your dot server, it should be reusing the same session.. opening that many ssl sessions sure and the hell not very efficient. You have 10 different sessions being setup in 15 seconds?

I know there was an issue with old version of unbound that it didn't reuse the session, but that was a few versions back when they changed that. from my understanding from unbound docs, I believe its suppose to be able to reuse the session for like 60 seconds.. Creating a new session for every query would be horrible performance..

A Former User

Damn! Now I understand what you were saying all along.
Sorry for being dense.
DNS resolution (encrypted or not) is one thing.
Accessing the destination after that, is another. And unless you use a VPN, HTTPS will always show the name of the destination (SNI) in the clear.

And thank you for spotting the communication issues I seem to have.
I will look into it further, because yes, I have some slowdowns...

Thank you, again.

johnpoz

@marchand-guy said in Just to clarify the use of DNS over TLS (DOT):

HTTPS will always show the name of the destination (SNI) in the clear.

Exactly - until such time that whole of the internet adopts some form of encrypted sni, there was an attempt with esni, that crashed and burned.. now the latest is ech (encrypted client hello).. But for that to work, every site hosting https services would have to enable it ;) So not going to happen anytime soon that is for sure hehehe

edit: the problem with any form of encrypted sni, is the hoster - why should they bother to enable it.. Its more work, it will be more resources their boxes have to expend to serve traffic, just one other thing that could break and take their site offline, which if site is selling something, or even just serving ads could mean lost revenue..

I don't really see it taking off like a rocket ship that is for sure, if adopted - its going to be a slow grind.. Some of the major hosters like cloudflare or something sure could make it so its default or even click a button. Like they do with dnssec on your domains. But for it to reach any sort of major deployment going to be a slow crawl that is for sure..

Shoot how many sites have moved to tls 1.3? even ;) If you want a slow crawl for change just look at ipv6..

dnssec should be on every domain, its % of use is horrible... Changes like this are slow to take hold.. dnssec is another one of those why should I enable it - its just something that could fail, and prevent my users from getting to my site.. So its adoption has been lack luster that is for sure.

A Former User

I like your way of thinking.

I need to rethink my communications stategy. If using DOT with quad9 is causing me delays, and my HTTPS communications are showing my destinations anyway, maybe I should try cloudflare to try isolating the DOT problems to quad9, or drop DOT altogether and get back to resolver without forwarding and ticking the maximum of options available to minimize the infos going out.

edit: I could try going full VPN from my router, but that's opening a can of worms...

RobbieTT

@johnpoz said in Just to clarify the use of DNS over TLS (DOT):

@marchand-guy said in Just to clarify the use of DNS over TLS (DOT):

Query Name Minimization Send minimum amount of QNAME/QTYPE information to upstream servers to enhance privacy

That sure isn't going to be optimal if your forwarding - that only makes sense if your resolving.. That if would even work would require multiple queries.. You should not have that set if forwarding.

The default setting in unbound is to apply qname-minimisation: yes.

The monsters only bite you if you select the option of qname-minimisation-strict: yes but the unbound default is set to : no.

There is also the option to set tls-use-sni: no. The default setting is a more reasonable : yes.

️

A Former User

@RobbieTT said in Just to clarify the use of DNS over TLS (DOT):

set tls-use-sni

No such option on my installation (pfsense 2.6 CE) in resolver settings

johnpoz

@RobbieTT said in Just to clarify the use of DNS over TLS (DOT):

The default setting in unbound is to apply qname-minimisation: yes.

since when? I just looked at clean install of 2.6 and that is not enabled.. Why it could be default, it sure wouldn't make sense if you were forwarding.

That might be the default for unbound, but default settings on pfsense would not to do that.. Unless they changed something recently?

tls-use-sni: no.

That would have zero to do with clients creating a connection to say amazon.com, etc., That would have more to do when forwarding to some sort of specific dot server..

RobbieTT

@marchand-guy You can go pure CLI for unbound configuration but the pfSense GUI gives you a custom options box where you can add configuration settings.

️

RobbieTT

@johnpoz said in Just to clarify the use of DNS over TLS (DOT):

since when? I just looked at clean install of 2.6 and that is not enabled.. Why it could be default, it sure wouldn't make sense if you were forwarding.

That might be the default for unbound, but default settings on pfsense would not to do that.. Unless they changed something recently?

As far as I tell, pfSense picks up the default unbound settings, unless there is a variance to them - this is why the pfSense unbound config list is so small. If the config option is not explicitly set in pfSense then the unbound defaults rule.

 qname-minimisation: <yes or no>
              Send  minimum  amount  of information to upstream servers to en-
              hance privacy.  Only send minimum required labels of  the  QNAME
              and  set  QTYPE  to  A when possible. Best effort approach; full
              QNAME and original QTYPE will be sent when upstream replies with
              a  RCODE other than NOERROR, except when receiving NXDOMAIN from
              a DNSSEC signed zone. Default is yes.

As ever, I'm willing to be corrected.

️

johnpoz

@RobbieTT look at the setting in the gui - its not set, so your saying in the gui being not checked to enable it - would actually mean its doing it.. That would be a bug that should be corrected then, because when not set it just doesn't put in the setting if unbound defaults to yes then there would be no way to turn it off.

Now if there is no gui option for, ok then it would make sense to use the unbound default.. But there is a clear gui setting for qname - and it defaults to not being enabled. If unbound was actually doing it, then it would be BUG that should be fixed..

So looking at my 2.6 config, it doesn't have it.. And it defaults to yes, then it would be on.. But how would I turn it off? Since just clicking enabled, and then disabled just removes the setting..

There is no setting in /var/unbound/unbound.conf for qname.. I have it enabled on my 23.05 and it places this in the conf

qname-minimisation: yes

If unbound now defaults that to yes.. Then yeah there needs to be a redmine put in - because there would be no way to disable from the gui... I just enabled and see the yes in the conf.. Then unchecked it and the whole qqname-minimisation line is gone. So if it is now defaulting to qname -- that is problem..

I will validate that default is now yes in unbound on version that is on 2.6, which is Version 1.13.2, then should prob look on 23.05 and 2.7 snap shots.. if unbound is now defaulting to yes on qname then the logic in the gui needs to be adjusted so you can actually turn it off..

 qname-minimisation: <yes or no>
              Send  minimum  amount  of information to upstream servers to en-
              hance privacy.  Only send minimum required labels of  the  QNAME
              and  set  QTYPE  to  A when possible. Best effort approach; full
              QNAME and original QTYPE will be sent when upstream replies with
              a  RCODE other than NOERROR, except when receiving NXDOMAIN from
              a DNSSEC signed zone. Default is yes.

Yeah its doing it by default.. If I put in in the options box then it doesn't do it..

server:
qname-minimisation: no

redmine created
https://redmine.pfsense.org/issues/14479

edit: ok just tested on 23.05, yeah its doing it even when you uncheck to do it in the gui, it just remove the line to do it in the conf.. which it then does it by default..

RobbieTT

@johnpoz Thanks, I hadn't noticed that at all; it does seem a bit odd.

Other settings via the Resolver GUI do populate faithfully across to the /var/unbound/unbound.conf file.

Learning as we go. No doubt there is more to be uncovered.

️

RobbieTT

@marchand-guy said in Just to clarify the use of DNS over TLS (DOT):

Accessing the destination after that, is another. And unless you use a VPN, HTTPS will always show the name of the destination (SNI) in the clear.

Things are improving with HTTP/3 as there is very little outside of the encryption, so the actual name has gone from clear text. Of course, you still need an address to route to and that will always be there. In IPv6 land the source and destination probably has a privacy address in place but the prefix may still paint a picture:

2023-06-16 at 18.36.05.png

️

johnpoz

@RobbieTT said in Just to clarify the use of DNS over TLS (DOT):

Other settings via the Resolver GUI do populate faithfully across to the /var/unbound/unbound.conf file.

To be honest this qname thing is kind of a issue to be sure, hey if your resolving its not really a change in the number of queries.. But if your forwarding and you do qname min its going to cost many queries when there should only be 1..

If I want to look up say host.domain.tld.. and I want to ask quad9 for that - asking it just for .tld or just for domain.tld are wasted queries that only take time to not work, and then finally ask for host.domain.tld

qname min should never be enabled if your forwarding..

And if there is some other thing going on and your creating multiple tls sessions vs just 1 and using it for multiple queries.. It can add up to poor performance..

edit:
To your http3 or quic point.. While the first connection might be encrypted - pretty sure those keys are visible, so you can decode and still get the sni if you wanted to..

RobbieTT

@johnpoz
I use forwarding and it only sends a single* query with the default setting.

️

*Well, there is an unrelated problem with unbound that may cause 2 sequential queries to be forwarded...

johnpoz

@RobbieTT said in Just to clarify the use of DNS over TLS (DOT):

I use forwarding and it only sends a single* query with the default setting.

So your saying in forwarding mode - it disables that qname-min is default to yes? I don't forward so would have to test that.. But yeah that would for sure make sense not to enable qname-min when forwarding.

As to you quic thing though - yeah its still there in the clear.. If I recall they exchange keys when they first talk, but those keys are in the open so anyone that wants to decode can, and wireshark does this on its own, etc...

The qname thing is still a problem though - because there is no "gui" way to disable it, and user just looking at the settings would think its off, when its not.. The only way to turn it off when resolving is to use the custom option box and actually set it to no.

A Former User

@johnpoz said in Just to clarify the use of DNS over TLS (DOT):

The only way to turn it off when resolving

Don't you mean the only way to turn it off when forwarding?
Won't you turn it on when resolving?