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: "Mueller, David S CIV SSC San Diego, 2872" <email@hidden>
- Date: Wed, 10 Sep 2008 08:33:51 -0700
- Thread-topic: [Fed-Talk] Certificate selection and secure web sites.
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