Comment by dbmnt

Comment by dbmnt 5 days ago

3 replies

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 5 days ago

> 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 5 days ago

    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 5 days ago

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