curl and certificate verification in jessie
Daniel Kahn Gillmor
dkg at fifthhorseman.net
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  (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...
Size: 949 bytes
Desc: OpenPGP digital signature
More information about the Pkg-gnutls-maint