On 30/04/2010 16:06, Bruno Harbulot wrote: > Hi Nicolas, > > On 28/04/2010 12:55, Nicolas Rinaudo wrote: >> This might be an important bit of information. After running a few more >> tests, I realised that Safari would: >> - fail ignoring certificates if the server is running on OS X. >> - succeed in ignoring certificates if the server is running on Debian Lenny >> (5.0) >> >> This might be an OS X only issue after all. > > I've looked a bit more into this issue, and it doesn't seem OSX-specific > (on the server side) unfortunately. It's not even specific to > self-signed certificates (I've tried with a trusted cert), the Simple > connector or Restlet. > I've managed to reproduce it with a basic Jetty server [1] running with > the Sun JVM on a Linux box. > > It has similar symptoms to the buffer issue we had a few weeks ago [2], > but I don't know whether it's a Java or a Safari problem at this stage. > > It appears with Simple, because Simple always requests (wants) a client > certificate. It also happens with Jetty if it's configured to do so. > > To (try to) keep it short, when a TLS server requests a client > certificate during the handshake, and extra TLS message is sent > (CertificateRequest), which contains a list of the names of the CAs from > which the server would be willing to accept client certificates. > In Java, this list is automatically populated by the default SSLContext > with the list of names corresponding to the certificates held in the > truststore. The more certificates in the truststore, the longer the > list, and thus the bigger the packet. > > On the current OSX 10.6, the default truststore [3] seems to have about > 160 certificates, whereas on an Ubuntu 9.10 (Sun JVM) the default trust > store contains about 75. > When I use the Mac's truststore on the Linux box, this fails too. When I > use a smaller truststore on the Mac, it works there. > > I've tried to debug the SSL handshake on the Java side and it looks like > it works fine, internally; however, when looking at the packets with > WireShark, not everything sent by the server according to the Java > debugging logs seems to be effectively sent. > I suspect this is a buffer size problem similar to [2], although in this > case, it happens with other servers, using NIO or BIO. > > > A workaround would be to specify a smaller truststore or to turn off the > optional client-certificate authentication.
It looks like it's a more general problem, with some buffer stack settings in various TLS stacks. I've just tried to set up Apache Httpd 2.2 with a large number of certificates too. Above about 150 DNs, it doesn't even accept connections from either Firefox or the OpenSSL test client (I suppose this number may vary slightly depending the length of the distinguished names in the certificates). This makes the server send something around 22000 bytes during the handshake. When Apache Httpd is configured with 118 CA certificates (again the exact number may vary), Firefox and the OpenSSL client can connect to it, but not Safari. (The server sends about 18000 bytes.) Best wishes, Bruno. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2599850
