On 23/12/15 17:21, Viktor Dukhovni wrote: > On Wed, Dec 23, 2015 at 04:48:20PM +0000, Matt Caswell via RT wrote: > >> The problem is that the server has been configured to allow client auth. The >> CertificateRequest message coming from the server seems very long (nearly >> 20k). >> This is primarily made up of a long list of acceptable CA names. > > Probably the entire CA bundle was loaded into memory as a CAfile, > rather than as a CApath, and now the server is spewing out a complete > list of the DNs of its trusted CAs on every connection. > > I am very tempted to say that this misconfiguration *should fail, > it is far better to send an *empty* list of trusted CAs than send > the Vladivostok phone directory.
I strongly disagree. As a supplier of a library for client side use (in the scenario we are talking about), it is *not* our responsibility to police server side configuration. I strongly suspect that no browser (taking a browser use case as an example) would fail when presented with such an over long CertificateRequest message so neither should we. From a client side perspective it does little harm to the client to accept a long message, but it does harm the client to reject (it prevents the client from using that server). We have in previous versions accepted this, so IMO we should as a minimum support what we used to support. > >> The master code has the max size limit for this message as being >> SSL3_RT_MAX_PLAIN_LENGTH (16384 bytes). This is the maximum that can be put >> into a single TLS record. Previous versions had it set to s->max_cert_list >> which is a configurable value that by default is 100k. >> >> The attached patch should resolve this issue (it just reverts the size limit >> to >> what it was before). > > Perhaps OpenSSL should suppress the default use of the contents of > CAfile as a list of DNs to send in certificate requests when that > list is longer than say 16 elements. Applications can explicitly > specify the list of CAs for the client certificate request as > needed. > > Sending the whole bundle to every client is not a good idea. The > empty list works much better in every respect. We could set the > limit to 0 instead of the arbitrary 16, thereby requiring the list > of client auth CAs to always be set explicitly. With any luck as > a result a lot fewer applications will end up sending the phone > directory. > This might be worthwhile as a *server side* solution. It should not prevent us from accepting long CertifcateRequests on the client. Matt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev