Big CA certificate bundle causes problems with GnuTLS 3.0.11
Sam Varshavchik
mrsam at courier-mta.com
Wed May 30 01:04:48 CEST 2012
Nikos Mavrogiannopoulos writes:
> In the TLS protocol the server advertises its CA certificates so a
> client would know which certificate to present. If a server trusts all
> the certificates in the system, the server would advertise all of them
> (their DNs actually).
IIRC, this occurs only when client certificates are enabled. Yes, I would
think that in that case only the certificates that the server trusts, should
be loaded.
I would think that in most situations an organization would have only their
own CA trusted, and loaded into a TLS server. I suppose I can imagine a
situation where an org would, in some context, decide that accepting a
client cert signed by any public CA to be acceptable, and then use it for
some particular purpose. But I don't think this would be the case for most
practical situations. And, in those cases, loading the public CA certs would
be a security hole. Depending on the purpose the client cert is being used
for, and how, it wouldn't take much imagination to get some public CA to
sign something that looks good enough to 0wn JOO.
So, I would take a hard look at why someone really wants to load a public CA
bundle, in the first place, to validate client certs.
I suppose someone might want, for some odd reason, to blow a wad of cash on
having some public CA sign some certs, for their clients, even though it's
trivial to set up your own cert, and do it yourself for free. But, still, in
that case, at the very least you should only load /that/ CA, and not the
whole bundle.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20120529/fabdd136/attachment.pgp>
More information about the Gnutls-help
mailing list