[foaf-protocols] Safari 4.01 (5530.18) ssl bugs

[Bruno Harbulot]

Hi Joe,

Joe Presbrey wrote:
> I have the same experience with foaf.me login but just tested
> presbrey.xvm.mit.edu with success.  See if your Safari will allow you
> access to https://presbrey.xvm.mit.edu/
> 
> If it does, you may want to consider the following patch:
> http://dig.csail.mit.edu/2009/mod_ssl-require_no_ca/mod_ssl-2.2.11-require_no_ca.patch
> 
> which allows you to specify:
> SSLVerifyClient require_no_ca
> 
> This is how I have presbrey.xvm.mit.edu setup.

I think this patch is a good idea (and, as Toby suggested, it's worth 
trying to submit it to the Apache Httpd project).
However, this implements the 'require' behaviour (as the name says of 
course), which means that the client needs to present a certificate, 
otherwise the connection will be closed more or less abruptly, without 
any HTTP exchange taking place (thus no error message).
This is equivalent to what we use in Java with 'need' authentication and 
a trust manager accepting all client certificates.

Safari and the 'require' behaviour has never been a problem (as far as I 
remember), but it's the optional behaviour that Henry was trying to 
obtain, so as to be able to provide users who wouldn't have a 
client-certificate with a suitable error page (and the REST way to 
discover what went wrong, guidance on how to obtain a certificate, 
etc.). This is actually a very important point, at least for the user 
experience.
Henry's patch for Apache Tomcat forces the server to close the 
connection, which makes Safari make a second attempt with the client 
certificate (Safari's first attempt being always without certificate 
unless an 'identity' has been defined by hand or by a previous visit to 
the same website, with the 'require' behaviour).

More on this topic (including a good explanation from an Apple engineer) 
in this thread:
http://lists.apple.com/archives/apple-cdsa/2009/Apr/msg00038.html

It's not just a problem with Safari, it's a problem with the OSX SSL 
network stack (CFNetwork).
As far as I remember, the way it worked before 10.5.3 was better if you 
only had one certificate in your keychain, but it was unable to let you 
choose properly if you had more than one. The way to choose has improved 
in 10.5.3, at the expense of optional authentication.
(I haven't run any detailed tests with 10.5.7 and Safari 4, but it 
appears the problem hasn't been solved.)


Best wishes,

Bruno.