Hi all,

I was talking to a friend using OSX about --pinnedpubkey support, I
mentioned that it wasn't supported in the darwinssl/SecureTransport back
end, but the option was there and he tried it and successfully connected
with a bad key. This got me thinking about failure modes:

$ echo bob > bad.key
$ curl --pinnedpubkey bad.key https://google.com/
curl: (90) SSL: public key does not match pinned public key!

Is how it behaves when --pinnedpubkey support is there, from
https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3
today:

> Added in 7.39.0 for OpenSSL, GnuTLS and GSKit. Added in 7.43.0 for
> NSS and wolfSSL/CyaSSL. Added for mbedtls in 7.47.0, sha256 support
> added in 7.44.0 for OpenSSL, GnuTLS, NSS and wolfSSL/CyaSSL. Other
> SSL backends not supported.

So wherever there is no support, it 'fails open', I guess, in that it
just goes ahead and connects whether the public key matches or not.

There is one backend, GSKit, that supports der/pem files but not sha256
hashes (no curlssl_sha256sum defined), that 'fails closed' because it
thinks the hashes are a file, can't find them (or they don't match), and
it fails to connect.

As an aside, I notice it doesn't really say if mbedtls supports sha256
hashes, but I see it does in the code.

So:
1. Should unsupported backends 'fail open', if not is this a security issue?
2. Should --pinnedpubkey just not show up and be an unknown option if
compiled with an unsupported backend?
3. Should it just be left as-is today? (know your curl?)

Thanks for feedback,
Travis Burtrum
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-04-21