[Development] OpenSSL certificate validation

[Florian Weimer]

On 08/13/2013 07:32 PM, Thiago Macieira wrote:
> On terça-feira, 13 de agosto de 2013 19:11:16, Florian Weimer wrote:
>>       // Initialize peer verification.
>>       if (configuration.peerVerifyMode == QSslSocket::VerifyNone) {
>>           q_SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, 0);
>>       } else {
>>           q_SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, q_X509Callback);
>>       }
>>
>> The same callback is used there.  But if it's registered in this manner,
>> it's not called by the OpenSSL while building the client certificate chain.
>
> Makes sense.
>
> I'm located in the US, so I'm not allowed to modify the SSL code. If you're in
> the US, you're not either. And now here's an interesting question: are people
> working for American companies allowed to modify the SSL code?

That's a project policy question, not a legal question, right? :-)

>>> If there's a better API for it than a global callback that doesn't get a
>>> context token passed, we're all ears
>>
>> You could use a multi-map with the X509_STORE_CTX * as the key instead
>> of a list.  The pointer should be available from the SSL_CTX via
>> SSL_CTX_get_cert_store, and it should be specific to that SSL_CTX.
>
> Sorry, I'm not sure I understood that. Sounds like we still have a global.

Yes, the map would still be global.  But you would only have to lock it 
while adding and extracting individual values.  The lock around the 
entire SSL handshake could go away, and at leat the current hazards are 
history.

> I'd like to obtain the list of error conditions and for each condition the
> associated certificate (or depth) without a global variable.

You could associate the error list with the SSL * using the ex_data 
mechanism.  The SSL * itself is available from 
X509_STORE_CTX_get_ex_data(ctx, SSL_get_ex_data_X509_STORE_CTX_idx()), 
if I'm reading the OpenSSL source code correctly.  (I think this is also 
the pointer you should use for the map index, not the X509_STORE_CTX * 
because that's an internal object which is created during certificate 
verification).

-- 
Florian Weimer / Red Hat Product Security Team