Hacker News Reader

Comment by vbezhenar | Hacker News Reader

I think that a big missing elephant is a tool which provides authenticated download.

What I mean is the following:

Let's say that I'm downloading PDF from mybank.com. Browser establishes TLS connection to the mybank.com, sends request, receives response PDF and then does something with response. This TLS connection could be serialized as it is with accompanied ephemereal keys. Those bytes include remote peer X509 certificate signed by digicert and the whole exchange is further cryptographically signed with corresponding key.

So basically you already have cryptographically signed PDF from your bank. You just don't have tools to save or verify this signature. And juridical framework to further act on those artifacts. But tech is deployed for 30+ years already.

View on HN

No, what's tied to the certificate is only the identity of the endpoints, not the content being transmitted (since that's only protected by a symmetric key both sides know), so you can forge a "recording" of a HTTPS session for any file you want.

There have been proposals to extend TLS to have this capability, but to my knowledge none are really standardized or used anywhere.

Thanks, this is unfortunate.

Wouldn't an ability to "forge a recording of a(n) HTTP session for any file you want" mean that you can implement a transparent HTTPS/TLS proxy that allows MITM attacks?

To deliver any file over TLS, you need access to the private key part of the TLS certificate, and to decrypt it, you need the public part. Having a recording of unencrypted raw TLS session along with the public key part would allow decrypting the stream later, while making it impossible to forge any data not coming from the identity controling those private keys.

For proper verifiability in the future, you'd want more details from the certificate and CAs (like verifiable way to ensure certificate was not revoked at the time of download), but there is already an asymmetric encryption happening at the TLS level.

Now, you can still forge some parts by omission: if you've got streamable data (requiring no random seeks), you can cut off parts of documents while maintaining encryption: you still can't modify it otherwise.

What am I missing in your claim of forging a "recording" of an HTTPS session?

Asymmetric cryptography is only used in the TLS handshake. The TLS handshake ends with both parties having a shared symmetric key only they know. The handshake can't be completed without the server having access to its private key.

Everything after that only needs the symmetric key. That both sides know, and thus both sides can generate whatever they want to put into a recording, and you can't verify if it is correct or not. All a third party can verify given a detailed recording is "this client did access the bank web server and completed a handshake with it".

Thanks for the details: I am surprised I never came across those details before, but that's obviously on me :)

We thought about it from the other side, we want to make it easy that just every PDF gets signed. We know it is not perfect, but it is better than not signatures at all. Inspired by LetsEncrypt

https://github.com/open-pdf-sign/open-pdf-sign-configurator/...

Reply on news.ycombinator.com