721728 - security.ssl.warn_missing_rfc5746 is not boolean

Status: RESOLVED INVALID

(Thunderbird :: Account Manager, defect)

Description

[Lucas Betschart]

Attachment: 8.4.2-6.bmp

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Ubuntu/11.10 Chromium/15.0.874.106 Chrome/15.0.874.106 Safari/535.2

Steps to reproduce:

I tried to set security.ssl.warn_missing_rfc5746 to false like descripted here:
https://developer.mozilla.org/en/Preferences/Mozilla_preferences_for_uber-geeks



Actual results:

But in Thunderbitrd 10 security.ssl.warn_missing_rfc5746 is an integer.
Value by default 1. If i change it to 0 the warning still appears.


Expected results:

1) security.ssl.warn_missing_rfc5746 should be bool or changed here in documentation:
https://developer.mozilla.org/en/Preferences/Mozilla_preferences_for_uber-geeks

AND

2) After changing the value to 0/false, the SSL-Warning (see attached picture) should not appear.

Comment 1

[Lucas Betschart]

This mistake came up when I was asking for a solution to hide the SSL-Warning on the Thunderbird Support List:
http://groups.google.com/group/mozilla.support.thunderbird/browse_thread/thread/dee87ed734bcfde6

Comment 2

[rsx11m]

Looks like the documentation is wrong, it is indeed defined and used as integer:
mozilla/security/manager/ssl/src/nsNSSIOLayer.h line 272 (on trunk) reads
> static PRInt32 mWarnLevelMissingRFC5746;
and per mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp#860 any value >0 should prompt the message. You may need to restart Thunderbird to see any effect of the change you've made, depending on when that preference is actually read.

Comment 3

[Lucas Betschart]

I've tried many times, and restarted Thunderbird everytime.
Doesn't matter if I have set the value through about:config GUI or modified it with a .js file from /defaults/pref, the message always appears.

Comment 4

[rsx11m]

> 2) After changing the value to 0/false, the SSL-Warning (see attached
> picture) should not appear.

I see, this warning isn't strictly related to the RFC 5746 issue, that preference simply determines whether or not a failure in compliance is logged into the Error Console. The message you see comes from the Account Wizard which didn't get to a configuration that allows for encryption either by using a secure connection or secure authentication. I'm currently connected to a mail server which is not in compliance with RFC 5746, see that message in the Error Console, but SSL/TLS works fine anyway. Thus I'm not sure what else could prevent you from establishing a secure connection to that server (maybe anti-virus software interfering, or simply that the server indeed doesn't support any secure mechanism).

Comment 5

[Lucas Betschart]

Yes the sever doesn't support any secure mechanism. And he doesn't have to because he is running on the same machine. (Very special use case).

I want to hide this message because it could scare the people using our product and think its not secure. But it is.

So it is not possible to hide this message with security.ssl.warn_missing_rfc5746? Then this is not a bug, but what is this preference good for then?

Comment 6

[rsx11m]

Ok, so in that case it's not a security issue at all but related to the new Account Wizard (which is supposed to warn you if there is an unsecure connection, but the special localhost case may be covered by suppressing that warning as this usually implies some proxy or add-on involved; on the other hand, multi-user machines still want to use encryption if authentication is required and the network communication could be monitored by another user present on that machine at the same time).

Comment 7

[rsx11m]

(In reply to Lucas Betschart from comment #5)
> So it is not possible to hide this message with security.ssl.warn_missing_rfc5746?

No.

> Then this is not a bug, but what is this preference good for then?

It's purpose is to warn the advanced user that the secure connection established is subject to a possible exploit described in CVE-2009-3555 which requires fixes on both client and server side (Mozilla applications are fixed, the server isn't if that message appears, thus the protocol revised in RFC 5746 can't be used).

We should probably clone this bug to fix the MDN documentation...

Comment 8

[Lucas Betschart]

Mh I couldn't find a documentation category. And cloning doesn't works for me. Just brings me to the open new bug page.

How can I close this Bug?

Comment 9

[Ludovic Hirlimann [:Usul]]

(In reply to Lucas Betschart from comment #8)
> Mh I couldn't find a documentation category. And cloning doesn't works for
> me. Just brings me to the open new bug page.

That's how cloning works :(

> How can I close this Bug?

change the status to resolved and choose a resolution.

Comment 10

[Lucas Betschart]

Ok, I've made a clone:
https://bugzilla.mozilla.org/show_bug.cgi?id=722642

But during cloning I have seen no difference to creating a new bug from scratch?.

Comment 11

[rsx11m]

Cloning keeps a couple of settings, like CC's and dependencies, thus it makes things easier. I've confirmed your other bug and moved it to the MDN category.

Thanks!