new | show | ask | jobs Github

okasaki 3 days ago

You would have to install a certificate for that to work.

▲

aaronmdjones 3 days ago | parent [-]

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.

▲

dbmnt 2 days ago | parent [-]

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.

▲

aaronmdjones 2 days ago | parent [-]

> 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.

▲

dbmnt 2 days ago | parent [-]

Ah, ok... a transparent proxy just to hide the origin IP. Thanks for clarifying. A lot of people are assuming full proxying, but I understand you were describing a hypothetical.

	▲	aaronmdjones 2 days ago \| parent [-]
		Right. What I proposed is scarcely different from doing HTTPS over a SOCKS5 proxy. It's just that the proxy would infer your destination from the ClientHello rather than being instructed by the client in advance (Edit: and it would have to assume port 443 -- a safe assumption in the context of a service whose feature is bypassing website content blocking).