Re: [Fed-Talk] Certificate selection and secure web sites.
Re: [Fed-Talk] Certificate selection and secure web sites.
- Subject: Re: [Fed-Talk] Certificate selection and secure web sites.
- From: Boyd Fletcher <email@hidden>
- Date: Wed, 10 Sep 2008 12:04:26 -0400
- Thread-topic: [Fed-Talk] Certificate selection and secure web sites.
I agree 100% that the current approach of manually setting the ID preference
in Keychain Access is a disaster and is the most user unfriendly solution I
have ever seen. I have spent a ton of time lately trying to show regular
users how to set the ID preferences for web sites. The users are getting
frustrated and fed up with this approach - its just plain bad engineering.
Apple needs to fix so the user can trivially select within Safari the
appropriate certificate to ALWAYS be sent to a particular web site if HTTPS
is used (and an easy change that selection if wrong).
As it stands right now most of our Apple users running leopard are using
VMWare and Windows to access DOD CAC enabled web sites because the current
approach in Leopard is brain dead.
boyd
On 9/10/08 11:33 AM, "Mueller, David S CIV SSC San Diego, 2872"
<email@hidden> wrote:
> I agree Microsoft has a better approach than what Apple does with 10.5.3
> and 10.5.4. Although, I think what Mozilla/Firefox does (on all
> platforms) is best, as it has the option to allow the browser to
> automatically select a certificate, and at least with the sites I
> visited, it worked very well so I wasn't faced with constant certificate
> selection popups. This is similar to how Safari with 10.5.2 and prior
> behaved -- no certificate selection popups, everything seemed to just
> work. But I think your suggested approach is even better, to popup once
> and then store the preference for future use on that site.
>
> What seemed to change is that starting with 10.5.3, Safari will only
> send a cert to a server that is configured to "require" one rather than
> one that is "optionally" configured to accept one. A couple of weeks
> ago I took a look at the TLS RFC (TLS 1.0 RFC 2246 and TLS 1.1 RFC
> 4346)as well as some Wireshark packet captures of a HTTPS exchange and I
> didn't see anything that looked like an "optional" client certificate
> request -- either the server sends a request and the client responds
> with one (or an empty Client Certificate message if it doesn't have a
> suitable cert) or the server doesn't send a request at all.
>
> Looking at the RFCs, I'm guessing what Safari is doing is waiting for
> the fatal handshake alert sent by the server when it doesn't respond
> with a client certificate (which is indicative of a server that is
> configured to require one), then trying again with a cert. Unless an
> identity preference is set in which case a cert will be sent the first
> time regardless. This sort of behavior is not very user friendly and
> goes against the whole "It Just Works" idea that Apple products are
> known for.
>
> I believe it was implied earlier that the sites that require a client
> cert to login but aren't configured to require one are misconfigured.
> However, I don't believe this is the case; the "optional" configuration
> as I've seen it used is good for at least two things:
>
> 1. Provide a transition mechanism until everyone is able to use CAC
> login. Safari's user-unfriendly operation means most Mac users will
> just continue to login using a username/password until the cutoff, and
> if there are any CAC login problems, they won't be uncovered until that
> is the only login mechanism.
>
> 2. Provide a more informative and useful error message.
> https://infosec.navy.mil is a great example. If you try to go there
> without a CAC, instead of a generic SSL error message, you get a page
> with phone numbers and an email address for a helpdesk, and links for
> Windows users to download the DoD server certificates and ActivCard
> smart card software (because, unlike Mac OS X and Red Hat/Fedora,
> Windows doesn't come with all the software you need to use a CAC).
>
> - David
>
> -----Original Message-----
> From: Walter Adams
> Sent: Wednesday, September 10, 2008 7:41 AM
> To: email@hidden
> Subject: [Fed-Talk] Certificate selection and secure web sites.
>
>
> Certificate selection and secure web sites.
>
> As I understand it the current Apple model is for users to go to the
> Keychain Access utility select a certificate (for those of us with CACs
> - one of those) and then you add a "new identity preference".
>
> You won't hear this often from me - but Microsoft got this right - they
> have the user navigate (with the browser) to a secure web site and then
> they present the user with a list of certificates for the users to
> select the certificate.
>
> Note: I don't know if the is a Windows OS characteristic or an
> Application
> (IE) characteristic)
>
> What they did not do is make that selection persistent - like Apple has.
>
> In my humble opinion the solution is to make the certificate selection
> context sensitive (al la Microsoft) and persistent (a la Apple). That
> would make this process a lot more straight forward. The only thing
> that is missing from both approaches is the ability to edit persistent
> associations
> - so that if you make a mistake or if something changes - a new CAC,
> etc... You can move on.
>
> Walter
> email@hidden
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Fed-talk mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden