On 02/02/2011 04:48 AM, Gervase Markham wrote: > On 01/02/11 23:03, Robert Relyea wrote: >> 1) use request/not require certificate. If a certificate is supplied, >> that will show up in the initial handshake. The certificate will tell >> the server which account and you can bypass login altogether. If no >> certificate is supplied, you can bounce to user to a normal login >> screen. The server would have to know if some accounts must have >> certificates or not. > > It could certainly know that. > >> Downside: This doesn't work well with 'remember these settings' options >> -- particularly IE's version-- there is no way to tell the browser to >> 'unremember' the setting. I think IE will prompt for the certificate >> even if there isn't one you can use. Netscape/Mozilla family browsers >> will usually not supply the certificate if there isn't one available, >> nor will it prompt the user, but if the user has a certificate that >> doesn't (even if it doesn't match the ca list from the server), it may >> be that Firefox prompts for it (I don't know what the current >> semantic is). > > Doesn't sound like usability paradise... :-|
This is part of the issue Anders has complained about with smart cards. Both Mozilla and Microsoft make UI choices that are less then optimal for smart cards and client auth. For the most part, FF can provide a reasonable interface (again, I don't know what changes have gone into FF 4.0 in this respect). IE is always going to be a little rough if you want to mix not-client auth with client auth. It will work, but won't be optimal. My question is for bugzilla access is this a problem? > >> 1) use normal ssl on your opening page. > > We do that... > >> When the user logs in, if the >> account requires a certificate and SSL-Renegotiate is initiated. This >> can be accomplished as Marsh indicates by bouncing to a different URL, >> but it's possible that you can create a server that handles this >> directly. This may be what Marsh was thinking since he was instrumental >> in discovering the original bug in SSL-Renegotiate and also in pushing >> to get is resolved. >> >> Downside: The user needs to start the login process before you know that >> you need a new cert. This only works safely with newer browsers (which >> has the renegotiate extension). Obviously you server needs to properly >> handle the extension (including refusing to renegotiate with clients >> that don't have the extension). > > So they would log in using name and password, and on detecting > success, the server would notice the account was marked "extra auth, > please" and renegotiate with a client cert request. > > Sounds technically plausible - we can possibly require all the > security groupt to use Firefox 4 - but seems like it would require > some serious Apache mod_ssl hacking. Probably not serious hacking, but some. Apache already has the ability to renegotiate (works with both mod_ssl and mod_nss), so you may be able to do it with cgi. I know the request/not require client auth case you can do with cgi (I've done it myself for demos). bob
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
