curl and certificate verification in jessie

Tollef Fog Heen tfheen at err.no
Thu Dec 4 19:59:51 UTC 2014


]] Daniel Kahn Gillmor 

> On 12/04/2014 10:41 AM, Ian Jackson wrote:
> 
> > I'm not an expert on TLS but I was under the impression that this
> > behaviour - requiring that TLS authentication be done by a nontrivial
> > certificate chain - was specified by the standards (presumably X.509
> > rather than TLS).  I could be wrong.
> 
> FWIW, i'm not convinced that there are any standards that say that a TLS
> endpoint MUST validate its peer by means of a hierarchical CA.
> 
> even if there were, i suspect most implementations would provide a
> mechanism to ignore that MUST.
> 
> The issue here is that GnuTLS upstream apparently wants to distinguish
> between the "here's a CA" case and the "here's a certificate that's
> valid for this host" case. [0]
> 
> The main argument seems to be that if you decide you are willing to rely
> on a CA, that means you're accepting anything they give you.
> 
> But if you say "i believe this cert is ok for a peer" with no other
> information, you're actually accepting the cert for *any* of the
> subjectAltNames it has.
> 
> This makes it far too easy for me to visit https://some.random.example
> and "accept" their cert, but not notice that the cert also has
> alioth.debian.org as a subjectAltName.  now the administrator of
> some.random.example can impersonate alioth to me.

This reasoning makes sense, for applications which do store certs.

> So, the idea is that when you "accept" an EE cert, you need to do it
> with an explicit associate to a specific peer's name, not just the cert
> itself.  newer versions of GnuTLS provide this facility, but it's not
> the traditional (and potentially dangerous) "here's a package of certs
> i'm OK with" interface that it was before.  And of course that interface
> isn't used by curl yet.
> 
> Unfortunately, this is quite a subtle API change, and it's not clear how
> to do it safely or sanely.

For curl, it sounds like a simple curl_set_option(CURL_SSL_EE_CERT,…)
call or similar would make sense and then expose that to the command
line too.  If I do curl --tls-ee-certs=somefile.crt https://www…, I
probably don't care if somefile.crt has a subjectAltName for alioth or
google.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



More information about the Pkg-gnutls-maint mailing list