Does the SSL/TLS client certificate "hash over all previous messages" step hash the entire TCP packets or just data?

Question

We have which uses TLS client certificates as it's authentication mechanism between client and server.

There is an IT department which wants to run this app through a firewall/proxy device of some sort, (client app is on the internet, server is behind their firewall/proxy device) and apparently they want to modify the TCP headers in some way (I'm not sure exactly what this entails and I've been unable to find out).

The IT department tells us they have this working with other apps using SSL or TLS, but none of these apps are using client certificates.

At any rate, the secure connection is failing. As far as I can tell from reading documentation, the handshake process is not fundamentally different in the prescence of client certificates - the symmetric encryption key is still derived in the same way, etc.

But, a thing that looks like it might fail is the "hash over all previous messages" step, wherein the client generates a hash of all the previous things it has sent to the server, signs it with the client-cert's private key, and sends that to the server.

So, does this "hash over all previous messages" step include the TCP headers? And thus, would this IT department be causing it to fail by modifying the TCP headers?

If not, what exactly does it mean?

Thanks for your time

Answer 1

It is only a hash over the TLS messages themselves, and not the TCP data. TCP data is frequently modified in-route (think NAT, etc.) so attempting to hash that would be futile.

Without knowing more about how it's failing, it's hard to say what the cause is. For example, if they're performing SSL MITM, then it would fail with client certificates, even if their server certificate was accepted. Another possibility is that they're using some IPS-type device that drops unrecognized packets, and it doesn't recognize client certificate messages.

A PCAP of the session might shed more light.