Signed HTTP Exchanges
The Signed HTTP exchanges draft (IETF draft) allows a publisher to sign their HTTP exchanges and intermediates to forward those exchanges without breaking the signatures.
What does that even mean?
Signed exchanges serialize an HTTP request and response into a binary representation called CBOR (RFC 7049). This payload is then encoded according to the MICE spec (Merkle Integrity Content Encoding), which provides progressive integrity for the serialized CBOR. This means that the content cannot be modified without invalidating the encoding. Finally, this encoded payload is signed using a private key associated with the CBOR-encoded public certificate served from the same domain serving the signed exchange. For instance, the public certificate for this site is hosted at this endpoint. This allows third parties such as Google's AMP cache to cache signed exchanges, and the browser can verify the source of the content, and display the proper URL. When a signed exchange is served from a third party, the browser parses the signed exchange, and can validate the integrity of the content, and verify that the signature is valid using the link to the public certificate. Our primary use case is for AMP pages, but there are many other uses for signed exchanges, and we're excited about this new technology. More info can be found in this explainer.
Cloudflare can generate signed exchanges using Workers!
Turn on this Requestly rule and the following links will send signed exchanges. Watch the network tab to see that a signed-exchange is served instead of a document