---
title: TLS Client Authentication Leaks User Info (pre-TLS1.3)
description: >
  TLS Client Authentication Leaks User Info (pre-TLS1.3)
posted: !!timestamp '2018-10-15'
created: !!timestamp '2018-10-15'
time: 10:54 AM
tags:
  - TLS
  - security
---

It's been long known that TLS is not the best privacy protecting
protocol in that SNI leaks what domain the client connects to.  I'm a
bit surprised that I haven't seen the failure to protect user
information when using client authentication mentioned, but it's likely
that TLS client authentication is so rarely used, that this have not
been on anyone's radar.

TL;DR: Just don't use TLS client authentication on anything before TLS
1.3.

With TLS 1.2 and earlier, if you use client authentication, the client
certificate is transmitted in the clear.  This contains enough
information to uniquely identify the user.  If it didn't, then there
would be no way for the server to do the authentication.

The danger of this is that Eve (eavesdroppers) on path will be able to
track your user's (or your) connections, where they connect from, figure
out how much data they transfer between to/from your site and likely
profile their usage.

I was confident that this was the case as I know that the entire
handshake is in the clear.  It isn't till the Finished messages that
the session becomes encrypted.  (TLS 1.3 fixed this by using a new
derived key, `[sender]_handshake_traffic_secret`, to encrypt all the
server params, which the client will use to encrypt it's response to
the certificate request in the server params.)  I decided to verify
that this was the case.

I generated a server and a client certificate and key:
```
openssl req -batch -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout server.key -out server.crt
openssl req -batch -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout client.key -out client.crt
```

I then launched the server, and included the `-Verify` and `-CAfile` options
for `s_server` to request a client certificate:
```
openssl s_server -accept 5829 -cert server.crt -key server.key -Verify 5 -CAfile client.crt -debug
```

Then I ran tcpdump to capture the session:
```
sudo tcpdump -s 0 -n -i lo0 -w clientcert.tcpdump port 5829
```

And then the client to connect to the server:
```
openssl s_client -connect localhost:5829 -key client.key -cert client.crt -debug
```

A usual, non-client authenticated connection and close was about 17
packets, but when I included the client authentication, it became 42
packets (the answer!).

I loaded the packet capture into wireshark, applied the SSL protocol
analysis and confirmed that the client certificate was present in clear
text:
[![Wireshark shows TLS handshake with client authentication, with the client certificate displayed in plaintext.]([[!!images/tls.packet.capture.screenshot.png]])]({{ media_url('images/tls.packet.capture.screenshot.png') }})

So, there you have it.  Do not use client authentication, pre-TLS 1.3,
if you care about the privacy of your users.

It is safe to use client authentication w/ a TLS 1.3 server as long as
the server requires all clients be 1.3 clients.  If the key exchange
algorithm is one of DHE_DSA, DHE_RSA, or an ECDH key exchange algorithm,
the random bytes in the Hello messages are signed and these bytes are
used by TLS 1.3 for downgrade protection.  As the signature covers these
bytes, the client would be able to detect any attempts to modify the
server or client handshake messages to force a downgrade before it would
send the client certificate.

Thanks to Mike Hamburg for reviewing an earlier version of this blog
post and pointing out that TLS 1.3 was not vulnerable to this and
helping w/ some of the research to prove it.

References:

* [TLS 1.2 Protocol Diagram](https://tools.ietf.org/html/rfc5246#page-36)
* [TLS 1.2 ServerKeyExchange](https://tools.ietf.org/html/rfc5246#page-52)
* [ECC Cipher Suites for TLS ServerKeyExchange Signature](https://tools.ietf.org/html/rfc4492#page-20)
* [TLS 1.3 Protocol Diagram](https://tools.ietf.org/html/rfc8446#section-2)
* [TLS 1.3 Server Hello](https://tools.ietf.org/html/rfc8446#section-4.1.3) Downgrade Protection