search

etcimon / botan

Block & stream ciphers, public key crypto, hashing, KDF, MAC, PKCS, TLS, ASN.1, BER/DER, etc.
Other
85 stars 22 forks source link

Partially fix OCSP validation #55

Closed CyberShadow closed 3 years ago

CyberShadow commented 3 years ago

I am thoroughly confused.

This library is advertised (here and here) as including a TLS client. However, upon trying to use the TLS client functionality in the most obvious way possible, namely making a simple HTTPS request, I've encountered numerous obstacles.

The first was the sheer amount of boilerplate required for the most basic functionality. It looks like all users of the library are expected to subclass TLSCredentialsManager, and even when they don't need to customize any of its functionality, "implement" all methods as stubs that call the parent class methods (which are all, for some reason, marked abstract). In my opinion, the more exposed knobs you have, the more opportunity there are for users to get something wrong; ideally, the library should provide a simple interface with some good defaults at the time of writing.

The second was lack of any functionality for using the host system's trusted root certificate authority store. OK, maybe this is understandable as this is a platform-specific detail that's hard to stay on top of; in any case, easily solved by packaging a trusted root CA bundle with your application (just remember to keep it updated).

The third was that OCSP validation, which, AFAIU, in lieu of a CRL, is a necessary part of validating the certificate chain, is completely broken. I can't see how the HTTP code for making OCSP requests could have ever worked at all. I'm not sure if this was a translation error or if it was broken in the C++ version too. OCSP validation also cannot apparently be turned off without entirely foregoing validation of the certificate chain; the only exposed switch is whether to validate the entire chain or just the first (youngest) certificate.

I had a look at what Vibe.d does. As far as I understand, the Vibe.d implementation simply does not validate the certificate chain, successfully establishing the connection whether it's secure or not. I could find no references to the tcp_message_handler hook, necessary for implementing OCSP validation, anywhere on GitHub. Am I really the first who has attempted to use botan's TLS client the "proper" way? Or have I made some gigantic misstep somewhere above?

In any case, here are some commits which I think improve the situation. I still don't have things quite working yet; the current obstacle seems to be that the OCSP response is signed with a certificate which is not available to Botan. (I would think that would simply be the issuer certificate, as the CN seems to imply, but apparently that one isn't flagged for the use of signing OCSP responses.)

CyberShadow commented 3 years ago

Added three more commits. With these, OCSP seems to now work for, at least, Let's Encrypt certificates.