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

Joe Presbrey presbrey at gmail.com
Wed Jun 24 01:44:37 CEST 2009


The only documentation I included with the patch is within the first
10 lines of the patch file and possibly a posting to the diggers
mailing list with the same information.

Yes Bruno, I understand the problem with broken clients not making
certificates available when optional is set very well (Apple is not
the only).  That is why I wrote this patch.  This patch is for the
admin that wants to get as many clients working with FOAF+SSL as
possible without bothering vendors or awaiting their fixes.  Not only
do you need to get Apple to fix, but all users to upgrade :'(

As for user-friendliness, sites using this patch might welcome users
on an http page that scripts or frames the https test page.

I have not yet submitted to Apache.  I would appreciate any testing on
your end.  AFAIK, only I and one other (Jim Hollenbach) have tested
it.

--
Joe Presbrey

On Tue, Jun 23, 2009 at 6:46 PM, Bruno
Harbulot<Bruno.Harbulot at manchester.ac.uk> wrote:
> 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.
>


More information about the foaf-protocols mailing list