#78 RFE: add API for certificate pinning

open
2014-04-03
2014-03-24
No

When using security sensitive applications (e.g. for accessing the Mozilla Persona verifier), it is often useful to do SSL certificate pinning instead of trusting into the x509 CA system.

It would be nice when curl has an API supporting certificate pinning. This API should be reliable, easy to use and should be working across all the SSL backends ;) Unfortunately, this is not the case with the current library. E.g. CURLOPT_CERTINFO + CURLOPT_SSL_CTX_FUNCTION is supported with OpenSSL only, passing the certificate instead of the chain in CURLOPT_CAINFO works with OpenSSL only too.

For certificate pinning, an easy access to the certificate fingerprint would be ideal. E.g. a CURLOPT_CERTFP option could be added which returns the fingerprint in CURLINFO_CERTFP. Type of hash could be either selected by the value of CURLOPT_CERTFP or by providing multiple CURLINFO_CERTFP_<hash> results. atm, I would prefer the first method.

Alternatively, the whole certificate could be returned by CURLOPT_CERTIFICATE and CURLINFO_CERTIFICATE_DER/PEM options.

Discussion

  • Daniel Stenberg

    Daniel Stenberg - 2014-03-24
    • labels: --> SSL/TLS, certificate
    • assigned_to: Daniel Stenberg
     
  • Daniel Stenberg

    Daniel Stenberg - 2014-03-24

    Thanks, and yes I agree that such an API would be great and is indeed missing.

    Any chance you feel like working on making it happen? (Since this is a feature-request rather than a bug, I'll move it to the feature-request tracker later on.)

     
  • Enrico Scholz

    Enrico Scholz - 2014-03-24

    I played a little bit and implemented a ssl verification callback at

    https://github.com/ensc/curl/commits/ssl-verify

    (the GETINFO stuff from my initial comment happens too late; the connection might have established already).

    For now, it is implemented for NSS only; I can do OpenSSL and gnutls too when there is an agreement that this is the right way to go. But the other crypto backends must be implemented by somebody else.

     
  • Daniel Stenberg

    Daniel Stenberg - 2014-03-25

    Thanks for starting this!

    I'd like you to take this discussion to the curl-library list. You'll see that you'll reach FAR more people there and it is a better place to discuss new features and ways to do things.

    In general, we have so many SSL backends we don't expect new features to be done for all of them at once. We should just make sure that the feature is designed in a way so that we believe it can be implemented by the other backends and then we do as many of them as possible. There are fans of a whole bunch of them on the list so there's a good chance we can work together to have something for the 3-5 most commonly used ones already from the start.

     
  • Daniel Stenberg

    Daniel Stenberg - 2014-04-03

    Ticket moved from /p/curl/bugs/1348/

    Can't be converted:

    • _priority: 5
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks