Re: Mozilla's behavior dealing with client certificate selection
Julien Pierre wrote: Perhaps we should have something like this too. Do we have something in NSS to clear the cache for all SSL client sessions ? I don't seem to recall that we do. I seem to remember that the function has been implemented, but it has no UI. checks No, I was thinking of HTTP Basic Auth. See the last comment in http://bugzilla.mozilla.org/show_bug.cgi?id=55181 Gerv ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Mozilla's behavior dealing with client certificate selection
Julien Pierre wrote: Yeah, the latest version of IE 6.0 has a new button in the Certificates portion of the Contents tab in the Internet Options control panel. The new button says Clear SSL State. Their context-dependent help says it wipes out the SSL cache. Presumably this is so that you can choose a different identity. Perhaps we should have something like this too. Do we have something in NSS to clear the cache for all SSL client sessions ? I don't seem to recall that we do. Yes. It's been there in ssl.h since Netscape Nav 3.0. Still there. NN 3.x and NC 4.x used to call it every time you changed SSL prefs, so that you don't have to restart the browser for them to take effect. PSM doesn't do that AFAIK. :( I suggested it as it seemed the most logical thing to do if you just wanted to switch identity, as you wouldn't need to keep the existing session around for the old identity, and it would force NSS to make a full handshake for the next connetion. mozilla already has the concept of separate profiles, and switching between them. Isn't that the right answer? Maybe each browser window could display in its status bar the nickname of the user cert used to authenticate in that window? That's an idea. Clearly more than a lock icon is needed for this situation to be handled. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Mozilla's behavior dealing with client certificate selection
Julien Pierre wrote: In order to login again to the same server with a new identity, you would need to invalidate the SSL session. [...] [...] it's pretty hard to envision what that would look like, from a user interface point of view. There might be a simple solution. See http://bugzilla.mozilla.org/show_bug.cgi?id=55181#c72 about Basic authentification and the security implication of automatically reused authentification. Reuse is not necessarily the expected behaviour for users when connecting to the same site from a separate window. Everytime the user goes to the adress by : - typing it from the adresse bar - selecting from a bookmark - following a link from a different site it might be better to not automatically reuse the existing authentification be it HTTP or SSL (the last case might require usability investigation to decide, what appears to mozilla as different sites might be internal links between a secure/non-secure portion of a site). This could be instead show a prompt like : --- You are already identified with a certificat to site www.xxx.com [x] Continue using current identification [ ] Choose the certificat to present as identification _ |_| Details of selected certificate: _ | | | | |_| [ ] Don't ask me again when I'm already identified [x] for this site [ ] for any site [OK] [CANCEL] [HELP] --- ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Mozilla's behavior dealing with client certificate selection
Nelson Bolyard wrote: Once you authenticate to a server that properly implements SSL session caching, each subsequent time you visit that server (until 24 hours pass, or you restart your browser), the client will say to the server I've previously authenticated an SSL sesiion with you, and here's its ID number, and the server will accept that, and will not ask the client to authenticate again. That's standard SSL/TLS session caching. It's been in every Netscape/mozilla browser since SSL has been in those browsers. For more advanced usage of client authentification, it can happen that you own several certs representing several identities that you may wish to wish concurently to connect to the server, or to change without having to close the browser. But probably support for that only requires change at the PSM level. I wonder if PSM would in it's current state support concurent access to the same site with a different user certificate. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Mozilla's behavior dealing with client certificate selection
Jean-Marc, Jean-Marc Desperrier wrote: Nelson Bolyard wrote: Once you authenticate to a server that properly implements SSL session caching, each subsequent time you visit that server (until 24 hours pass, or you restart your browser), the client will say to the server I've previously authenticated an SSL sesiion with you, and here's its ID number, and the server will accept that, and will not ask the client to authenticate again. That's standard SSL/TLS session caching. It's been in every Netscape/mozilla browser since SSL has been in those browsers. For more advanced usage of client authentification, it can happen that you own several certs representing several identities that you may wish to wish concurently to connect to the server, or to change without having to close the browser. But probably support for that only requires change at the PSM level. I wonder if PSM would in it's current state support concurent access to the same site with a different user certificate. In order to login again to the same server with a new identity, you would need to invalidate the SSL session. Normally, the session is valid for 24 hours. If you don't want to wait that long, you can either restart the browser or the server, which will also invalidate it ;-) NSS does provide you with the ability to connect to a server without re-using an existing SSL session. Nothing in PSM tries to do this, to my knowledge. And it's pretty hard to envision what that would look like, from a user interface point of view. The best way would be if the server provided a logout page, which would invalidate the SSL session in the server, and thus force your browser to do another full handshake the next time around, and allow you to select another identity. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Mozilla's behavior dealing with client certificate selection
Julien Pierre wrote: Jean-Marc, Jean-Marc Desperrier wrote: For more advanced usage of client authentification, it can happen that you own several certs representing several identities that you may wish to wish concurently to connect to the server, or to change without having to close the browser. Yeah, the latest version of IE 6.0 has a new button in the Certificates portion of the Contents tab in the Internet Options control panel. The new button says Clear SSL State. Their context-dependent help says it wipes out the SSL cache. Presumably this is so that you can choose a different identity. But probably support for that only requires change at the PSM level. I wonder if PSM would in it's current state support concurent access to the same site with a different user certificate. NSS permits an application to have multiple concurrent SSL sessions with the same peer, each session having different authentication. It's accomplished with the SSL_SetSockPeerID function. But once you had multiple sessions, it's not clear to me how PSM would figure out which of them to use for a new SSL connection. It's also not clear to me that an ordinary user could keep it straight. In order to login again to the same server with a new identity, you would need to invalidate the SSL session. That's not required by NSS, nor by the SSL/TLS specs. Maybe you're saying that PSM currently requires this. Normally, the session is valid for 24 hours. If you don't want to wait that long, you can either restart the browser or the server, which will also invalidate it ;-) NSS does provide you with the ability to connect to a server without re-using an existing SSL session. Nothing in PSM tries to do this, to my knowledge. And it's pretty hard to envision what that would look like, from a user interface point of view. The best way would be if the server provided a logout page, which would invalidate the SSL session in the server, and thus force your browser to do another full handshake the next time around, and allow you to select another identity. Maybe each browser window could display in its status bar the nickname of the user cert used to authenticate in that window? -- Nelson B ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Mozilla's behavior dealing with client certificate selection
Nelson, Nelson B wrote: Julien Pierre wrote: Jean-Marc, Jean-Marc Desperrier wrote: For more advanced usage of client authentification, it can happen that you own several certs representing several identities that you may wish to wish concurently to connect to the server, or to change without having to close the browser. Yeah, the latest version of IE 6.0 has a new button in the Certificates portion of the Contents tab in the Internet Options control panel. The new button says Clear SSL State. Their context-dependent help says it wipes out the SSL cache. Presumably this is so that you can choose a different identity. Perhaps we should have something like this too. Do we have something in NSS to clear the cache for all SSL client sessions ? I don't seem to recall that we do. But probably support for that only requires change at the PSM level. I wonder if PSM would in it's current state support concurent access to the same site with a different user certificate. NSS permits an application to have multiple concurrent SSL sessions with the same peer, each session having different authentication. It's accomplished with the SSL_SetSockPeerID function. Yes, I'm aware of that. However, I don't really see a good way UI-wise to take advantage of this in PSM. But once you had multiple sessions, it's not clear to me how PSM would figure out which of them to use for a new SSL connection. It's also not clear to me that an ordinary user could keep it straight. In order to login again to the same server with a new identity, you would need to invalidate the SSL session. That's not required by NSS, nor by the SSL/TLS specs. Maybe you're saying that PSM currently requires this. I suggested it as it seemed the most logical thing to do if you just wanted to switch identity, as you wouldn't need to keep the existing session around for the old identity, and it would force NSS to make a full handshake for the next connetion. Normally, the session is valid for 24 hours. If you don't want to wait that long, you can either restart the browser or the server, which will also invalidate it ;-) NSS does provide you with the ability to connect to a server without re-using an existing SSL session. Nothing in PSM tries to do this, to my knowledge. And it's pretty hard to envision what that would look like, from a user interface point of view. The best way would be if the server provided a logout page, which would invalidate the SSL session in the server, and thus force your browser to do another full handshake the next time around, and allow you to select another identity. Maybe each browser window could display in its status bar the nickname of the user cert used to authenticate in that window? That's an idea. Clearly more than a lock icon is needed for this situation to be handled. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Mozilla's behavior dealing with client certificate selection
I am investigating how mozilla deals with client certificate authentication. So far, i understood there are two modes, according on how the option client certificate selection is set. When select automatically is set, mozilla chooses the newest client certificate, i.e, the one that has the most recent Not Before Date. This can be problematic, if the server does accept more than one CA, or if a CA issued more than one certificate to a user (a user certificate and an admin certificate, for example). To allow more flexibility, one can choose the option Ask every Time. Here is my question, what is the exact behavior of Mozilla, when you choose Ask Every Time? Does it mean that it will open a pop-up to ask for certificate selection for every single page i want to browse? I did some testing, but was not able to find out the logic behing mozilla's behavior. In some case, it does not ask for a certificate, in others, it does for every page. For IE, it is simple, one pop-up to ask for client certificate, then IE cache the old authentication information and automatically perform client authentication with the previous credentials without any user intervention. Could you explain mozilla's behavior when ask every time option is set? Thanks, Nicolas. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Certificate Selection
Stephen Henson wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] says... Henrik, Henrik Gemal wrote: How does Mozilla select certificates to show to a webserver when the server asks for a certificate? The web server firstsends Mozilla a list of valid CA certificates from which it will accept client cert. Although a server sending an empty list is strictly speaking illegal in SSL/TLS some implementations will tolerate it and interpret it as any CA. No idea if Mozilla does though... Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. Until recently, NSS treated a cert request with an empty set of CA names as an error. Now, in the most recent versions (3.7 and later, IIRC), it allows zero-length lists, and passes them up to application's cert selection callback function. I don't know what mozilla (the browser application) does when it receives a zero-length CA name list. This change to NSS was made in response to the Internet Draft revision to RFC 2246. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tls-rfc2246-bis-03.txt As presently drafted, TLS 1.1 will explicitly allow zero length CA name lists. -- Nelson Bolyard Netscape Communications (subsidiary of AOL) Disclaimer: I speak for myself, not for Netscape
Re: Certificate Selection
Stephen Henson wrote: My tests on Mozilla 1.2.1 show it tolerates an empty set and interprets it as any CA. Maybe thats NSS 3.6 because that's the version the Generic Crypto Services HW version shows up as. Hmm. The change that allowed empty CA name lists was rev 1.44 of ssl3con.c which first appeared in NSS 3.7. I wonder if mozilla used a snapshot of NSS that was made after the 3.6 release, but just before the 3.7 release. That would still show the number 3.6, even though it contained 3.7 features. But perhaps there's another explanation. Did you server send an empty list (zero length list)? Or did it perhaps send a list containing one zero-length name? That is, was the length of certificate_authorities zero? or was it (say) 3, and the length of the first DistinguishedName zero? I believe that NSS 3.6 allowed the latter but not the former. Zero length DistinguishedNames are not allowed by RFC 2246, but NSS 3.6 allowed them. -- Nelson Bolyard Disclaimer: I speak for myself, not for Netscape
Re: Certificate Selection
Henrik, Henrik Gemal wrote: How does Mozilla select certificates to show to a webserver when the server asks for a certificate? The web server firstsends Mozilla a list of valid CA certificates from which it will accept client cert. Mozilla then looks through the available client certs. The most common case is there is zero or one match, so the automatic choice is easy. If there is more than one, I believe Mozilla will pick the most recently issued certificate. You can however force Mozilla to prompt you by setting Edit/Preferences/Privacy Security/Certificate/Ask every time . If a spammer set up a cert login site I would automaticly show me the cert? Yes, but only if they first knew who issued your certificate, as the spammer's SSL web server would need to present the correct issuer CA certificate for this to work. Also, note that presenting your certificate to a spammer does not accomplish anything more than authenticating you as the owner of the certificate. The spammer knows who you are at that point based on the certificate, however he cannot replay the authentication, because he doesn't have the private key.
Re: Certificate Selection
In article [EMAIL PROTECTED], [EMAIL PROTECTED] says... Henrik, Henrik Gemal wrote: How does Mozilla select certificates to show to a webserver when the server asks for a certificate? The web server firstsends Mozilla a list of valid CA certificates from which it will accept client cert. Although a server sending an empty list is strictly speaking illegal in SSL/TLS some implementations will tolerate it and interpret it as any CA. No idea if Mozilla does though... Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage.
Re: Certificate Selection
Stephen Henson wrote: Although a server sending an empty list is strictly speaking illegal in SSL/TLS some implementations will tolerate it and interpret it as any CA. No idea if Mozilla does though... NSS enforces the SSL/TLS specs and will not tolerate an empty CA cert list from the server.
email encryption certificate selection keeps changing
I'm involved in a project evaluating PKI for some local applications. Thus I have several certificates and others are added and deleted regularly. I'm new to this. Lots of trial and error going on here. I have to keep going back and re-selecting my email encryption certificate. The one I want to use for everyday email keeps getting replaced by some of my more bizarre test attempts. Most of the time the only way I can even get the certificate I want to show up on the selection list is to delete all the others. Will I have to use seperate keys for each to keep Mozilla from overriding? I'd rather not do that. -- Larry smime.p7s Description: S/MIME Cryptographic Signature
Re: email encryption certificate selection keeps changing
Usually, when you import a certificate into Mozilla, each certificate
will get assigned a unique nickname. The cert stored in the internal
database will remember the association from actual cert to nickname.
The configuration in mail remembers the cert nickname.
If you are testing and doing trial and error, I guess you are playing
with your own CA and generating your own certs.
Make sure you don't confuse Mozilla by re-using the same certificate
serial numbers. Mozilla's crypto library NSS uses the pair
{issuer,serial number} to uniquely identify a cert. If you reuse serial
numbers, you pretty much confuse Mozilla.
If you ensure that, Mozilla should be clever enough to remember which
exact certificate you have selected for email configuration and to
automatically switch to a different one.
Kai
Larry Riffle wrote:
I'm involved in a project evaluating PKI for some local applications.
Thus I have several certificates and others are added and deleted
regularly. I'm new to this. Lots of trial and error going on here.
I have to keep going back and re-selecting my email encryption
certificate. The one I want to use for everyday email keeps getting
replaced by some of my more bizarre test attempts.
Most of the time the only way I can even get the certificate I want to
show up on the selection list is to delete all the others. Will I have
to use seperate keys for each to keep Mozilla from overriding? I'd
rather not do that.
