Hi everyone,
I think that it’s time for me to delve a little deeper in the DoT and DoH matter.
I watched the Lawrence’s video about DNS over TLS and HTTPs and even though I think that I got most of them, they also raised some doubts nonetheless since I am everything but a computer networking expert.
So, first of all, I need to make sure that I got a couple of things right before I go ahead.
Is DoT basically handled by your router/firewall (dnsmasq) while DoT is handled by your browser…to date at least?
Can your dns server (say cloudflare) to which you forward the encrypted DNS queries, be it either over TLS or HTTPS, reads which site IP are you requesting for?
If I got it right, no Men-in- the-middle guy can read your queries over TLS or https on their way to the server dns resolver and back because they are encrypted. Ok, but once your browser gets the IP and asks the server on which is deployed, say, web pages or whatever, to start a connection, is the IP still encrypted. I mean, in this last step, can a MITM see which IPs are involved while their exchange information and data…source IP and destionation IP?
I meant if a few routers now are capable of DoH already, or it is a tool which only few browsers are capable of now.
ok
as I suspected, I was not clear enough. Sorry, it’s my fault. I wasn’t talking about the data echange between my device and the DNS provider anymore, but what exactly happens between you and your final target, that is, the server which you asked the IP for (say the one which hosts, i.g., nytimes.com or bbc, whatever). The IP must be in clear in order to enable every router to route your connection request to that server. am I correct on this point?
DoT looks to be firewall/router based at this point. Some firewalls/routers like Pfsence support DoT in later versions of the firewall. You also see some consumers routers incorporating software like Stubby to do native DoT support. Many Asus wireless routers can run 3rd party Merlin firmware that supports DoT. I believe other 3rd party firmware like DDWRT might also support DoT. DoH at the moment is browser based but more and more operating systems have announced support for DoH. Later versions of Microsoft Windows are going to be implementing DoH. You can enable it manually now but it is going to be turned on in future versions. I believe some Linux distros have announced DoH support but I don’t recall which ones.
At this time both DoH and DoT encrypt your DNS request in your browser or on your router. Your encrypted request arrives at the DNS resolver (cloudflare, Quad 9, Google, etc), they decrypt the request, identify the needed IP address, encrypt the IP address, then return the query to you. Hence the DNS resolver knows who you are and what site you want to visit. Very recently, Apple and Cloudflare have announced ODoH or Oblivious DoH. This is a very clever enhancement of DoH but using a 3rd party proxy to obfuscate the party making the DNS request. In this case, You make a DoH request and it goes to a 3rd party proxy. The 3rd party proxy re-routes your encrypted DoH request and forwards it on to the DNS resolver (cloudflare, Quad 9, Google, etc). At this point the 3rd party proxy has no idea what site you want to go to but they do know who you are. The DNS resolver decrypts the DNS request, identifies the needed IP address, encrypts the IP address, and forwards the IP address to the 3rd party proxy. The DNS resolver knows what site is requested but not who you are. The 3rd party proxy then forwards the encrypted IP address to you. Again, the 3rd party proxy only knows who you are and the DNS resolver only knows the requested site but never your identity.
There should be minimal overhead with the 3rd party proxy. I expect lots of others to support ODoH other than Apple and Cloudflare. I suspect we’ll see this in 6-12 months.
Once you have the IP address of the site you want to visit there is no intervention with the DNS resolver at all. Your browser, or your operating system, encrypts your request (the S in https://) and forwards your request to the server at the IP address. The server decrypts your request, fetches your data, encrypts your data, and returns the encrypted data to your IP address. Again, all encrypted if you are using sites that are HTTPS. Most are today and our browsers are getting rather obnoxious if we try to visit an older HTTP site without encryption.
Thank you for your long answer. Very very useful. It is almost everything clear even to a newbie like me.
ok! Got it!
the encrypted dns request to the DNS resolver (cloudflare, Quad9, etc) is sent after a three way handshake with the resolver server itself, which then sends its public key (certificate) to enable the client to encrypt the dns request? Got it right?
basically the same question as above. Once I have the IP address of the site I want to visit, I initialize a three way handshake with it (the server of course), then I send the http/uri in an ecrypted IP packet. Correct? A reverse proxy (if any) can possibly read a subdomain in the uri to correctly process and address it to the “right way”. I’d like to find a graphic representation of what an IP packet looks like just after a three way handshake with the server.
Just a further expansion on DoT and DoH. DoT is handled at the transport layer. DoH is handled at the application layer. This explains why they are limited to certain devices/applications.
Yes. DoH and DoT are handled by TCP hence the three way handshake.
There should be many examples available in networking textbooks. I particularly find the one by Peterson and Davie very through but still relatively easy to follow.