7

In a scenario where there are client RSA certificates (e.g. on a smart card), is it possible to record a form submission (or an AJAX request) in a form which makes it possible to later ascertain that the client actually did send that information (e.g. containing a client's signature of temporary keys used to encrypt the data)?

I'm thinking of the result being something like a binary blob containing a trace of TLS traffic over TCP, enriched with data from the server which would make it self-contained.

If possible, is it possible without revealing the server's private key in such a blob? And can it be done with an existing TLS library without heavy modification?

| improve this question | |
8

No.

There is an even simpler scenario for this question, without the client certificate.

You ask, given pcapng / tcpdump / wireshark file of the entire communication session between client and server and an SSLKEYLOGFILE dump in NSS Key Log format so you could decrypt the stored traffic, is that proof that the server sent whatever the file says the server sent?

And the answer is no, it is not.

TLS does not provide non-repudiation. The signature is proof that you communicated with the other party, but it is not proof of when the communication took place (because gmt_unix_time is deprecated) and it is not proof of what was communicated, only that the communication took place (possibly without any application data being sent).

After the handshake, both sides have the same symmetric keys for both sides. Both sides can generate a transcript that shows the other side sent, encrypted and authenticated with the expected keys, any data. There is no way to know whether that is true or not.

To achieve non-repudiation, you would need to add a digital signature at the end of the connection, signing a hash of the entire connection until the disconnect message was received. But there is no such feature in TLS.

Alternatively, you would need your friendly local sigint intelligence agency to provide a packet capture file that they certify is authentic, and one of the sides of the communication to provide SSLKEYLOGFILE dump, and then you would know that some packets were really sent in that direction and the cleartext data.

| improve this answer | |
  • So, the client cert phase in TLS basically only serves to prove to the server that the client is in possession of a private (RSA) key belonging to a cert? – Ivan Voras May 4 at 21:21
  • 1
    Yes, exactly. If you are the server, you know you're communicating with someone who has the client certificate's private key, and you know since you yourself are not faking the transcript, what you receive was sent by the client. But after the fact, the transcript only proves that at some point in time, someone who had the private key signed the handshake, because the server can fake the entire transcript after the handshake. – Z.T. May 4 at 21:35
  • If it had non-repudiation I could still make a client that always returned the wrong signature at the end. Sure it's obvious, but ... – Joshua May 4 at 21:55
  • Does that hold true for all cipher suites? Is there really no cipher suite in which one side encrypts a symmetric key so it's decrypted by the other's private key, PGP-like? (I know that would break the idea of ephemeral keys) – Ivan Voras May 4 at 22:05
  • 1
    The so called RSA key exchange, which is not allowed in TLS 1.3 because it does not provide forward secrecy, doesn't help you. It doesn't sign the data sent after the handshake. – Z.T. May 4 at 22:09
3

The certificate of the client is only used to authenticate the client. It is not used in key exchange which happens before the client even sends the certificate and proves ownership of the private key. The client certificates is thus neither directly nor indirectly included in the traffic encryption or MAC. This means that capturing the TLS traffic can not be used to proof later that the client has send specific data.

See also a similar question which is about proofing that the server has send something: How to prove some server sent some file over HTTPS. The basic answer is the same: no site is signing the application traffic with their own private key but encryption and MAC are only based on a shared secret created during the key exchange.

| improve this answer | |
3

See answer by Thomas Pornin at https://crypto.stackexchange.com/questions/5455/does-a-trace-of-ssl-packets-provide-a-proof-of-data-authenticity. Like the other answers here, Thomas Pornin explains that the signature by the client cannot be used to prove anything about the information that the client sent to the server during the session. However, the server may be able to use the signature by the client to prove that the client connected to the server at a specific time.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.