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. 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. I'm currently unsure what the right thing to do is about this situation. --dkg [0] http://lists.gnupg.org/pipermail/gnutls-devel/2014-December/007274.html
signature.asc
Description: OpenPGP digital signature
