# Does a trace of SSL packets provide a proof of data authenticity?

I'm wondering if it would make sense to record a whole HTTPS session, publish its encryption keys and present it to third parties as a proof that this particular data was sent by a given server identifying itself with some signed certificate. Could such proof be forged in any way? Should this proof be convincing to third parties who receive it?

(I've posted separately on StackOverflow to ask how to implement this process. In this question, I'm interested in learning about whether such a "proof" can be forged.)

-
Don't cross-post. The second half of the question is off-topic here. –  CodesInChaos Nov 22 '12 at 16:28

The server doesn't sign the data itself. It only signs part of the handshake if you're using a signing based suite. That means you can prove to a third party that a handshake with a certain server happened, and what data was exchanged in that handshake.

If you're using a RSA encryption suite, it doesn't even sign the handshake, but authenticates indirectly by proving that it can decrypt a client chosen key encrypted with its public key.

The actual connection is encrypted and authenticated using symmetric operations. Anybody who knows those symmetric keys can forge a ciphertext that decrypts and authenticates successfully with these keys. So you can't prove which data was exchanged.

In conclusion you can at most prove that a handshake happened. If you want stronger proof, you can use a scheme that signs the actual message, such as PGP.

-
SSL also provides integrity. Is this mechanism symmetric too? –  Smit Johnth Apr 4 '13 at 19:34
@SmitJohnth Non handshake data is authenticated with a MAC, so it's symmetric and can't be used to prove who authored that data to a third party. –  CodesInChaos Apr 6 '13 at 19:00

To complete what @CodesInChaos explains:

• If the server has a RSA key in a certificate which is suitable for encryption, then anybody can forge a completely fake conversation without the server being involved at all. In the SSL/TLS protocol, when using a "RSA" cipher suite, the client generates the random "pre-master secret" which it then encrypts with the server's public key; the server merely decrypts it. The attacker then just has to play the roles of both client and server, and speak with himself. In a normal SSL/TLS situation, outsider cannot fathom the SSL connection because they only observe the encrypted pre-master secret; but our envisioned attacker chose the pre-master secret, so he knows it perfectly. The same reasoning applies to the case of a server with a Diffie-Hellman certificate (but who does that anyway ?).

• If the server key is not suitable for encryption, but for signatures (e.g. it is a DSA or ECDSA key, or it is a RSA key but the server's certificate contains a Key Usage extension which restricts it to signatures only), then the attacker must "prime" the attack by contacting the server once. With the "DHE" cipher suites, the server generates an ephemeral Diffie-Hellman key pair, signs the public key, and sends it to the client. Once the attacker has a nice signed DH public key from the server, he can use it to build fake SSL connections (as many as he wishes).

The problem is a bit more interesting in the other direction: the server recording a SSL/TLS connection with certificate-based client authentication, and wanting to use it as a proof. The signature computed by the client happens during the initial handshake, and everything which is sent afterwards is encrypted and MACed with the agreed-upon symmetric key, which both client and server know, so the server could fake it at will. However, what the client signs is a hash of all preceding handshake messages, which includes the server's certificate, and also the client random and server random. An interesting point is that the first four bytes of the "client random" are not random at all; they are supposed to encode the current time, with second accuracy.

Therefore, by recording the handshake messages of a SSL connection with certificate-based client authentication, one obtains a proof that the client did connect to a specific server, and even at what time the connection happened (note that the time is relative to how well the client system clock is adjusted; I have encountered personal computers which were off by several years, to the blissful ignorance of their owners). Of course, it says nothing about the data which was exchanged afterwards.

(Whether this "proof" would have any legal value is another, quite distinct subject; I am only talking about the cryptographic half of the problem.)

-