Hacker News Reader

Comment by _0w8t | Hacker News Reader

I can see how DNS over HTTPS addresses security, but I do not see how it helps with privacy. After resolving the IP address over secure connection HTTPS still sends the host name unencrypted, so one can just eavesdrop on that. And if encrypted DNS becomes widespread, I suspect that various state-imposed firewalls like one Russia will just look for HTTPS connection header to block a particular site.

View on HN

The industry stance seems to be: SNI not yet being fixed should not be an excuse to preclude work on securing the privacy of DNS requests. SNI Encryption is being discussed: https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.p...

We at DNSFilter are working on client to resolver agents which use DNS over TLS as well as DNSCrypt. We're also looking to create a standard for recursive resolvers like us to communicate securely with authoritative providers (no RFC yet).

>HTTPS still sends the host name unencrypted.

needed for webservers because of multiple domains (SNI) on single IP address. Didn't read the spec, but couldn't be hostname encrypted in case of DNS resolving? (eg. hostname can be sent in http body).

Well, unencrypted data by nature are vulnerable to tamper. Say change the DNS answer to point the client to another IP address in this case.

Of course DNS over HTTPS is not a sliver bullet that will ensure your privacy, instead, it's one step towards better security and thus (hopefully) privacy.

> After resolving the IP address over secure connection HTTPS still sends the host name unencrypted

Correct me if I'm wrong, but I'm pretty sure the host name is generally only sent in an HTTP header, which should be encrypted over HTTPS.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ho...

No, in order to multi-host SSL sites the host name has to be sent first in order for the correct certificate to be presented.

https://en.wikipedia.org/wiki/Server_Name_Indication

You don't even need SNI; the initial Server Hello, which contains the server's certificate (which contains the DNS name the certificate is issued for) is sent in the clear.

No longer true in TLS 1.3 as I understand it

The ServerHello starts out by finishing key agreement and then (in the same message) it assumes its peer now knows the session key and encrypts the rest of the message, including Certificate.

Interesting; do you have a reference? In particular, how does it complete key agreement without the certificate? The first thing that comes to my mind is that in order to build the encrypted connection, you need to know who you're building it with, i.e., you need the certificate. You could build an encrypted connection with just whoever is on the other end, and then exchange the cert, but I would wonder then how you would prevent a MitM from just building two connections and forwarding the content across. (Though that would defeat a passive listener, at least.)

(Essentially, the problem is that prior to requesting the certificate for X.com, you need to know that you're talking to X.com; a sort of authentication chicken and egg.)

The TLS 1.3 drafts (and given they're in Last Call, presumably the RFC itself once published) use different types of brackets to indicate whether and how things are encrypted in the ASCII art diagrams. The curly braces {} are used for the Certificate structure, meaning it is encrypted using the session keys but it is NOT authenticated application data yet. We'll see why in a moment.

So, firstly I'm going to say, go read the drafts for yourself https://tools.ietf.org/html/draft-ietf-tls-tls13-23 because I am pretty sure that's the most snarky response and also hey, it's right there, if I'm wrong that's a great place to start in proving so.

But then I'll answer your substantive question, because the answer is pretty interesting (and quite unlike earlier versions of TLS).

So, you are correct that we can (and TLS does) do DH without knowing who we're talking to, and that our problem is that although our session is encrypted and can't be eavesdropped, this seems useless because we don't know who the heck we're talking to, surely we can be subject to a Man in the Middle attack.

However, TLS 1.3 has a trick here, after sending Certificate the server sends CertificateVerify. CertificateVerify signs the entire key agreement (which we just did) with the identity from the Certificate. So, a client receiving CertificateVerify either gets a matching signature (the party we did our DH key agreement with _was_ the owner of the Certificate - good) or they don't (we're being MitM'd the phone call is coming from inside the house - get out!)

Once the client has checked CertificateVerify (and presuming they're happy with whatever was inside Certificate) they're truly secure and Application Data can begin to be processed.

In TLS, the server will send its certificate — and thus the domain name — in the clear.

> I suspect that various state-imposed firewalls like one Russia will just look for HTTPS connection header to block a particular site.

What if that site does a lot more things? Even they can only upset their population so much by blocking entire domains. With regards to Russia, Google's DNS over HTTPS is a perfect example. "Domain fronting" is a thing for a reason.

In Russia the government does ban domains unless the domains are popular. At some point they even tried to ban based on IP addresses from DNS records, but people quickly learned how to use that to "ban" government-based media by changing IP addresses of banned domains to point to those sites.

Are you talking about leaking names through TLS?

As I understand it, this would fix leaking during DNS resolution, fixing any leaks from TLS is a separate issue. And yes, when that's fixed, you'll still be leaking destination IP.

But if not one step at time, how is it going to get better? :)

One step, but in what direction?

Reply on news.ycombinator.com