Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Safari and client certificates
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Safari and client certificates



On Apr 16 2009 12:58 PM, Bruno Harbulot wrote:
> Hello,
>
> I'm currently using OSX 10.5.6. I'm not sure if the behaviour of Safari
> regarding the choice of client certificate has changed since 10.5.3
> [1][2], but it doesn't look like it has.
>
> I've just looked in more details at what was happening during the handshake.
>
> 1. Using optional authentication on the server (for example, using
> "optional" in Apache Httpd or setWantClientAuth in Java).
>
> The server sends the CertificateRequest message after its Certificate.
> The client (Safari) replies with an empty Certificate message.

Unless you create an identity preference item for this server in your keychain first, in which case the preferred client certificate for that server is sent.

>
> 2. Using mandatory authentication on the server (for example, using
> "required" in Apache Httpd or setNeedClientAuth in Java).
>
> The server sends the CertificateRequest message after its Certificate.
> The client (Safari) replies with an empty Certificate message.
> This handshake fails.
> The client starts a new connection (and thus a new handshake).
> The server sends the CertificateRequest message after its Certificate.
> Safari offers a choice of certificates; this creates an "identity" in
> the keychain.
> The client (Safari) replies with a Certificate message containing the
> appropriate certificate chain.
>
>
> I'm wondering what the reason for designing it like this, that is, for
> not asking for a client certificate in the first place, whenever a
> CertificateRequest message is received.

The reason for the current design (requiring an identity preference to be set in the keychain in order to specify whether a client certificate is sent) has to do with overcoming current API limitations. Most people have the idea that "Safari" is the client, because other browsers are monolithic. Safari is actually the top layer of a cake that looks something like this:

    +---------------+
    |     Safari    |
+-----------------------+
|       Foundation      |
+-----------------------+
|       CFNetwork       |
+-----------------------+
|    Secure Transport   |
+-----------------------+
           ||
        (Server)

Each layer only sees and interacts with the API layer directly below it. When Safari issues a request to connect to (Server) via https, it passes down through 3 distinct frameworks to arrive at the SSL handshake (in Secure Transport, part of the Security framework). During the handshake, a server can request a client cert, but there has been no way for that message to return back up to Safari, short of a connection failure. The identity preference mechanism is an out-of-band method for Secure Transport to get a message from Safari about the user's preferred client certificate.

>
> Is there any plan to fix this in the next release? A fix for the iPhone
> and iPod Touch would be welcome too.

Yes, there is a plan to fix this, so that the request for a client cert can go all the way back to Safari at the top layer without the need to set a preferred identity for that site. Whether it will happen in "the next release" is not for me to say.

> I'd say I almost preferred the pre-10.5.3 behaviour; if I remember well,
> at least one certificate was sent.

And since it was almost always the *wrong* certificate that was sent, it did not really help in most cases.

-k

>
>
> Best wishes,
>
> Bruno.
>
>
> [1] http://lists.apple.com/archives/apple-cdsa/2008/Jun/msg00004.html
> [2] http://support.apple.com/kb/HT1679
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Apple-cdsa mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Safari and client certificates (From: Bruno Harbulot <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.