Comments on 2020-07-13 Client Certificates and IO::Socket::SSL (Perl)

I left a comment on the mailing list.

This is the short summary I provided:

In the TOFU world, the default OpenSSL setup doesn’t quite work. The default is that clients don’t send their client certificates to the server unless the server asks for them during the handshake. In the OpenSSL world, the server can be told to do this by telling it to verify the client certificate. When you do that, the server will then reject the connection because the client certificate is self-signed. In order to force the server to still accept it, you need to provide your own verification callback which simply returns 1 for all certificates in the chain of certificates the client presents you with.

“SSL_set_verify() sets the verification flags for ssl to be mode and specifies the verify_callback function to be used. If no callback function shall be specified, the NULL pointer can be used for verify_callback. In this case last verify_callback set specifically for this ssl remains.”

Keywords to look for in your SSL or TLS library’s documentation are “peer verification”, “verification mode”, “verification callback”, etc.

Once you have all that, then you can get the fingerprint of the client cert on the server side and compare it to the list of fingerprints you know (if you’re trying to only allow some people access), or save the combination of fingerprint and common name in your database if you want to create an account (like astrobotany does), or send a 60 code back if there is no certificate, or a 61 code if the fingerprint doesn’t match anything in your database, or a 62 if you decide to do further tests such as checking the validity start date or the expiry date of the client certificate.

Hope that helps somebody
Cheers
Alex


Only partially related, but here’s an interesting question: on the mailing list and on IRC, Luke Emmet said his clients was rejecting server certificates because the hostnames does not verify, the x509 didn’t match up.

What do other people think about this? My personal impression was that in a trust on first use (TOFU) world, the common name (CN) of a certificate could be anything. It could be “Alex Schroeder”, for example. Or it could be “alexschroeder.ch”. Even if it was served as the certificate for another domain, like transjovian.org. After all, the question is only whether you “trust on first use”.

My impression is that a client that tries to verify that CN and domain match is doing it wrong. What do you think? Sadly, my SSL know-how is weak, so any pointers to how things ought to work in a TOFU world are appreciated.

Cheers
Alex


Please make sure you contribute only your own work, or work licensed under the GNU Free Documentation License. Note: in order to facilitate peer review and fight vandalism, we will store your IP number for a number of days. See Privacy Policy for more information. See Info for text formatting rules. You can edit this page if you need to fix typos. You can subscribe to updates by email without leaving a comment.

To save this page you must answer this question:

Just say HELLO