Ask HN: Are signed URL previews feasible?
For centralized public services the server can just retrieve the preview and serve it. But for decentralized services like Mastodon either every server has to fetch the preview on its own leading to lots of traffic and potential discrepancies between the previews served by different servers or the origin home server sends the preview but now everyone has to trust that it is authentic. The home server to which a link gets posted could place anything as its preview and thereby indirectly impersonate the URL and fake its content.
For E2EE messengers things are even more annoying because you do not want the servers to see the URL at all. So either all parties have to retrieve the preview on their own meaning they have to connect to a random, potentially malicious URL or only the sender does and everyone has to trust the sender that the preview is authentic which is a great opportunity for scams.^1
The perfect solution would be a standard for web servers to sign URL previews with their CA issued certificate. So that you can always proof that a preview is authentic. RFC 9421 already standardizes this. But this will not happen. There is virtually no chance of widespread adoption.
So my idea is:
You retrieve a webpage and record the whole TLS session including certificates, MACs and your key material like nonce and client random from the handshake. Now you use this as the basis for the URL preview. When you include your secret material from the TLS handshake anyone should be able to verify that the content is authentic from the server serving the URL due to the CA certificate and authentication of TLS traffic.
Standardize the request headers and limit the response length. Just cut off everything after the limit. Define some algorithm for computing the preview that ever recipient can verify. If you want to include linked images in the preview that increases complexity but should be doable. Repeat the whole thing with the linked image and create a bundle from all requests that authenticates the preview.
The downside I see is complexity and the need for the receiver to parse the preview bundle which might be attack surface.
Does anything similar already exist? Am I missing something or do you think this might be feasible to implement?
[1] Many messengers solve this by providing a URL preview service on the server. The client sends the URL to the messenger service which retrieves (and signs I hope) a URL preview which the client then includes in the message. This has the advantage that none of the parties of the conversation has to directly connect to an untrusted UTL. This bypasses E2EE for URLs. You can usually opt of this by disabling previews. Consider this if you did not know about this.
4 comments
[ 0.30 ms ] story [ 7.8 ms ] threadRecording the TLS session doesn't work. The content is only authenticated with a symmetric session key. The content is not signed by the server's private key.
The site content is authenticated with the symmetric key.
The symmetric key is authenticed with the private key.
That led me to jump to the conclusion that the content is transitively authenticated with the private key. But the security model of symmetric and asymmetric authentication schemes is of course very different. The server's private key is never disclosed so you cannot use it to forge the key exchange. But the symmetric key is of course shared and only defines a single level of trust: You either have it, meaning you can both verify messages but also sign arbitrary messages. For the purpose of transport security that is perfectly fine as both parties have full trust in each other for this purpose (the whole point is to guard the connection against anyone else), but for public authentication you need an asymmetric structure that allows verifying without the ability to sign. Symmetric cryptography by design does not enable this.
It is irrelevant that the symmetric key is authenticated with the server's private key because the presupposition that the symmetric authentication works is flawed. Verification by the untrusted public is a different scenario from verification by the two trusted parties of the communication and the presuppositions do not carry over.