Open Bug 163861 Opened 20 years ago Updated 7 years ago
Support "multiple account on same server with SSL certificate authentication" configuration
Required environment to see this problem: - you have at least 2 mail accounts on the same mail server - you connect using SSL - you are not using password based authentication, but certificate based SSL client authentication - your server must actually support using SSL auth instead of password auth - therefore, you are using different certificates to authenticate for each mail account Problem: Mozilla displays the same mailbox contents for both configured accounts. Expected behaviour: Mozilla should provide a way to work with contents of both accounts.
Clearly: If the user has chosen the client certificate selection preference to "select automatically", this environment can not work. The application will likely always choose the same certificate, authenticate to the server with the same certificate for both accounts, and as a result, will show the same account twice. So as a requirement, this kind of environment can only be supported when client authenticate selection is configured to be "ask every time".
The first problem is: SSL is using a session cache. If the application does not use some special logic, the SSL session cache will simply reuse SSL handshakes based on a host:port identity. Right now, Mozilla does not use the special logic that would be required to allow SSL to distinguish the connections to the same server:port, and it will reuse the client certificate authentication selection. The first step to a solution is: When the application logic is opening a SSL network connection, and there is the risk that multiple different sessions could be opened for different accounts/shares on the same server, the application should pass a kind of "identity tag" down to the SSL network layer, which it can use to distinguish.
This patch is a first attempt to find a solution. Unfortunately, due to the generic interfaces that are used to communicate between application code and SSL layer, I had to make a lot of changes.
patch v1 is not yet good enough to land. The idea of the solution is: The application should pass on an identity tag - which is unique enough to guarantee that for each connection using a different identity a separate SSL session will be used - which is non-random, to make sure the SSL session cache can still be used whenever it is reasonable, to keep the good performance Patch v1 tries to do that by passing on the user name of the accessed account down to SSL. But still, there are two problems: Problem 1) ========== When doing SSL based auth, the field user name might not even be filled in to the account preference, because it is not required when authenticating with the server (I think). A better choice would probably been to pass on the email address (as Nelson suggested it). However, at the code location where I added the changes, the email address was not available. That seems to be stored in some other higher level class. As a result, more code needs to be changed to pass on the account's email address (or similar) to the mail protocol code that starts the connection. Problem 2) ========== I think the user experience is still not good enough. I assumed in a previous comment, a user would ultimately have to configure "ask every time" for client certificate authentication. The following environment would be working: - user has NOT configured accounts to check mail automatically - users checks account 1. - certificate selection prompt comes up - user knows which account this request is for, and selects the correct one - user now decides to check the other account - again the cert picker comes up - user again knows which cert is the correct one to authenticate and selects the correct one. However, the phrase "user knows which cert to choose" is only correct because the "check mail" action was manually triggered by the user. The problem starts when a user configures "check mail at startup" or "check mail automatically every n minutes". In that case, the user will not know which certificate to select, since our current UI does only say "server has asked for authentication, please select cert for server". But the user has no clue for which account he will get prompted first and is unable to decide which cert is correct to choose now. As a result, in order to fix this bug correctly, we need to also extend the UI. The client authenticate certificate prompter needs to be extended to display the shown identity tag in the UI. I realize that also means, the patch v1 should also be changed to pass the identity tag as a unicode string, not a C string.
I guess the same thing happens with Web bank account access. In my case 3 members of my family use the same bank so each has his/her own certificate. When I log on to online bank account, mozilla uses the first certificate it finds, so if I enter password for second or third, mozilla doesn't know that and bank reports wrong password (because combination of password and certificate is not right). I know it's possible to enable Ask every time in Mozilla but if I do this then it asks for every click or transaction in progress I make on that page which is rather annoying. It would be nice for Mozilla to have possibility of selection of Identity on entrance of such page (addres, port) and would use that identity through whole session (like IE)...
Regarding comment 5, there is a fundamental difference between the situation described in this bug, and the situation described in comment 5. This bug describes a single user with multiple accounts that are all his personal accounts. Comment 5 describes 3 users sharing a computer, each with his/her own personal account. In that situation, it is really much more appropriate for each user to have his/her own mozilla profile, with his/her own security databases and his/her own password to protect his/her private keys. By combining all the keys and certs into a single profile, you have created a situation where it is possible (indeed easy) for any of these users to impersonate the others. The solution to this is necessarily different than the solution to the problem described in this bug.
Kaie , have things changed here since 2002/2003 ?
(In reply to comment #7) > Kaie , have things changed here since 2002/2003 ? I don't think so
You need to log in before you can comment on or make changes to this bug.