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 09:22:21 -0700
- Thread-topic: [Fed-Talk] Certificate selection and secure web sites.
Using Firefox with Coolkey on Mac OS X also works since it doesn't use
the Keychain, and seems to me like a more cost effective solution than
paying for VMWare Fusion and Windows licenses. ;)
One tip for using Firefox with CAC: If you can, insert the card after
you launch Firefox; for some reason, Firefox seems to take much longer
to start up if a CAC is in the card reader.
- David
-----Original Message-----
From: Boyd Fletcher [mailto:email@hidden]
Sent: Wednesday, September 10, 2008 9:04 AM
To: Mueller, David S CIV SSC San Diego, 2872; Apple Fed Talk
Subject: Re: [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:
> om.mil
>
> 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