163861 - Support "multiple account on same server with SSL certificate authentication" configuration

Status: NEW

(MailNews Core :: Security, defect)

Description

[Kai Engert (:KaiE:)]

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.

Comment 1

[Kai Engert (:KaiE:)]

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".

Comment 2

[Kai Engert (:KaiE:)]

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.

Comment 3

[Kai Engert (:KaiE:)]

Attachment: Patch v1

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.

Comment 4

[Kai Engert (:KaiE:)]

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.

Comment 5

[Robert]

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)...

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 7

[Ludovic Hirlimann [:Usul]]

Kaie , have things changed here since 2002/2003 ?

Comment 8

[Kai Engert (:KaiE:)]

(In reply to comment #7)
> Kaie , have things changed here since 2002/2003 ?

I don't think so