Invalid responses to client certificate requests

[svkampen]

When connecting to servers which request a client certificate, but no client certificate is provided, invalid responses are sent.

In TLSv1.2, an empty certificate response should contain a certificate_list of length 0, i.e. the message length is 3 (one 24-bit integer, namely the length of the certificate_list, which is 0) (RFC link). Right now, a response with length 0 is sent:

Compare the correct response:

In tls_build_certificate, line 10019, we treat all_certificate_size > 0 differently from all_certificate_size == 0 -- simply treating both the same fixes the issue for TLSv1.2 (that is, we simply use the code in the if block for both cases).

Now, for TLSv1.3, we never even seem to send a reply to the certificate request, and I am not familiar enough with either TLSv1.3 or this library to know where the issue is, so I am hoping it is more obvious to you 😄 . (Sidenote: for TLSv1.3 debugging, it would be really nice to be able to export the keys in the SSLKEYLOGFILE format, so Wireshark can decrypt the encrypted handshake etc. It seems like it should be quite easy to implement, I have seemingly successfully exported the keys by hand and massaged them into the format, but I am a bit hesitant to say I have a correct implementation because I don't know the library well).

For reference, the servers I am testing against are public Gemini servers (e.g. geminiprotocol.net:1965), which often use client certificates as a form of authentication.

Lastly, thank you for building such a wonderful standalone TLS implementation! I am using it as part of Crypto Ancienne, and it is truly incredible to have TLSv1.3 on platforms that are older than I am.

[eduardsui]

Thanks for reporting this. I never really tested client certificates on TLS 1.3. I'll take a look today.

In tls_build_certificate, line 10019, we treat all_certificate_size > 0 differently from all_certificate_size == 0 -- simply treating both the same fixes the issue for TLSv1.2 (that is, we simply use the code in the if block for both cases).

Did you use the latest tlse.c?

[svkampen]

Haha, I figured client certificates are probably an area that doesn't see much testing.

Yes, this is with the latest tlse.c. I can reproduce it with the example in examples/tlsclienthello.c (replacing TLS_V13 with TLS_V12), using the host geminiprotocol.net and port 1965.

[0xVZ]

@svkampen Hey, i encountered the same problem, did you find a solution?

[svkampen]

@0xVZ Apologies for my late response, I was on vacation and totally forgot to reply haha.

I do have a fix for TLSv1.2, as described above (I have also attached it as a patch file, below), but it does not work for TLSv1.3.

Patch for TLSv1.2

[eduardsui]

@svkampen can you create a pull request for this?

Thanks!

[svkampen]

Sure, I've opened #127.