[posted and mailed] [cut my own stuff]
> When a user authenticates to a remote server using a local PKCS 11 > device, and then either logs out of the device or removes the device, > NSS/mozilla will no longer allow the authenticated SSL session to be > reused or restarted. Any subsequent attempt to use an authenticated > SSL session that was originally authenticated with the smart card will > require reauthentication. That means the user will have to reinsert > his card and login again. > > This is intended to make it so that when a user takes his smart card > and leaves, someone else cannot sit down at his computer and continue > to use his authenticated session, pretending to be the authenticated > user. > > Communicator did not check that the card is still present and still > logged in as often as mozilla does, and that was seen as a bug. > Mozilla checks for each SSL connection. I think it may even check for > each http request. It seem to be for every SSL connection, not for each http request. Not that it matters too much; mozilla has more concurrent connections than in the old days :) > > The way that NSS checks to see if the card is still present and logged > in is by calling C_GetSessionInfo and examining sessionInfo.state. If > the call fails, or returns one of the "PUBLIC" session states, then > the card has been logged out or removed. > > So, based on your description, I'd guess your module is returning a > public session state when queried for each http request. That is correct. We require a PIN to be entered before every private key cryptographic calculation. Therefore the session state will be public after the sign operation. It seams that the Mozilla software requires authentication on both sessions (SSL and on the SmartCard). This may seem correct, but this is debatable. You will only need one private key operation to be performed to create an SSL session. It may be in the interest of the user not to cache the PIN after a cryptographic calculation. Maybe it would be a good idea to use the C_GetSessionInfo return value. If this returns anything else than CKR_OK the session is invalid. Therefore, the SSL session will be invalidaded as well. Note that when a token is removed, the session should always be invalid according to PKCS# 11. To require the user to be in an authenticated state in relation to the token may be one step too far. We are currently debating if we can lessen the security by requiring the PIN code to be entered once per process instead. Since this is a mayor design change we are hesistant to take this step. Well, at least we know now at what stage the problem occurs. Thanks for your time and information, Warper
