Hacker News Reader

Comment by asddubs | Hacker News Reader

i assume in days of https, most of the history they would be able to obtain are only domain names, not specific URLs, right?

View on HN

Hence the desire to backdoor all encryption to see the full juicy details. Also the reason DNS over HTTPS exists and is spreading.

Does DNS over HTTPS allow the dns provider to see beyond the domain name?

Since DNS (Domain Name System) only deals with the domain names themselves, any DNS resolver (communicated to via HTTP, TCP, UDP, QUIC or what have you) will only resolve a domain name => IP address. Adding a path in there makes no sense.

They can see the IP address of the machine making the request, if that's what you mean.

I am guessing the parent commenter is wondering if the full URL can be deciphered from DoH.

In the way DoH is being used in practice, it alllows third parties to collect histories of DNS lookups for myriad users, separated by individual program. In other words, the third party can tell which program was used by a given user to initiate any given DNS lookup. The program often reveals identifying information about the device on which it is installed. Other parties collect user data pertaining to IP address and device.

Device fingerprinting, i.e., associating a given user with a given device, is in widespread use purportedly "as a security measure" by "tech" companies like Facebook. Can we be sure the data collected is also not being used for other purposes.1

Combine the DNS program+IP fingerprint with, e.g., a web browser+IP fingerprint and now we can potentially identify a user from DNS lookups.

Now consider that Facebook prefixes all external URLs posted to Facebook pages (including external URLs posted in messages) so that any clicks on these URLs are captured, and the HTTP requests to non-Facebook sites are redirected via Facebook servers, again as a purported "security measure". Can we be sure the data collected is not also being used for other purposes.1 Thus Facebook has a history for each user of the URLs in Facebook pages/messages that the user clicks/follows.

The problem with DoH in practice is that it is being used almost exclusivelt to provide third party DNS. When we use third party DNS we give anyone (e.g., a "tech" company, a government, etc.) the potential opportunity to obtain from the third party (e.g., through subpoena, acquiring assets through merger, undisclosed data breach, etc.) complete DNS lookup histories for users' individual programs. There is no need to do this because there is no technical need to use third party DNS. And, of course, DoH does not have to be used only by third party DNS providers, so DoH itself is not the problem.

1. If I recall correctly, Facebook in the past has been caught lying about collecting telephone numbers "only" as a security measure.

Makes sense, thanks for explaining the bigger picture.

Except if you have a root certificate, then you can MITM you heart away. Which govs probably have.

yes, but it'd be the ISPs storing the internet history

Backbones have the reputation of being filled with intercepting devices from various entities, including gov's own.

wouldn't certificate pinning partially prevent this though? i'm not saying this is impossible, but for regular ISP-logged data that some schmuck wants access to, rather than a 3 letter agency or whatever, i doubt this is much of a concern

Intercepting at line rate isn't a thing. Recording absolutely happens, but that's why we're talking about End to End Encryption. It would suit snoops very much if what they recorded wasn't 90% unintelligible noise.

Right now they get a good idea which sites are visited (because of Server Name Indication) by web browsers, and they get some portion of email (sent in the clear) plus a small fraction of web traffic (HTTP-only) and numerous older unencrypted protocols.

In particular they also get most of DNS. DPRIVE work (DNS over TLS, DNS over HTTPS, and eventually DNS over QUIC) reduces that considerably. Future DPRIVE work also includes oblivious transfer (you ask say Google to do a DNS lookup on your behalf, they learn who you are and which DNS server was asked but not what you asked it, the DNS server learns what was asked but not who you are, you get your answer).

Or of course, if you're particularly worried, you use Tor and everything on the snoops' screens dissolves into noise.

A root CA certificate doesn't allow you to "MITM you heart away". Its purpose, as would be clear if you think about what the CA does with it, is to sign other certificates for keys which in turn are used to sign certificates that identify machines.

So first of all this hypothetical government would have to issue itself certificates for any sites it was interested in intercepting, and intercept the traffic to impose a MITM. It has to do this live or it won't work. Every time it does this, it provides the other participant a smoking gun, which is to say evidence - in the form of these bogus certificates.

But wait, if you run Chrome, Safari or similar browsers, these certificates just won't work. To be functional the government has to obtain proof they were logged for everybody to see - in the Certificate Transparency system. Without that the user just gets an error telling them the certificate isn't logged and can't be trusted.

If they were logged, we all get to see them. Do you see them? No, because this isn't actually a thing. It's a paranoid fantasy.

I think they meant unrestricted signing certificate. A few CA's have been caught providing this to external entities and have been pulled from trust stores. The cynical side of me assumes the behavior just moves to another shell company. For those curious how to mitigate or at least identify when this is occurring, you could trust transparency reports, or if you don't trust those, then log certificate fingerprints of the sites you visit.

  for domain in $(cat ./mydomains.txt); do echo -en "${domain} "; openssl s_client -servername "${domain}" -connect "${domain}":443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin; done|sort -k2 -t"=" | awk {'print $NF "\t" $1'} | column -t

  Fingerprint=4C:B1:F9:42:9A:58:CB:E2:7F:92:27:A9:41:5B:15:8B:01:3B:D1:64  ycombinator.com
  Fingerprint=98:70:50:FF:B9:05:CA:D3:A7:9A:85:96:C2:12:0D:B9:7C:03:A1:65  news.ycombinator.com

It's probably also worth logging the creation/expiration dates too, given that certs expire so much quicker these days. If you wanted to make this information even more useful, have people all around the world run this and feed it into a distributed database and log the ISP the test was run from so that you can see if a particular ISP has been compromised. That is how some folks I know in Africa found out their ISP was using BlueCoat proxies and that the certs were being installed as part of their ISP's required package downloads.

This seems like an over-complicated non-solution. If your browser is trusting some other root, you can see that information in the browser. For example if I click the padlock for this site, and pick More Information / View Certificate, sure enough this is a certificate issued from DigiCert.

But also, it's basically game over if you agree to run arbitrary software other people pick, so that's where the real problem is for the African case you describe.

What about specific lengths of the documents, linked from pages which may be known or be easy to guess (earlier visited, front page or known size)?

Correct

Reply on news.ycombinator.com