Daily chat client should not ask for an SSL certificate when connecting to a server through SSL.

NEW
Unassigned

Status

defect
7 years ago
4 years ago

People

(Reporter: ntrrgc, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

7 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120530 Firefox/14.0a2
Build ID: 20120530042008

Steps to reproduce:

I installed Daily. Awesome! The next thing I did was configuring IRC.
I added the Freenode IRC server through SSL, and set it to connect every time I start Daily.
It worked fine.

Then, I set up my SSL certificates for signing mail through S/MIME. It worked too.

Then, I restarted Daily.


Actual results:

Now, every time Daily tries to connect to Freenode through SSL, it prompts me for a SSL certificate *of mine*. This is not needed at all.

Why on the Earth should I provide my S/MIME certificate only to connect Freenode?

Clicking Cancel works, but it prompts again every time I start Firefox and connect Freenode through SSL. It is misleading and cumbersome.


Expected results:

AFAIK, it should not prompt for a SSL certificate, as it didn't before I installed my S/MIME certificates into Daily, and as other IRC clients doesn't either.
I've added a comment about this on bug 437683. I too think Thunderbird shouldn't prompt for a password. I haven't tried setting security.default_personal_cert to Do not send, but setting is global...
Status: UNCONFIRMED → NEW
Ever confirmed: true
This looks a lot like we should use the ANONYMOUS_CONNECT flag: http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/socket/nsISocketProvider.idl#77

I wonder if that would prevent sending credentials to proxies though.
Duplicate of this bug: 783524
Bug 783524 also had a report of this for XMPP, I'm pretty sur ethis is somethign with our socket code though, so it shouldn't be IRC or XMPP specific.
Summary: Daily chat client should not ask for an SSL certificate when connecting to an IRC server through SSL. → Daily chat client should not ask for an SSL certificate when connecting to a server through SSL.
After reading the code, it seems the intended behavior of the "Remember this decision" checkbox is to remember for the session. Nothing seems to be saved on the disk, and that seems to be what the developer who wrote the code intended.
CC'ing kaie who may have some insights here.

Kaie, is it a bug that we get a prompt to select a user certificate when connecting to an IRC server over SSL for the first time after starting Thunderbird?
The resulting user experience is quite poor, as if the IRC accounts are configured to connect automatically at startup, the user has a modal prompt at each startup :(.
From the description, it sounds like Mozilla opens a connection to the server, and starts the SSL handshake, and the server asks for client authentication. Is that correct?

If you are not sure, can you please tell me the hostname and port number that you use for connecting to the server?

Juan, did the Freenode IRC community give you a SSL client certificate that you use to identify yourself? If not, it sounds like a bug.


Just in case there isn't a bug, but you own a matching personal cert and the server's request for SSL based authentication is legitimate.

Yes, in this scenario, it is expected that you get the prompt each time you restart Mozilla. It's because we don't have proper a implementation yet that can remember site specific preferences. See https://wiki.mozilla.org/PSM:Topics#SSL_client_authentication
(In reply to Kai Engert (:kaie) from comment #7)
> From the description, it sounds like Mozilla opens a connection to the
> server, and starts the SSL handshake, and the server asks for client
> authentication. Is that correct?

I don't think the server asks for client authentication, but I'm not 100% sure.

> If you are not sure, can you please tell me the hostname and port number
> that you use for connecting to the server?

I've just reproduced the bug again when connecting to chat.freenode.net:6697

chat.freenode.net is a load balanced pool of servers though, so some servers may not behave exactly like the others.
With at least asimov.freenode.net and pratchett.freenode.net I get the certificate prompt.
For me this happens each time I connect to irc.mozilla.org:6697 using SSL. I always select Cancel on the User Identification Request window, since I don't think I should use my StartCom certificate to identify myself. I'm not sure what happens when I do identify using that certificate and when I tell Thunderbird to remember that decision...
I inspected the SSL handshake to chat.freenode.net:6697 and irc.mozilla.org:6697 using the ssltap utility.

Both SSL servers send a certificate_request protocol message, asking the client for a client authentication certificate. They use an empty list of CA certificates, indicating their willingness to accept anything.

We behave correctly. Mozilla should remember your "cancel" action for the remainder of your running session for the given target site.

I don't know why those servers are configured that way, I find it surprising. Usually, if a server is configured for client authentication, it should also communicate a whitelist of CAs having issued certificates, which are accepted by the server for the purpose of authentication.

The configuration running on those IRC servers might be a bad default.
I've communicated with freenode staff on a support channel, they told me that client certificate authentication is possible, see https://www.freenode.net/certfp/ - which means that the behavior you see is expected.

Given our current limitations, you'll have to deal with the prompt once after startup for each destination. Improvements to this situation will require someone to work on 
https://wiki.mozilla.org/PSM:Topics#SSL_client_authentication
Reporter

Comment 12

7 years ago
Oh, that seems like a cool feature, although there should be a way to get rid of TB asking each time for client certificate (both in case you use or you don't use it). Maybe an option for permanently picking a client certificate in the "account" (IRC) settings?

BTW, I just tried connecting to Rizon with SSL (irc.rizon.net:6697). It not only displayed the 'pick a certificate' dialog, but then disconnected. Then it retried once and again and never worked.

Rizon uses invalid SSL certificates, so maybe it could be that TB is not prompting the user on certificate error, and just closing the connection? That would make for another bug report.
Another way to fix this bug could be:
- change the authentication default on the socket used for the IRC/SSL connection
- add a checkbox to account configuration
- disable client SSL authentication unless the user has manually enabled the configuration checkbox

BTW, user Fuchs on IRC has proposed that Thunderbird should implement SASL authentication  support for Freenode as that's the preferred authentication method. More information can be found at http://freenode.net/sasl/
I'm only forwarding this suggestion. You might want to file a separate bug for it. (I won't, I don't want to get the bugmail as the bug reporter).
kaie, thank you so much for looking at this!
Is there any way that users could mark a certificate as only for signing/encrypting emails, and not for being used for SSL client auth?

Or is there any scriptable way to tell NSS to not attempt to SSL client auth a specific socket, so that we could add a hidden pref telling socket.jsm (http://mxr.mozilla.org/comm-central/source/chat/modules/socket.jsm#408) to ignore certificates, so that users who sign emails wouldn't be annoyed by this startup prompt any more?
(In reply to Kai Engert (:kaie) from comment #13)
> Another way to fix this bug could be:
> - change the authentication default on the socket used for the IRC/SSL
> connection

Any pointers to what code I should write to do that?

> - add a checkbox to account configuration
> - disable client SSL authentication unless the user has manually enabled the
> configuration checkbox
> 
> Thunderbird should implement SASL
> authentication  support for Freenode as that's the preferred authentication
> method.

That's being discussed and implemented in https://bugzilla.instantbird.org/show_bug.cgi?id=1573
(In reply to Florian Quèze [:florian] [:flo] from comment #15)
> (In reply to Kai Engert (:kaie) from comment #13)
> > Another way to fix this bug could be:
> > - change the authentication default on the socket used for the IRC/SSL
> > connection
> 
> Any pointers to what code I should write to do that?

Have a look at nsSSLIOLayerImportFD and SSL_GetClientAuthDataHook.

You might be lucky, there is already an anonymousLoad flag that can be provided on socket construction.
(In reply to Florian Quèze [:florian] [:flo] from comment #14)
> Is there any way that users could mark a certificate as only for
> signing/encrypting emails, and not for being used for SSL client auth?

I don't think so

Updated

7 years ago
OS: Linux → All
Hardware: x86_64 → All
(In reply to Kai Engert (:kaie) from comment #16)

> Have a look at nsSSLIOLayerImportFD and SSL_GetClientAuthDataHook.
> 
> You might be lucky, there is already an anonymousLoad flag that can be
> provided on socket construction.

Thanks. I already mentioned the ANONYMOUS_CONNECT flag in comment 2, but I'm afraid it would also prevent sending credentials to proxies. (The same flag on HTTP requests prevents it).

Comment 19

5 years ago
There have been a lot of changes in this area - does that affect the status of this bug?
Flags: needinfo?(clokep)
This is likely still an issue.
Flags: needinfo?(clokep)
Duplicate of this bug: 1134472

Comment 22

4 years ago
(In reply to Florian Quèze [:florian] [:flo] from comment #18)
> > You might be lucky, there is already an anonymousLoad flag that can be
> > provided on socket construction.
> 
> Thanks. I already mentioned the ANONYMOUS_CONNECT flag in comment 2, but I'm
> afraid it would also prevent sending credentials to proxies. (The same flag
> on HTTP requests prevents it).

Does this matter at the moment? We don't support HTTP proxies yet anyway (Bug 955075).
(In reply to aleth [:aleth] from comment #22)
> (In reply to Florian Quèze [:florian] [:flo] from comment #18)
> > > You might be lucky, there is already an anonymousLoad flag that can be
> > > provided on socket construction.
> > 
> > Thanks. I already mentioned the ANONYMOUS_CONNECT flag in comment 2, but I'm
> > afraid it would also prevent sending credentials to proxies. (The same flag
> > on HTTP requests prevents it).
> 
> Does this matter at the moment? We don't support HTTP proxies yet anyway
> (Bug 955075).

Socks proxies can also have a username/password. Would they not be affected?
You need to log in before you can comment on or make changes to this bug.