Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to proxy a mobile app (with Fiddler), which sends a client certificate to the server it connects to. I would think that capturing traffic with Tcpdump, retrieving the client certificate and using it with fiddler would be enough to bypass this.

However, when I capture packets using Tcpdump without a proxy, I notice that the server sends some certificates, asks for a client certificate, and the client sends an empty certificate (certificate's length was 0). After the whole SSL process, application data is sent normally, and the app works fine after that. The fact that a certificates length 0 is accepted made me think that any certificate would be accepted, but this does not seem to be the case.

I do indeed pass a fake certificate to Fiddler, and I see a similar entry again (certificates length 0), such that makes me think that I am missing something on how the client sends the certificate.

After the SSL process, I get a server Encrypted Alert and the app won't work at all. So, I am wondering, why do I get a 0 certificate's length even though I send a certificate? Even if fake, shouldn't I be seeing it in Tcpdump?

share|improve this question
up vote 3 down vote accepted

In TLS, after presenting its own certificate, the server may ask for a client certificate (CertificateRequest message). The request contains the list of the CA names that the server will use to validate the certificate. The client must then respond with a Certificate message containing a matching certificate: the client will scan the certificate it owns for one which has been issued, directly or indirectly, by a CA whose name is one of the names specified by the server.

If the client does not have a matching certificate, then it must send a Certificate message with an empty list (which is what you observe)(in SSL 3.0, in that situation, the client omitted the Certificate message altogether, but since TLS 1.0 an empty Certificate is mandated).

When the client does not present a certificate, it is up to the server to decide what to do next. The server may accept the connection nonetheless. In IIS configuration, that's the difference between "request certificate" and "require certificate". Among possible behaviours, the server may accept the connection at the SSL level, and then fall back to an application-level authentication protocol within the tunnel (that, from the outside, would appear as "encrypted application data").

Therefore, either you do not have a matching certificate on the client side, or the client does not notice that his certificates are matching, e.g. for lack of an intermediate CA (in the case root -> intermediateCA -> end-entity, and the server sends the name of the root, but the client knows only "end-entity").

share|improve this answer
that totally makes sense, i was thinking on similar lines, but the problem is that there's no other authentication happening. I do see a 0 length cert sent, so it seems as if the client cannot find a cert. It does work though when not using a proxy but does not when i do use one :/ – Spyros Jul 23 '13 at 14:09
The behavior is that the app hangs when a proxy is used. I have tcpdumped both situations and both times a 0 cert is sent. The only difference is that when proxied, no application data is sent, only an encrypted alert, and the app hangs. I am wondering whether this is some kind of protection. – Spyros Jul 23 '13 at 14:13
Might you need the server cert, and not the client cert then? – schroeder Jul 23 '13 at 21:08
no, i have already bypassed the server cert, this is a client cert needed here. – Spyros Jul 24 '13 at 5:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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