Comment by cluckindan
Comment by cluckindan 6 days ago
Sure they can. When your browser resolves a host, they replace the actual IP with the IP of a proxy that is configured to forward traffic according to the Host HTTP header.
Comment by cluckindan 6 days ago
Sure they can. When your browser resolves a host, they replace the actual IP with the IP of a proxy that is configured to forward traffic according to the Host HTTP header.
No you wouldn't.
The current situation:
- You ask Foo DNS Provider for the IP address of pornhub.com
- Foo DNS Provider responds with the real IP address
- You connect to that address, send a TLS ClientHello containing a Server Name Indication extension of "pornhub.com"
What could happen:
- You ask Foo DNS Provider for the IP address of pornhub.com
- Foo DNS Provider responds with one of their own IP addresses
- You connect to that address, send a TLS ClientHello containing a Server Name Indication extension of "pornhub.com"
- Foo DNS Provider now knows that you intend to connect there, so it connects there for you and relays your ClientHello to it
- Foo DNS Provider then just acts as a dumb relay, passing everything back and forth with no modifications
- The certificate verifies fine because the traffic was not modified and it was presented by the party who controls the corresponding private key
- The website thinks you are connecting from Foo DNS Provider, not your real address
The only thing that would break this is ECH (Encrypted ClientHello), currently supported only by CloudFlare and Google Chrome (and its derivatives) as far as I know. This security feature is provisioned with ... DNS records! So Foo DNS Provider can simply indicate that the records required for ECH do not exist, and your web browser wouldn't encrypt the ClientHello. It's already tampering with the responses to address lookups anyway, so DNSSEC wouldn't be an issue -- you simply would not expect to be able to validate anything.
This is wrong. It shows a fundamental misunderstanding of how certificate authorities (CAs) work.
A certificate has to be signed by a trusted CA (one your browser already trusts).
A DNS provider could mint a self-signed cert for pornhub.com, but your browser would reject it immediately.
Even if they tried to trick a real CA, Certificate Transparency (CT) would expose the bogus certificate:
https://en.wikipedia.org/wiki/Certificate_Transparency
Instead, NextDNS is very likely abusing the EDNS Client Subnet feature to provide website operators with a spoofed client location. Much more simple and less nefarious.
> A certificate has to be signed by a trusted CA (one your browser already trusts).
Yes.
> A DNS provider could mint a self-signed cert for pornhub.com, but your browser would reject it immediately.
I never said anything about the DNS provider minting any certificates, and explicitly said that the certificate would be provided by PornHub's servers and merely relayed -- verbatim -- through the DNS provider. As well as the rest of the TLS negotiation.
> Instead, NextDNS is very likely abusing the EDNS Client Subnet feature to provide website operators with a spoofed client location.
That's what they are doing now, yes. What I propose is how they can continue to make it work once the website operators catch on and start looking at the ASN information of the source IP address of the HTTP connection.
I am well aware of how CAs and the Web PKI model and TLS work.
You would have to install a certificate for that to work.