Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Seems very marginal for privacy when people in the middle can still see the IP you're connecting to, just not which DNS record you may have retrieved the IP with.


Run wireshark on an ssl connection. The server certificate is sent in plaintext. It includes the DNS name of the server you connected to.

DoH would make sense in a world where that was fixed. (Though DNS over TLS is also a thing, and makes strictly more sense than DoH from what I can tell...)


> The server certificate is sent in plaintext.

Not with TLS 1.3, which moves the server certificate to the encrypted part of the handshake.


This is why people are also working on shipping ESNI, which will stop sending the DNS name in plaintext in the cert.


It's actually quite massive. Most sites (well not most, but a lot) sit behind something like cloudflare, so your scummy intercepting ISP would only see a connection to cloudflare. Of course none of this really means too much until encrypted SNI is a thing but it's a definitely a lot more than marginal imo


You can sort of assume anybody paying any attention to traffic is sniffing the SNI information, it's pretty obvious.


Encrypted SNI is a parallel and related effort to that, though.

So hopefully not a cause that's lost forever, but we can improve more in the future.


Not all ISPs around the world have the resources to do that. It also doesn't have to be 100%, we just have to make it difficult (or more expensive) and that helps.


Good point. Sniffing traffic is orders of magnitude more expensive than simply logging DNS queries.


    tcpdump -i any -s 1500 '(tcp[((tcp[12:1] & 0xf0) >> 2)+5:1] = 0x01) and (tcp[((tcp[12:1] & 0xf0) >> 2):1] = 0x16)' -nnXSs0 -ttt
Is it though? This one liner works just fine for me on my gateway and is capturing quite a huge number of raw SNI names.

     0x0110:  c008 0016 0013 0010 000d c00d c003 000a  ................
     0x0120:  00ff 0100 0113 0000 001d 001b 0000 186c  ...............l
     0x0130:  6f67 7369 6e6b 2e64 6576 6963 6573 2e6e  ogsink.devices.n
     0x0140:  6573 742e 636f 6d00 0b00 0403 0001 0200  est.com.........


It's not complicated, but that's also going to take more time , cpu power, and memory bandwidth to do so than just recording dns packets. When you need to do that to millions or billions of connections per second the costs start to really add up.


It’s just bitmask and slicing basically, that would work just fine even on hosts with obscene amounts of traffic.


It gets more difficult when you deal with aggregated traffic in the 10s or 100s of Gbps.

But yes, it is possible.

One thing is though - TLS1.3 is getting more popular and so is session resumption. So even now quite a bit of traffic cannot be identified and it will get harder and harder.

Encrypting DNS requests is one required piece of the puzzle.


Sure, that would work for a SOHO gateway, but at ISP scale that's a ton more traffic to be sniffing.


It's far easier for ISPs to scrape up your DNS queries (they run the resolver) than it is for the to make correlations based on IP addresses, especially with multiple websites hosted on the same IP.


So all DoH does (once ESNI is eventually a thing) is alter this equation. ISPs will simply begin correlating IPs (and CT logs: http://blog.seanmcelroy.com/2019/01/05/ocsp-web-activity-is-...) instead.


Soon to be resolved by IPv6 everywhere.


Isn't it the opposite? With DoH, ISPs now have another incentive not to boost IPv6 adoption.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: