[Development] OpenSSL certificate validation

[Jake Petroules]

On Aug 14, 2013, at 3:32 AM, Florian Weimer <fweimer at redhat.com> wrote:

> 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? :-)

Project policy yes, but the underlying reason is due to the wonderfully well thought-out
and useful US crypto export laws...
https://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States


>>>> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petroules at petroules.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130814/58fe3691/attachment.html>