3 ms·

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

by detaro 4y ago

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.

vbezhenar 4y ago
Thanks, this is unfortunate.
necovek 4y ago
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?
- detaro 4y ago
  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".
  - necovek 4y ago
    Thanks for the details: I am surprised I never came across those details before, but that's obviously on me :)

by detaro 4y ago

vbezhenar 4y ago

Thanks, this is unfortunate.

necovek 4y ago

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?

detaro 4y ago
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".
- necovek 4y ago
  Thanks for the details: I am surprised I never came across those details before, but that's obviously on me :)