cURL / Mailing Lists / curl-library / Single Mail

curl-library

Callback for cert verification

From: Vitaliy Kulikov <vitaliy_at_google.com>
Date: Tue, 6 Jan 2009 13:56:14 -0500

Hello,

I am an engineer at Google, and this is my first email to this mailing
list. I implemented item 7.6 of your "TODO" wish list ("Provide
callback for cert verification"), and I would like to contribute my
changes back to the project. Could someone point me to a list of
instructions on how I can get my changes reviewed and submitted?

Here is a brief description of my changes (please let me know if you
have any questions or notice that any of my assumptions about the code
are incorrect).

While the CURL stack comes with general HTTPS support, it provides
limited functionality when it comes to dealing with SSL certificate
errors. For example, the stack does not keep track of multiple
certificate errors (only the last error is logged), it does not
distinguish between error values that come from different SSL
implementations, and it does not provide callbacks for passing
certificate [error] data up the software stack to let the client
decide whether certificate errors should be ignored or not. Depending
on parameters set, CURL either simply ignores all errors or fails to
connect if an SSL certificate error is detected.

I modified the stack in a number of ways. First, I created an
implementation-independent list of common SSL certificate error codes
with the idea that certificate errors from different SSL
implementations should map to implementation-independent error codes
before being passed and stored up in the CURL stack. This way, the
upper levels of the stack should not care about what SSL
implementation is used.

Second, I added code to save certificate [error] data as part of the
'ssl_connect_data' data structure every time a secure connection needs
to be established and a new set of certificates is received from the
server. I save every certificate in binary along with the encoding
method (DER is the only encoding supported at the moment) and the
certificate error data. If there are multiple certificates in the
chain, I save them all (I have a hard-coded limit of 16 certificates
per chain at the moment).

Third, I provide a way for the client code to supply the stack with a
callback function to be called every time a new chain of certificates
is received and validated. If a valid callback function is provided,
it must return CURLE_OK if the connection should be established or a
CURLE error code (probably an SSL certificate error code) if the
connection should be aborted. Because it is up to the client code what
SSL certificate errors must be ignored and what not, the network stack
is blocked while waiting for the callback to return.

Thanks,
Vitaliy
Received on 2009-01-06