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. --dkg [0] http://gnutls.org/manual/gnutls.html#Trust-on-first-use
Attachment:
signature.asc
Description: OpenPGP digital signature