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 [email protected] - http://epipe.com/ _______________________________________________ Help-gnutls mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-gnutls
