Big CA certificate bundle causes problems with GnuTLS 3.0.11

[Janne Snabb]

On 2012-05-30 03:37, Michal Suchanek wrote:
> Now what I do not get is how a pile of CA certificates is fragmenting
> the packets.
> 
> Sounds like a security hole. CA cert piles should be local to either
> side, only one CA cert relevant for the session. Technically there can
> be more than one cert in the trust chain but not pile of them.

If the *server* chooses to trust a pile of CA's in the same way as web
browsers (clients) typically do, this will happen, see:

https://tools.ietf.org/html/rfc5246#section-7.4.4

It also says:

"If the certificate_authorities list is empty, then the client MAY send
any certificate of the appropriate ClientCertificateType, unless there
is some external arrangement to the contrary."

...which suggests that in cases like this it might be a good idea or at
least acceptable *not* to put anything in the certificate_authorities
list when the server sends the Certificate Request. It is unclear how
various client side implementations implement the "MAY" part of the
above RFC quote. Do they send a client certificate if the CA list is
empty? Which one will they send if they have several?

It feels like there should be a way in the GnuTLS API to define whether
the list of trusted CAs is to be advertised in Certificate Request or
not. (Maybe there is a way but I am missing it?)

I encountered this issue with Exim SMTP server with the default
configuration that is packaged in Debian and Ubuntu. If the
administrator enables TLS but does not specify which CAs to trust, in
Ubuntu 12.04 it will trust 152 of them (basically the same ones as
trusted by Mozilla NSS plus a couple of more) and advertise all of them
in Certificate Request. I am sure there are many mail servers out there
which are sending more than 16 kb of data in every TLS handshake
basically just to say "we trust everyone".

--
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/