On 2009.11.11 at 13:00:05 +0100, David Sommerseth wrote: > > Good point! I was not aware of the Apache/mod_ssl way of doing it. My > only concern about that is if it would be possible to exhaust the memory > pool for environment variables? Imagine a a buffer overflow bug if an > attacker sends a specially crafted certificate request with 1000 > certificates in a chain.
I'm not sure that all intermediate CA Certificates have to be exported such way. I don't remember if Apache does so, because I never tried to test Apache with chain longer than 1 and without intermediate CA certs in the OpenSSL cert-store. For most purposes two things are sufficient 1. Check validity of client certificate data using chain (i.e. did intermediate CAs have right to issue certificate with such extension). It is better done inside OpenSSL. I've written patch which enables OpenSSL builtin certificate policy checking in OpenVPN. 2. Get an information from client certificate, not from intermediate CA certificate in the chain. > The reason for this concern is that OpenVPN provides now all certificate > info available at once in many of the the different hooks, all with _0, > _1, _2, etc as a suffix at the end of the environment variable name. > With roughly 2KB per certificate, on a cruel attack with 1000 chained > certificates, that could mean 2MB would be needed for the environment > table and you would have 1000 environment variables to go through. [skip] > One way how to control this situation would be to also implement a > "--max-chained-certs" argument, which would default at something > reasonable, f.ex 5. > Really, OpenSSL allows to set maximal verification depth. Apache mod_ssl has a configuration directive which sets maximum allowed chain length using SSL_CTX_set_verify_depth function. OpenVPN doesn't provide such a directive now. So, may be exporting certificate should be accompanied with providing such a directive with reasonable default. I've never seen chains longer than 3, so 5 should be sufficient.
