curl and certificate verification in jessie

Daniel Kahn Gillmor dkg at
Mon Dec 1 19:36:15 UTC 2014

On 12/01/2014 01:50 PM, Alessandro Ghedini wrote:
> On lun, dic 01, 2014 at 11:18:19 +0100, Tollef Fog Heen wrote:
>>>> Is this intentional, or is that a bug in either gnutls, curl, or the software
>>>> using these libraries?
>>> AFAICT this is due to the gnutls26 -> gnutls28 switch. Using libgnutls-dev to
>>> build curl instead of libgnutls28-dev makes it possible to point CURLOPT_CAINFO
>>> to a single leaf certificate and have the verification succeed.
>>> FWIW the current behaviour is the same with openssl. I don't know if there's a
>>> reason for it though.
>> Can we get it reverted/fixed?
> If you are asking if curl is gonna go back to gnutls26, I don't think that's
> gonna happen. AFAICT it's not maintained upstream anymore and gnutls28 provides
> stuff like ECC support that's IMO more important.

I agree with Alessandro here: we definitely don't want to revert to
GnuTLS the 2.x series (gnutls26).  gnutls 3.x (gnutls28) is the only
viable option for jessie.

> What does "security-related regression" mean? (if anything this makes security
> checks tighter).

I'm not convinced by this argument.  Saying "i'll only accept the
following end-entity cert" is a tighter check than "i'll only accept a
cert for the end-entity certified by this CA".

However, the semantics of the CURLOPT_CAINFO call are squishy on whether
it can be used to mean the former.  And CURLOPT_ISSUERCERT appears to
have the same constraint.

Modern versions of GnuTLS have a TOFU facility [0] (similar to
known_hosts of Openssh) which could be used for the former approach, but
i don't see any way to reach that mechanism from curl.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Pkg-gnutls-maint mailing list