[fChk]

This topic stems from the 'Heads-Up: Firefox rolling DNS-over-HTTPS (DoH)' thread and will try to present in a non-technical overview, the big picture of the current state of our privacy on the Web and the emerging technologies that promise, when adopted, a new wave of the famous 'Going Dark' meme.

Till fairly recently (june 2013 -the Snowden revelation moment) the Web was still largely transmitted in plain text. You would connect to a forum like this one and login without any encryption at all, not even for the login forum to secure your password!... But that was then. By 2015, the Web (or a large section of it) adopted the HTTPS as its new medium of transmission in a move to reassure its users that its actors are doing something against the industrial scale of spying that Snowden revealed... That was the first 'Going Dark' moment.

Thus, the push towards TLS (and the fact that Windows XP was becoming EOL by 2014) made even the ubiquitous shared hosting services to start offering it to their users by making use of the TLS SNI extension (Windows XP didn't support SNI.) At first people were starting to use self-signed keys for their personal websites, but by December 2015, Let's Encrypt, the non-profit certificate authority, entered the Web scene and made TLS certificate affordable for everyone... No more excuses!..

With an HTTPS-powered Web, a bit of intimacy and privacy started to exist on the Web, especially when TLS v1.2 was adopted; this version was the first to support Perfect Forward Secrecy (PFS), which is a TLS feature that make use of 'volatile' session keys assuring the safety of the encryption even if the private key of the server is compromised somehow. [As an aside -and will probably comeback later on this in another post -PFS is now mandatory in TLS v1.3.]

Alas, with all the progress outlined above, we're still too short to claim any privacy on the Web, and here is why: we are leaking the site's own identity even if that communication is done via HTTPS (be it TLS v1.2 or even v1.3.) On that simple information, anyone sitting between you and that server will be able to get a pretty good idea about YOU!.. and that's a gold mine for a lot of reasons, starting from the trivial (business related stuff-i.e. selling that info to the highest bider) to the sensitive (legal related matters.)

So, to protect the identity of the sites we visit we have to deal with 4 different leaks:

• DNS name resolution: this leak is dealt with when using DoH (DNS over HTTPS on port 443) or DoT (DNS over TLS on port 853.)
  
• the TLS certificate message: this leak is suppressed when we use TLS v1.3, which encrypts the server certificate by default.
  
• the TLS Server Name Indication extension (SNI): the fix for this leak (i.e. the encryption of the the SNI field, hence “encrypted SNI” or ESNI) was dropped from the TLS v1.3 standard but still Mozilla & Cloudflare engineers are currently testing a use-case for it.
  
• the IP address of the server: this is a hard one to crack; no wonder, it's at the heart of the Internet mechanics. But on shared hosting and/or behind a CDN (like Cloudflare) and/or behind a VPN ..etc.. things get indeed a lot fuzzier.
  

Those are the trends that , as of this end of 2019, are presented to us to shore up our privacy defences for whom is still willing to fight back against this ongoing online striptease... To test your 'leakage level', Cloudflare has setup a page that tests out all the 4 above mentioned 'fixes' for you (ie: Secure DNS -for DNS privacy-, DNSSEC -for DNS integrity, TLS 1.3, and Encrypted SNI.)

Now, I'll be posting about the specifics of all the 4 technologies in a bit more details later on.

Stay tuned.

[deanhills]

Alas, with all the progress outlined above, we're still too short to claim any privacy on the Web, and here is why: we are leaking the site's own identity even if that communication is done via HTTPS (be it TLS v1.2 or even v1.3.) On that simple information, anyone sitting between you and that server will be able to get a pretty good idea about YOU!.. and that's a gold mine for a lot of reasons, starting from the trivial (business related stuff-i.e. selling that info to the highest bider) to the sensitive (legal related matters.)

Thank you for your detailed explanation @fChk.  This may or may not have anything to do with this, but a few months ago I'm almost certain I was a victim of DNS hacking.  I was wondering whether this could be related to your topic along the lines of "leaking a site's identity".

There are rogue hackers who may open a VPS/Server account with IP XXX.  They then have a domain that is registered say with Namecheap, and the IP of that account is registered with the domain at Namecheap. Namecheap of course doesn't ask any one to verify the IP that they insert with the Domain to modify the DNS of the domain with an external IP - they can technically add or modify the IP of their domain at any time they wish without having to go through a DNS verification process.  And there is also not a system where when a service is ended and the IP withdrawn and reused, that the IP that was given is automatically removed from the domain hosted by the domain registrar.  

So very shortly after I purchased a VPS in March with Contabo, I got a terrible notification that my IP was guilty of attacking other Websites.  The complaint said that two domains (the ones I mentioned above) were hosted by my VPS with my IP and were attacking other Websites.  Of course, by the time we figured this out the perpetrators were gone, and the Websites empty.  And strangely enough, Contabo could find no evidence on my VPS that any hacking had taken place.  There were no files at all.  The complaint was entirely based on those domains that had been attacking other Websites with my IP.

The sad part of it all was the domain that I had originally used with the VPS had been blacklisted all over the Internet.  I in essence lost use of it.  Yet ironically those two rogue Websites at Namecheap on which the complaint was based, weren't touched by the anti-spam cops.  They seem to be fine.  I guess one could call that double jeopardy.  My VPS got suspended, and I lost use of my domain.  Yet nothing happened to the domains that were associated with the IP that and the complaint was based on.  Like the system of checking on spam is also not a really good system - it protected the spammers more than in my case my domain.

I then asked Contabo for a new IP, and up to a couple of months ago, about three months after the event, those domains seem to be still "abandoned" with my original "hacked" IP still in place.  Do you think someone else could become a victim if they were to get a VPS with the IP with which the two domains are registered with Namecheap?  In essense DNS hacking?  Like Namecheap and other domain regisrars who do not verify IP ownership when domain DNS is made custom to an external IP actually open up the possibility of domain DNS abuse?

I was also thinking of another possibility. While those rogue Websites may have been hosted somewhere with my "attack" IP before I was given the IP, could they have set up e-mails in such a way that their sending were delayed and then launched after they no longer were hosted with that IP?

[fChk]

Thank you for your detailed explanation @fChk.  This may or may not have anything to do with this, but a few months ago I'm almost certain I was a victim of DNS hacking.  I was wondering whether this could be related to your topic along the lines of "leaking a site's identity".

Not exactly related.. This thread is about the end-users privacy issues.

First of all, sorry about that misfortune.

(...)
I then asked Contabo for a new IP, and up to a couple of months ago, about three months after the event, those domains seem to be still "abandoned" with my original "hacked" IP still in place.  Do you think someone else could become a victim if they were to get a VPS with the IP with which the two domains are registered with Namecheap?  In essense DNS hacking?  Like Namecheap and other domain regisrars who do not verify IP ownership when domain DNS is made custom to an external IP actually open up the possibility of domain DNS abuse?

Anyone can become a victim when they have a static IP. I don't think it's a DNS poisoning issue here, as if I understand what you're saying above, the issue was the IP not the domain name. Thus, in this case, it should have been an IP address spoofing incident; but that's quite unlikely IMHO. (for more on this.)

I was also thinking of another possibility.  While those rogue Websites may have been hosted somewhere with my "attack" IP before I was given the IP, could they have set up e-mails in such a way that their sending were delayed and then launched after they no longer were hosted with that IP?

This is a more likely scenario than the IP address spoofing (what are the odds?!!)

[humanpuff69]

Plaintext is extremely easy to see . With wireshark i can see the whole webpage and the request . Imagine the user entering a password , the attacker/sniffer can easily know the password

Https solve the problem . Because to acomplish the same thing you need the user to use the custom ceritifcate . If you ever use burp with https you know what i mean

And dns is also plaintext , i can snoop the port 53 tcpdump and get what the user is visiting . This is what your isp mostly see

And with the dns being encrpyted it solve that problem .

[fChk]

So, to protect the identity of the sites we visit we have to deal with 4 different leaks:

• DNS name resolution: this leak is dealt with when using DoH (DNS over HTTPS on port 443) or DoT (DNS over TLS on port 853.)
  
• the TLS certificate message: this leak is suppressed when we use TLS v1.3, which encrypts the server certificate by default.
  
• the TLS Server Name Indication extension (SNI): the fix for this leak (i.e. the encryption of the the SNI field, hence “encrypted SNI” or ESNI) was dropped from the TLS v1.3 standard but still Mozilla & Cloudflare engineers are currently testing a use-case for it.
  
• the IP address of the server: this is a hard one to crack; no wonder, it's at the heart of the Internet mechanics. But on shared hosting and/or behind a CDN (like Cloudflare) and/or behind a VPN ..etc.. things get indeed a lot fuzzier.
  

In this post, I'll expand a bit on the DNS name resolution risks and what specific issues the use of DNSSEC and encrypted DNS (or secure DNS or DoH/DoT) address from an end-user(/client) perspective.

In upcoming threads, I'll deal with how these 3 technologies(/standards) are implemented server-side (ie, how DNSSEC is deployed for a given domain name, and how we can implement our own DoT/DoH servers.) But for now, in this post, we'll just address the DNS issues from a user's perspective in the Web context (as an example.)

The Importance the DNS:
The first thing a browser does when you want to visit a website is to perform a DNS lookup to get the IP address of the domain name you're about to visit. For this to succeed, the browser relies on the OS configured DNS server (which is normally set with your IPv4 connectivity stack.) For the 92% of the case it's the user's ISP DNS server; for the 5% it's the Corporate DNS servers and for the rest(/powerUsers) it's a public DNS resolver (be it OpenDNS, Quad9, Cloudflare's or Google's ..) [1] So, if this DNS lookup for whatever reason fails, well, you're stuck!... That's how DNS is critical for your daily web browsing routines (in fact, DNS is critical for anything using domain names on the Internet... and I'm sure this is trivial knowledge... but I'm building a logic here :-) So, bear with me, please.)

The Problem(s) with the DNS:
DNS queries and replies are transmitted in plain text over UDP or TCP, which make them an easy target for spoofing, surveillance, and filtering (DNS-based censorship) while in transit on the wire.

In other words, traditional DNS is just a disaster waiting to happen. It is plain-text,  easily monitored, easily blocked (port 53), easily redirected, easily forged (when without DNSSEC.)


DNSSEC to the Rescue:
Because securing the DNS is securing the Internet as a whole, the Domain Name System Security Extensions (DNSSEC) has been steadily developed and deployed over the past two decades (check the timeline here.)

At its core, DNSSEC is a technology that uses cryptographic signatures to make the DNS tamper-proof, protecting it against DNS hijacking. And to quote the Wikipedia page:

It is a set of extensions to DNS which provide to DNS clients (resolvers) cryptographic authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

So, please, remember that DNSSEC doesn't provide DNS data confidentiality(/privacy) but it's all about DNS data authentication and integrity (ie, you can be sure that the data you're getting is authentic and sound.)

Alas, for this assurance to happen, both the domain and the user's stub resolver have to DNSSEC-aware. Please review the wiki page for more on that. In here, I'll just point out that in Linux (I'm no longer a Windows user in production mode--and don't advice it) both Bind and Unbound are good options when it comes to DNSSEC support(/signature validation.) But, Use Bind only if you have local zones to manage; if not, use Unbound.

What about Privacy ?.. "encrypted DNS" to the Rescue:
To the joy of the Internet snoopers, secure DNS has been neglected for far too long; the party is over!.. DoH and DoT are here ( drum beat :-) )

For about 2 years or so (I was basically offline in that period, so I missed the whole beginnings), encrypted DNS is becoming a HOT topic on the Internet and rightly so; it's such a huge deal for the rest of us privacy-starved netizens, although, it's still work in progress that result on today's DoH and DoT.

DNS-over-HTTPS (DoH, port 443) and DNS-over-TLS (DoT, port 853), by encrypting the traffic between clients and resolvers, enhance users' privacy and complement Public DNS resolvers validation of DNSSEC to finally provide a real end-to-end authenticated DNS for DNSSEC-signed domains.

Now, I'll finish by presenting a rough overview of DoH and DoT and will leave all the technical details to my upcoming thread on 'Encrypted DNS'.

What is DoT?
DNS over TLS (DoT) is a proposed standard (rfc7858) from the IETF, that encrypts DNS traffic and send it via port 853 using the TLS protocol. Thus its sole goal is to increase user's privacy and security by preventing eavesdropping and tampering of the DNS data.

We'll deal more about DoT implementation in the adhoc thread; for now let's just summarize it by stating that DoT is encrypted, easily monitored (traffic-wise; port 853), easily blocked but not easily forged.


What is DoH?
DNS over HTTPS (DoH) is a new RFC (rfc8484) from the IETF, published in October 2018, that "gives web applications access to DNS information via existing browser APIs." And, by doing that, they are short-circuiting the Operating system hegemony/control over DNS functionality, thus creating another headache to the corporate security folks in their efforts to enforce
the corporation's policy in the work-place (I've read somewhere on the Web, someone calling Firefox a 'rogue application' for daring to implement DoH :-) .)

Anyway, DoH is encrypted, not easily monitored (it's mixed with standard HTTPS traffic; but see this post ), not easily blocked (same reason as before), not easily redirected and not easily forged.

This ends the overview of the DNS name resolution leakes and fixes. My next post here is about the TLS v1.3 and the ESNI.

Stay tuned!


----------
[1]-Those percentages aren't real obviously, but quite plausible :-)

[fChk]

What is DoH?
DNS over HTTPS (DoH) is a new RFC (rfc8484) from the IETF, published in October 2018, that "gives web applications access to DNS information via existing browser APIs." And, by doing that, they are short-circuiting the Operating system hegemony/control over DNS functionality, thus creating another headache to the corporate security folks in their efforts to enforce the corporation's policy in the work-place (I've read somewhere on the Web, someone calling Firefox a 'rogue application' for daring to implement DoH :-) .)

It's interesting to read a blog post from infoblox.com, a cybersecurity website, entitled: DoT, DoH and the DNS “Last Mile” Security Problem, where they question the suitability of DoH on enterprise networks.

We don’t question the motives of the developers of DoH: One of their goals was to help safeguard web browsing on parts of the Internet where snooping on DNS traffic and manipulating DNS responses is routine. But we question its suitability for use on enterprise networks.

Infoblox Implementation Recommendations for DoT and DoH
Infoblox’s recommendation is that companies block direct DNS traffic—including DoT and DoH—between internal IP addresses and DNS servers on the Internet, including Cloudflare’s. This approach should force users to employ their company’s internal DNS infrastructure, allowing their IT organization to apply DNS resolution policy and troubleshoot problems.

DoT, as we already said in the previous post is easy to block by shutting down port 853, but DoH is a bit trickier (as we already said too.) And here is their solution:

Code: (Select All)

# Block DoH to Cloudflare

deny tcp/udp in/out to 104.16.111.25 on port 443

deny tcp/udp in/out to 104.16.112.25 on port 443

deny tcp/udp in/out to 2606:4700::6810:7019 on port 443

deny tcp/udp in/out to 2606:4700::6810:6f19 on port 443

# Block DoH to Google Public DNS

deny tcp/udp in/out to 8.8.8.8 on port 443

deny tcp/udp in/out to 8.8.4.4 on port 443

deny tcp/udp in/out to 2001:4860:4860::8888 on port 443

deny tcp/udp in/out to 2001:4860:4860::8844 on port 443

Barring access to Cloudflare and Google public DNS resolvers on TCP/443 and UDP/443 is the plan they came up with. Brilliant!.. But wait!.. What about all the other freely available DoH services?.. Ok!.. They will also add them to the list one by one later on. Sounds like a done deal, right?..

It would seem so, till we know that it's easy to set up your own DoH server [1], then it simply becomes mission impossible for our enterprise IT security Folks.

Just for the record. I'm not suggesting that circumventing DNS infrastructure in Enterprise environment is a good thing, especially when you have consented to stick to their internal rules and regulations. The point that I'm making is how desperate the situation is for those IT security teams facing DoH challenge.

@'Hidden Refuge' did bring up some folks attempts trying to single out DNS traffic over 443 in his 'DNS-over-HTTPS (DoH) can be easily detected and blocked' thread, but I do think they won't get passed the proof-of-concept stage... But we'll see, who knows?.

--------
[1]- A how to set a DoH server is on my list of the upcoming threads in here (unless someone else write it in the meantime.)

[fChk]

[1]- A how to set a DoH server is on my list of the upcoming threads in here (unless someone else write it in the meantime.)

I did setup a private DoH server on @Neoon NAT-VPS and it did work perfectly with Firefox.

A HowTo thread coming soon this week-end on this sub-topic.

The tutorial is entitled 'How to Set up Your Own DoH Server on CentOS 8'; follow the link for more.


Edited on 15/02/2020, to add the tutorial link.

[humanpuff69]

I did setup a private DoH server on @Neoon NAT-VPS and it did work perfectly with Firefox.

A HowTo thread coming soon this week-end on this sub-topic.

is it uses like google or other dns for the dns database or you add each site and the ip to the DoH server?
i used to make DoH server before but it basically act like a proxy to insecure dns

[fChk]

is it uses like google or other dns for the dns database or you add each site and the ip to the DoH server?
i used to make DoH server before but it basically act like a proxy to insecure dns

Check this thread 'How to Set up Your Own DoH Server on CentOS 8'.