When a TLS client's certificate is offered to the TLS server
Everyone knows that TLS servers have certificates and TLS clients check those certificates when they connect to the server. What is probably less well know is that TLS clients can have certificates as well, and the server can ask a client for a certificate as part of the TLS handshake. As the result of a Twitter conversation today, I wound up wondering and guessing if TLS client certificates get sent to the server after the connection becomes encrypted.
The short answer: they don't. The TLS 1.2 RFC's handshake protocol overview describes it in relatively short form and is explicit that the client certificate is sent to the server before the connection becomes encrypted, not afterward.
Does this matter? Yes, sort of. Because the TLS handshake protocol is not encrypted, a passive observer can eavesdrop on it and fully decode it. This is handy if you want to use wireshark to see what cryptography people actually get with your server, but it also means that a passive observer (such as an ISP) can see what client certificate is in use if you use client certificates. Since client certificates are hopefully unique, this allows such an eavesdropper to identify such clients. They may not know who you are, but they can correlate different clients by their certificates.
(If client certificates carry real identification of the user in the Subject Name field, an eavesdropper can read all of these out in plain text. Sadly I suspect that there are client certificates that carry such data, because putting all of the proper Distinguished Name details certainly sort of looks like the proper thing to do. This might be okay for client certificates that are intended to be used only inside an organization and never exposed over the Internet, but I would avoid it in anything intended for use across the Internet.)
The good news is that client certificates aren't used much from what I've seen. They may be more used inside organizations, but there the potential threat from eavesdroppers is hopefully much lower. And since client certificates are so little used, probably no one bothers implementing this eavesdropping attack in practice because the payoff is too low.
(The only time I've personally used TLS client certificates is for StartSSL. I assume StartSSL opted for TLS client certificates because they're probably harder for users to compromise than passwords, since you can't exactly write them down (although you can send them around in email and so on).)