Open Bug 327001 Opened 18 years ago Updated 2 years ago

selection of wrong client certificate for TLS/SSL IMAP connection prohibits client authentication

Categories

(Thunderbird :: Security, defect)

Product:
Thunderbird
Component:
Security
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

People

(Reporter: pb, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Thunderbird 1.5 for Windows

Some days ago I have installed additional client certificates for e-mail signing and encryption. Before, only one client cert was installed with the only use for secure client authentication on TLS/SSL IMAP.

Since the additional certificates were installed, thunderbird selects the wrong one for client authentication on TLS/SSL IMAP which makes it unusable now.

Note that I have configured 4 IMAP servers, 2 of them with server side certificate only, one without TLS/SSL and one with client certificate required.

Reproducible: Always

Steps to Reproduce:
1. create an IMAP account to a server cert only secured TLS/SSL IMAP server
2. create an IMAP account to a client cert secured TLS/SSL IMAP server
3. install related client cert for #2
4. test -> working
5. install client certs for signing/encryption


Actual Results:  
wrong client certificate will be used for #2

Server (stunnel'ed) claims about:
Feb 13 14:46:49 server stunnel[6881]: VERIFY ERROR: depth=0, error=unable to get local issuer certificate: ...
Feb 13 14:46:49 server stunnel[6881]: SSL_accept: 140890B2: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned


Therefore client authentication using certificates no longer works, have to use stunnel now...

Expected Results:  
Proper match of related client cert in SSL/TLS session regarding the received server cert or capability for dedicated configuration of client certificate.

In Mulberry, the client certificate can be dedicated selected.

Currently, it takes the first certificate in list for client authentication.
Severity: normal → major
Forgot to mention, displayed error code in GUI: -12195
Looking for same problem in Firefox, I found, that Firefox contains an additional check box in GUI which toggles
  security.default_personal_cert

Changing in Thunderbird this existing key to

security.default_personal_cert = Ask Every Time

I can select the proper certificate, but unfortunately I have to do this every time (means if I select an IMAP subfolder, I will be asked again).

Why is there no "remember choice" implemented? Such feature would be really nice.
Related to/duplicate of bug 288195 or Core bug 257182?
Looks like the bugs mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=327001#c3 are of similar case. I will now drop a note there about my entry.
Same problem on Linux, and it looks like that since latest update here using FC5 to 1.5.0.7 the selector was gone (earlier, I was able to select which certificate I want to use for TLS client authentication).

BTW: no-one working on this???
OS: Windows 2000 → All
Version: unspecified → 1.5
I've reactivated the selector, looks like prefs.js looses the mentioned user settings.
Still happens in ThunderBird version 1.5.0.9 (20061206).  If I change the security.default_personal_cert to Ask Every Time will it remember my choice while still in a ThunderBird session?
it's even worse than that.  If I change the security.defautl_peronal_cert to Ask Every Time it asks but I CAN'T select the correct cert to use fot authentication.  BTW, I and another coworker can duplicate this at will.  Why is this still classified as Unconfirmed?
For sure it's very strange that noone from developer side is interested in this bug. BTW: can you check this also with 2.0.0.0rc1? If so, we can change the version, perhaps it get's more publicity afterwards.
Here's what I've found when testing with 2.0.0rc1 (BTW, this is on Linux):

1). I import my Verisign cert.
2). I set my Verisign cert to be the cert to sign and encrypt/decrypt messages with.
3). I try to send a message via my IMAP account (which should use my other personal cert)...connection hangs and on my mail server I see the incorrect cert presented.
4). I change security.default_personal_cert to "Ask Every Time".
5). I attempt to send again as in step 3...I get prompted for the Cert to use but the ONLY cert displayed is the Verisign cert (so I can't select my other cert).  I hit cancel and the mail sending hangs.
6). I clear the signing and encrypt/decrypt cert stuff.  I don't remove the Verisign cert at this point.
7). I attempt to send again, get prompted for a cert, hit cancel and lo and behold the mail get's sent (even though I could NOT select my other personal cert when prompted it still used the correct cert to send the mail).
8). I change the security.default_personal_cert back to "Select Automatically".
9). I attempt to send again and, this time, the mail hangs and the wrong cert is used.
10). I remove the Verisign cert from Thunderbird completely and attempt to send again and this time it works.
Oops, to make a short story long, it really doesn't work with Tbird 2.0.0rc1 any better then 1.5.x.  So this bugzilla should be posted for 2.0 as well.
Version: 1.5 → 2.0
Kai: is the cert-selection logic in PSM code or mailnews?
Assignee: dveditz → kengert
Status: UNCONFIRMED → NEW
Ever confirmed: true
First, please note there was recently a regression bug 370136 in FF 2.0.0.1 and FF 2.0.0.2 that could cause client auth to fail when a user has more than one cert. (Firefox 2.0.0.3 and later and Firefox 2.0.0.0 and earlier do not have that bug).

Kevin, when using "ask every time" and connecting to a particular server, you were surprised to see that Firefox only offers some of your certs, although you have more. The displayed list of certs is being influenced by the server. A server can send a list of CAs it accepts certificates from, and Firefox/Thunderbird will only display matching certs.


Yes, we are aware that client auth cert selection could be improved. But it's not as straightforward as it seems on first sight.

I invite you to read this wiki page:
http://wiki.mozilla.org/PSM:CertPrompt


(In reply to comment #12)
> Kai: is the cert-selection logic in PSM code or mailnews?

This is general PSM code.

After reading comment 0 and comment 1 more carefully:

Your stunnel server side log indicates that Firefox sends a certificate the server does not like. This might have been caused by an incorrect configuration on the server side. Your server might not give sufficient information about which CA will be accepted. If Firefox/Thunderbird is "left in the dark" about what certs the server would like to see, it will use any valid cert, and I don't see a mistake here.

If you would like to demonstrate this is a bug in Firefox/Thunderbird, I'd like to request that you send dumps of your certs and use the ssltap utility to produce a trace of your failing handshake.

The error code that Firefox gave you was -12195.
I agree this is not very helpful, and in Firefox 3 you'll see humand readable strings.

But -12195 means: 
SSL_ERROR_UNKNOWN_CA_ALERT
"Peer does not recognize and trust the CA that issued your certificate."

This supports the suspicion that
- your server did not specify the CA it uses
- mozilla client used any valid cert (which was correct)
- server could not verify that other cert and rejected it

(In reply to comment #13)

export NSPR_LOG_MODULES=IMAP:5

Should setting the above (and the log file of course) log the cert stuff that is going on because I'm not seeing it in the log file (is the number an aggregate of the 1 and 4 levels or does level 5 mean everything)?  How can I verify what the server is sending to the client as to what valid CA's it will accept?  I also find it strange that when I set "ask every time" and have my Verisign cert in Tbird, that is the only cert displayed, but if I hit Cancel at that box then the mail gets sent correctly anyway (even though I didn't select that cert and the only other cert available is the "bad" cert that is really the good cert)...shouldn't cancel be the same as "don't send the email but send me back to do more editing of the email before trying to send again"?

Oh, and are we talking about Firefox or Thunderbird because there seems to be an awful lot of mention of Firefox in this message and that's not where we are running into issues (at least not in this bug thread).

First, this bugzilla entry should be focussed on the thunderbird client cert issue.

NSPR_LOG_MODULES=IMAP:5 doesn't help, nothing useful regarding the certificate handling is shown.

While OpenSSL shows the used CA:

$ openssl s_client -connect server:993
CONNECTED(00000003)
depth=1 /CN=Certificate Authority/C=DE/L=Munich/O=Peter Bieringer/OU=Certificate Authority/emailAddress=pb@bieringer.de
verify error:num=19:self signed certificate in certificate chain
verify return:0
7351:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1057:SSL alert number 40
7351:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

thunderbird doesn't apply the filter anyway. 3 certificates are shown in dialog box, while only one should match.

On thunderbird 2.0.0.0 I get after importing the 2 client certs:
  Error -12271
Server side shows me, that in automatic mode still the wrong cert is sent.
In "ask every time" same happen like with 1.5.0.10

Do you have a Linux binary of "ssltap" available and are there more debug switche available for the certificate selection mechanism?

(In reply to comment #15)
> export NSPR_LOG_MODULES=IMAP:5

traces mail protocol, but not the SSL layer


> Should setting the above (and the log file of course) log the cert stuff that
> is going on

no

> How can I
> verify what the server is sending to the client as to what valid CA's it will
> accept?  

You could do so by using the ssltap utitily.

ssltap can act as a server, accepting a SSL connection, forwarding all data to the remote site, and at the same time dumping trace information about the connection.

In order to use it, you must:
- start a ssltab process on your machine, giving it hostname and port of the server, and a local listening port
- change your client to connect to host and port where ssltap is running


> I also find it strange that when I set "ask every time" and have my
> Verisign cert in Tbird, that is the only cert displayed, but if I hit Cancel at
> that box then the mail gets sent correctly anyway (even though I didn't select
> that cert and the only other cert available is the "bad" cert that is really
> the good cert)...shouldn't cancel be the same as "don't send the email but send
> me back to do more editing of the email before trying to send again"?

We could argue what's correct and what not, but...

At this point "cancel" applies only to the cert selection process, but not to the global application activity.

If you select cancel, you say "do not use any cert to authenticate". The connection will continue without a client cert.


> Oh, and are we talking about Firefox or Thunderbird because there seems to be
> an awful lot of mention of Firefox in this message and that's not where we are
> running into issues (at least not in this bug thread).

The SSL and client auth is in common code that is shared by both FF and TB.

(In reply to comment #16)
> First, this bugzilla entry should be focussed on the thunderbird client cert
> issue.
> 
> NSPR_LOG_MODULES=IMAP:5 doesn't help, nothing useful regarding the certificate
> handling is shown.

Right. In order to trace the connection, please use the ssltap utility.


> While OpenSSL shows the used CA:
> 
> $ openssl s_client -connect server:993
> CONNECTED(00000003)
> depth=1 /CN=Certificate Authority/C=DE/L=Munich/O=Peter
> Bieringer/OU=Certificate Authority/emailAddress=pb@bieringer.de
> verify error:num=19:self signed certificate in certificate chain
> verify return:0
> 7351:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
> failure:s3_pkt.c:1057:SSL alert number 40
> 7351:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:s23_lib.c:188:
> 
> thunderbird doesn't apply the filter anyway. 3 certificates are shown in dialog
> box, while only one should match.

Did you import the root CA cert into TB and did you mark it as trusted?
What I said about filtering would only apply if the CA is marked as trusted. (I really hope we do filter, but haven't tested it recently)


> On thunderbird 2.0.0.0 I get after importing the 2 client certs:
>   Error -12271

SSL_ERROR_BAD_CERT_ALERT

"SSL peer cannot verify your certificate." 

The remote system has received a certificate from the local system, and has rejected it for some reason.


Your certificates and / or trust settings seem to be bad.
I can't give any assistance until you provide a full set of all certs you created yourself. I suspect you made a mistake.


> Server side shows me, that in automatic mode still the wrong cert is sent.
> In "ask every time" same happen like with 1.5.0.10
> 
> Do you have a Linux binary of "ssltap" available and are there more debug
> switche available for the certificate selection mechanism?

If you are using Fedora Core 5 or later, ssltap is available through the "nss-tools" package.

> If you select cancel, you say "do not use any cert to authenticate". The
> connection will continue without a client cert.

This will not help in my case because authentication via client cert is required and not optional.

> Your certificates and / or trust settings seem to be bad.
> I can't give any assistance until you provide a full set of all certs you
> created yourself. I suspect you made a mistake.

Trusts are proper set, only the hostname of the server mismatchs, but this should have no impact (at least nothing more than the warning box) as long as a client certificate is available which matches the CA sent by the server.

But thie filter doesn't work here, because my other client cert from a complete different CA is not masked out at all.

BTW: without playing around with /etc/hosts, the hostname mismatch will also occur using ssltap.

BTW2: one should fix ssltap not displaying online help two times, if option "-?" is used ;-)
I finally tracked the issue down using openssl, it's a behavior difference in use of "stunnel" instead the use of "openssl s_server" on server side:

stunnel result:

config:

client = no
connect = localhost:imap
CAfile = /etc/pki/ca-cert.crt
cert = /etc/pki/server-cert.crt
key = /etc/pki/server-key.pem
ciphers = MEDIUM:HIGH:!ADH:!SSLv2
verify = 2
service = imap-stunnel

openssl s_client shows:

subject=/CN=gatemuc.muc.bieringer.de/C=DE/L=Munich/O=Peter Bieringer/OU=Gateways/emailAddress=pb@bieringer.de
issuer=/CN=Certificate Authority/C=DE/L=Munich/O=Peter Bieringer/OU=Certificate Authority/emailAddress=pb@bieringer.de
---
No client certificate CA names sent
---

Using openssl_server for tests instead with same(!) configuration:

# openssl s_server -accept 993 -cert /etc/pki/server-cert.crt -key /etc/pki/server-key.pem -CAfile /etc/pki/ca-cert.crt -verify 2


openssl s_client shows:

subject=/CN=gatemuc.muc.bieringer.de/C=DE/L=Munich/O=Peter Bieringer/OU=Gateways/emailAddress=pb@bieringer.de
issuer=/CN=Certificate Authority/C=DE/L=Munich/O=Peter Bieringer/OU=Certificate Authority/emailAddress=pb@bieringer.de
---
Acceptable client certificate CA names
/CN=Certificate Authority/C=DE/L=Munich/O=Peter Bieringer/OU=Certificate Authority/emailAddress=pb@bieringer.de
---

Suddenly, "Acceptable client certificate CA names" is shown and contain the CA.

So this must be a problem in the openssl library call of stunnel, why here "No client certificate CA names sent" is shown.

stunnel-4.15-2
openssl-0.9.8b-8.3.fc6

stunnel-4.20-2 does not improve the situation.

So connecting to "openssl s_server" using Thunderbird 1.5.0.10 the automatic selection will work.

Because stunnel is common used for SSL termination and probably other implementation have also problems in pushing the "accepted CA list" back the client one should think about an extension of the match mechanism using the CA of the server certificate as a fallback if the "accepted CA list" is empty.

In case still no certificate matches the "accepted CA list" (either empty or no proper CA shown) but an installed client cert can be used, this choice should be remembered at least for some minutes.

Will file a bug against stunnel now because of the absence of "accepted CA list".
Bug filed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237962
Intermediate result: sending the "accepted CA list" was disabled in stunnel-4.00, reason is currently unknown...and this behavior currently can't be configured by user.
Peter, thanks for your update.

Now that you know some problems have been caused by stunnel, how would you summarize the issues that are left in this bug?
1. fallback capability:

Capability of fallback on empty "accepted CA list" using the DN from the signing CA of the server certificate, toggable or by default


2, remember choice of selected client for some time

Currently for each new connection the client certificate selection box will be shown. There should be some kind of caching (e.g. at least for 5 minutes) of the selection of the client certificate per server, if a successful TLS/SSL session was done before using this client certificate.
see also Bug 322145 and Bug 290787
Assignee: kaie → nobody
If there are two certificates and the wrong one is chosen, then I just think we try to make the automatic mode too smart. What is wrong with trying the certificates until the right one is found and then save that discovery? Just brute force trial and error.
btw, the same bug is valid for POP3 client certificates.
Severity: major → normal
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.