Hacker News Reader

Comment by k__ | Hacker News Reader

Half-OT

Is there any way to account a response of a TLS enabled server to it's public key?

Something like reverse fingerprinting?

Do you mean that you can prove to a third party that a TLS transcript is accurate? Then the answer is no. TLS authenticates application data with a symmetric algorithm based on a negotiated secret. To verify authenticity, you need to disclose that secret, but you can also use the secret to authenticate a made-up application data stream. I think it's still possible to prove that a decryption is correct if everyone agrees that the ciphertext is genuine, but that's the extent of it.

It is technically possible to verify the authenticity of a TLS transcript without disclosing the secret key. You would need a zero knowledge proof. Where you prove that you know a key that is consistent with the TLS handshake and that is consistent with the symmetric part of TLS.

If the cipher suite used has authenticity in the symmetric part, that proof would be enough.

There are no implementations of this to my knowledge, and all the general zero knowledge proof caveats of speed, proof-size, etc all still apply.

It is definitely possible though. It would be cool to make. Why would anyone need this though?

See https://eprint.iacr.org/2023/1022. Not only is it implemented, it is reasonably efficient (e.g., on the order of a couple seconds)

This seems to be the other direction. I assume the question was about extracting a cryptographic proof from a TLS session that (say) a bank statement downloaded over HTTPS (in HTML, no API) has not been tampered with. I really doubt this is possible, and quite a few TLS users would treat such an unexpected non-repudiation property as a vulnerability in TLS.

The TLS session, and the 'secret inputs' to the TLS handshake, will always give proof that the received message originated from a TLS session from someone who held the private key to the used certificate. Or from someone who received a session key from that private key holder.

If you want to fix this, you need the authenticity of the ciphertext to be proven to the recipient without the recipient being able to transfer it. An interactive zero knowledge proof could maybe do that.

Yes, as far as I understood DH, the symmetrical keys don't have any mathematicial relation to the asymmetrical ones.

I guess, the only reliable way is to sign the response, which requires changes to the server

What do you mean? The asymmetric ephemeral keys used in a TLS handhake with Diffie Helman result rather directly into the symmetric session key used by TLS. The signature of the handshake with the certificate links the ephemeral keys to the certificate, and hence the symmetric session key is linked mathematically to the certificate.

What I wanted to say is, the session key isn't generated from the private keys of either party.

If I sign any data, it's mathematically linked to the certificate, but that doesn't mean the cert was involved in creating the data.

That's what I meant with a common understanding of what the ciphertext is.

I don't think this is possible if all you have is your own recording of the ciphertext, with no proof that it was actually transferred over the wire. This is the typical situation with packet capturing at one endpoint only.

A few days, I read that someone claims to do that.

But there was no background info. Just "We use ZKP to prove we got the right data"

So, it's technically possible?

I feared so, thanks.

I was hoping responses were signed.

https://security.stackexchange.com/a/231019/70830

have a look at this https://tlsnotary.org/

Reply on news.ycombinator.com