Hacker News Reader

@freeone3000, that's incorrect, in the case of Signed Exchanges. Chrome will verify the document's signature against the publisher's public certificate. This will be `nytimes.com` for example. It is not using Google's certificate for this verification, and Google does not possess the private key required to modify the content and update the signature.

View on HN

The actual mechanism by which a signed exchange is implemented is prone to man in the middle attacks by removing the Signature field wholesale. You are not requesting info from nytimes.com, you're requesting info from amp.google.com and trusting that the backing data is accurate. There's no need for a certificate to be presented at ALL! Unless it can be determined that such a header should exist, there's no way to verify its absence.

All this means is that any server can choose to present any bytes, even with TLS, as a response to any request. This isn't a novel observation.

If a signed exchange includes a URL, that URL must be signed for the browser to respect the field.

Right, but this means proposing signed exchanges as a solution to AMP's strategies is kind of nonsense, since it's a semantic problem whether a page is acting as a proxy for another, and a technological solution doesn't work here.

Reply on news.ycombinator.com