236933 - Disable SSL2 and other weak ciphers

Status: VERIFIED FIXED

(Core :: Security: PSM, enhancement, P1)

Description

[Michel Brabants]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

Heya,

I wwould suggest to change the default security-settings ... I have disabled the
following myself:

SSLv2, all ciphers lower than 128 bit. And it would be even better yo disable
md5 and only allow the others like sha-1, ...

SSLv2 isn't secure anymore since some time. SSLv3 and TLS are the only "secure"
once to use these days as far as I know. It's good mozilla includes them "MAYBE"
for compatibility, but they shouldn't be enabled as defaults ...

I wouldn't advise people who use their computer for internet-banking to enable
SSLV2, ... Ofcourse there are maybe easier ways to break get the necessary info,
but disabling the things I mentionned above would help.

Michel

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> SSLv2, all ciphers lower than 128 bit.

A number of sites break when you do that.

In any case, this is a crypto issue, not a security one...

Comment 2

[John G. Myers]

SSL2-only sites still exist, see bug 76162.  There is already a security warning
for weak session ciphers.  It is not yet time to disable SSL2.

Comment 3

[Michel Brabants]

Ok, then.
But sites that use SSLv2 aren't really secured. Maybe they don't need it, but
anyway. There is only the impression of secuirty then to my knowledge ...(which
can be not big enough ofcourse). I hope it is a big warning that says it is
insecure for things like internet-banking, ... Anyway, for any seriuous things.
I hope there also is one for SSLv2 ... 

I suppose people haven no choice if they want to visit the site, but they should
be warned (which seems to happen ..for weak ciphers anyway). I hope they read it
or the print is big enough to rraw attention or something :).

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I think it would be time to reconsider this. According to
http://wiki.mozilla.org/Necko:SSL_v2_Sites there are only *three* sites known
not to work when SSLv2 is disabled. Many other sites have been mentioned, but
they all have since then upgraded.

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

*** Bug 247830 has been marked as a duplicate of this bug. ***

Comment 6

[Daniel C]

This depends on bug 307271. Once all (or a large majority) of those 102 sites
have been fixed, this bug should and can be fixed.

Comment 7

[Patrick]

bug 307271 comment 8 gives a screenshot of the error that occurs when SSL 2 is
disabled, but that particular error message doesn't help the novice user very much. 

For starters, it's not clear if this is a problem of the web page or firefox
[ie., the server or the client]. Furthermore, it doesn't give any steps towards
solving the problem for the user. And finally it just sounds very technical.

Can't we have an error page instead of a dialog, a la the error page for
non-existing pages?

Comment 8

[Daniel C]

Patrick Fey <[e-mail]> noted in bug 307271 that according to http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx Microsoft will be disabling SSLv2 by default in Internet Explorer 7. They will also be enabling SSLv3 and TLSv1 by default. This probably means that Mozilla can do the same. I doubt this will make it into 1.8, but it could make it into a security release from the 1.8 branch. Would disabling SSLv2 be considered for a security release? The reason I say this is because: 

1. I think it's too late for 1.8.
2. I think there are still too many un-upgraded sites (bug ssl2 lists 71 open bugs, some of these with more than one site).
3. Internet Explorer hasn't done it yet.

Therefore if this could make it into the first security release from the 1.8 branch _after_ Internet Explorer 7 is released, then it would solve all 3 problems. It would have more time to be considered (1), more sites will be fixed by then (2) and Internet Explorer would have done the same, therefore it would be acceptable for Mozilla to do it too (3). OK, so the last point is not really true. Just because Microsoft did it doesn't always mean that we should too. However, this is an exception. Microsoft have to decided to do A Good Thing.

What are people's thoughts on this?

Comment 9

[Kai Engert (:KaiE:)]

Daniel, what you say sounds reasonable to me.

In order to disable the SSL2 ciphers, we can change the default prefs value in file netwerk/base/public/security-prefs.js

As the current default is "true", and user's pref files contain non-defaults only, as soon as we change the pref, users will automatically our new default.

I would like to propose, that at the same time we disable SSL2, we also remove the UI for SSL2. However, we'd continue to have support for the SSL2 preferences. If power users decide to enable it.

In addition, I would like to propose, that at the same time we also deactivate weak SSL3+TLSv1 ciphers (40- and 56-bit), but keep them in the UI for now.

While this change is reasonable to stop people from using weak ciphers, it also means that more users will start to see error messages about incompatible servers. As users have also complained about the error message we show currently, I have tried to improve the wording, to be more explicit about the real cause of the failure.

Please see the changes in file pipnss.properties.

Comment 10

[Kai Engert (:KaiE:)]

Attachment: Patch v1

Comment 11

[Daniel C]

       <p><em>Use SSL 3.0</em><br/>
         Specifies whether you want to send and receive secured information
-        through SSL3 (Secure Sockets Layer Level 3), a protocol that is intended
-        to be more secure than SSL2. Note that some web sites may not support
-        this protocol.</p>
+        through SSL3 (Secure Sockets Layer Level 3).</p>

Perhaps that change should be left out? It's still true.

Should another bug be filed for turning more netwerk errors into the new error page form for Firefox? 15 preferences are being swithced off by this patch; aside from SSL2 which is tracked by 307271, how many more sites will cause errors after this patch?

Comment 12

[Gervase Markham [:gerv]]

Comment on attachment 206549 [details] [diff] [review]
Patch v1

>-SSLDisabled=You cannot connect to %S because SSL is disabled. 
>-SSL2Disabled=You cannot connect to %S because SSL version 2 is disabled.
>-SSLNoMatchingCiphers=%S and %S cannot communicate securely because they have no common encryption algorithms.
>+SSLDisabled=It is not possible to connect to %S securely, because your settings do not allow to use the SSL protocol.

Better, perhaps:

It is not possible to connect to %S securely, because the secure SSL protocol is disabled. You may re-enable it on the Security tab of the Advanced pane in your preferences.

>+SSL2Disabled=It is not possible to connect to %S securely, because your settings do not allow to use the outdated SSL protocol version 2.

It is not possible to connect to %S securely, because it only supports an older, insecure
version of the SSL protocol. Please ask the website owner to upgrade their site.

(Yes, it's possible to enable it, but there is absolutely no need to tell them that. The only people who would ever want to do it will know how.)

>+SSLNoMatchingCiphers=%S and %S cannot communicate securely, because they have no common encryption algorithms, or your SSL protocol settings do not allow to use them.

%S and %S cannot communicate securely, because they have no enabled encryption algorithms in common.

>       <p><em>Use SSL 3.0</em><br/>
>         Specifies whether you want to send and receive secured information
>-        through SSL3 (Secure Sockets Layer Level 3), a protocol that is intended
>-        to be more secure than SSL2. Note that some web sites may not support
>-        this protocol.</p>
>+        through SSL3 (Secure Sockets Layer Level 3).</p>

Maybe:

Specifies whether you want to send and receive secured information through SSL3 (Secure Sockets Layer, Level 3). This is a standard protocol for communicating securely with websites. Disabling it will prevent you visiting some secure sites.

(and the same for TLS as well).

Gerv

Comment 13

[Kai Engert (:KaiE:)]

Daniel, IMHO, if we no longer support SSL2 in the UI, we should no longer mention it in help text.

I agree with your proposal that more network errors might be turned into error pages. However, if I understand correctly, that's just a suggestion for nicer presentation, the information communicated to the user won't be different?

Comment 14

[Kai Engert (:KaiE:)]

Gerv, I like your wordings, I will attach a new patch.

Comment 15

[Kai Engert (:KaiE:)]

Gerv, you proposed: "Disabling it will prevent you visiting some secure sites."

I'm not a native english speaker, but I wonder, should we insert a "from", saying "prevent you FROM visiting"?

Comment 16

[Kai Engert (:KaiE:)]

Attachment: Patch v2

Comment 17

[Gervase Markham [:gerv]]

Kai: either is correct, but your version is probably clearer.

(Note that I'm probably not qualified to code review this patch.)

Gerv

Comment 18

[Kai Engert (:KaiE:)]

Attachment: Patch v3

added "from"

Comment 19

[Kai Engert (:KaiE:)]

mbeltzner: What do you think about this change? It has the following parts:

- The strings that Gerv and I discussed, they appear in error messages, only.

- A change to the firefox prefs UI, navigate to: menu edit / preferences / advanced / security. In the protocols section, SSL 2 will be gone, and both SSL 3 and TLS 1 will appear in the same, single line. The help section that explains SSL 2 will be removed, too.

- Changes to Seamonkey UI, edit pref / privacy / ssl. Remove the checkbox for SSL 2. There is an additional dialog that shows up when you click "edit ciphers". The SSL 2 tab will be gone.

- No changes to Thunderbird UI. (I just learned that Thunderbird does not offer the ability to configure which SSL protocols to use. I think this is confusing and inconsistent, because SSL is commonly used when connecting to mail servers, too.)

Comment 20

[Kai Engert (:KaiE:)]

Darin, FYI, we are planning to disable SSL2 and some weak ciphers. The attached patch changes the prefs in netwerk.

Comment 21

[Gervase Markham [:gerv]]

Kai: you probably need to request that a specific person review your patch.

Gerv

Comment 22

[Kai Engert (:KaiE:)]

Attachment: Firefox ScreenShot: current prefs, illustrates removal

Comment 23

[Kai Engert (:KaiE:)]

Attachment: Firefox ScreenShot: NEW prefs

Comment 24

[Kai Engert (:KaiE:)]

Attachment: Firefox ScreenShot: current help, illustrates removal

Comment 25

[Kai Engert (:KaiE:)]

Attachment: Firefox ScreenShot: NEW help

Comment 26

[Kai Engert (:KaiE:)]

Attachment: SeaMonkey ScreenShot: current prefs, illustrates removal

Comment 27

[Kai Engert (:KaiE:)]

Attachment: SeaMonkey ScreenShot: NEWS prefs

Comment 28

[Kai Engert (:KaiE:)]

Attachment: SeaMonkey ScreenShot: current cipher prefs, illustrates removal

Comment 29

[Kai Engert (:KaiE:)]

Attachment: SeaMonkey ScreenShot: NEW cipher prefs

Comment 30

[Kai Engert (:KaiE:)]

Attachment: Patch v3a - New strings

Comment 31

[Kai Engert (:KaiE:)]

Attachment: Patch v3b - UI Removal and Changed Prefs

Comment 32

[Kai Engert (:KaiE:)]

Comment on attachment 211708 [details] [diff] [review]
Patch v3a - New strings

Mike, can you please review/approve these string changes to error messages (all products) and help texts (Firefox)?

They have been proofread by Gerv already.

Comment 33

[Kai Engert (:KaiE:)]

Comment on attachment 211700 [details]
Firefox ScreenShot: current prefs, illustrates removal

Mike, can you please review this Firefox prefs UI change? We are removing an obsolete entry. There is also attachment 211701 [details] that shows how the new prefs look like.

Comment 34

[Kai Engert (:KaiE:)]

Comment on attachment 211704 [details]
SeaMonkey ScreenShot: current prefs, illustrates removal

Neil, can you please review this SeaMonkey prefs UI change? We are removing an
obsolete entry. There is also attachment 211705 [details] that shows how the new prefs
look like.

Comment 35

[Kai Engert (:KaiE:)]

Comment on attachment 211706 [details]
SeaMonkey ScreenShot: current cipher prefs, illustrates removal

Neil, can you please review this SeaMonkey prefs UI change? We are removing an
obsolete entry. There is also attachment 211707 [details] that shows how the new prefs
look like.

Comment 36

[Wolfgang Rosenauer [:wolfiR]]

What's the timeline for that change?
I would suggest to make it happen for FF/TB2 and SM1.1
and if we don't want the UI change for 1.8.1 what about changing the defaults at least?

Comment 37

[Kai Engert (:KaiE:)]

> What's the timeline for that change?
> I would suggest to make it happen for FF/TB2 and SM1.1
> and if we don't want the UI change for 1.8.1 what about changing the defaults
> at least?

(I'd prefer to remove the SSL 2 UI, but if we can't get the UI changes approved, changing at least the defaults would be better than no change at all.)

Yes, I agree, several people I spoke to who are involved in security would like to see this happen for FF 2, too.

Comment 38

[Kai Engert (:KaiE:)]

Attachment: Patch v3c - UI Removal [checked in]

Comment 39

[Kai Engert (:KaiE:)]

Attachment: Patch v3d - Disable weak SSL prefs [checked in]

Darin, could you please review this small change to
  mozilla/netwerk/base/public/security-prefs.js

It disables SSL 2 and the wek ciphers.
This change is independent of UI.

Comment 40

[[e-mail]]

Comment on attachment 211704 [details]
SeaMonkey ScreenShot: current prefs, illustrates removal

Once SSL2 is disabled by default, of course.

Comment 41

[Mike Beltzner [:beltzner, not reading bugmail]]

this will block the release of Firefox2

Comment 42

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 211700 [details]
Firefox ScreenShot: current prefs, illustrates removal

this part of the fix is fine. I kinda wonder why we'd need to point out the version number if it's the only option, but mconnor's convinced me that I'm just overthinking.

ui-r=me

Comment 43

[Darin Fisher]

Comment on attachment 212372 [details] [diff] [review]
Patch v3d - Disable weak SSL prefs [checked in]

r=darin

Comment 44

[Kai Engert (:KaiE:)]

I checked in the changed prefs on the trunk.

Comment 45

[Steffen Wilberg]

Comment on attachment 211708 [details] [diff] [review]
Patch v3a - New strings

r=me for the prefs.xhtml changes.

Comment 46

[Joe McCabe]

This change seems kind of awkward. There's no GUI option to overide the change (e.g. "Enable SSLv2"), and Thunderbird & Firefox lack GUI to enable/disable specific ciphers.

This makes things pretty broken for SMTP, IMAP, and HTTP servers that are using older cipher suites and, for whatever reason, the administrator is not inclined to update to newer encyption.

Comment 47

[Gervase Markham [:gerv]]

Times have changed, and we're not accepting "for whatever reason" any more. Are there any possible technical reasons for not using SSL3/TLS? Laziness is no longer an acceptable excuse.

(Specific ciphers is another issue; I can't speak about that.)

Gerv

Comment 48

[Joe McCabe]

(In reply to comment #47)
> Times have changed, and we're not accepting "for whatever reason" any more. Are
> there any possible technical reasons for not using SSL3/TLS? Laziness is no
> longer an acceptable excuse.

It's pointless to get into an argument about why administrators make the decisions they do.

Whatever their reasons are, both Thunderbord and Firefox have no end-user accessible GUI (about:config just doesn't count as "end-user accessible") to chose to over-ride these default settings. 

Why can't there be an "advanced security options" window (or something) where I can chose to use SSLv2 or various ciphers in SSLv3 or TLS if I, as a properly informed user, chose to use them? Why not just throw the usual "low grade security" warning to the end-user if they enable these things, and allow them ultimately decide it's OK?

Comment 49

[Gervase Markham [:gerv]]

> both Thunderbord and Firefox have no end-user
> accessible GUI (about:config just doesn't count as "end-user accessible") to
> chose to over-ride these default settings. 

No, and we don't have end-user UI to enable any other feature we don't support either.

> Why can't there be an "advanced security options" window (or something) where 
> I can chose to use SSLv2 or various ciphers in SSLv3 or TLS if I, as a 
> properly informed user, chose to use them? 

Because we want to put pressure on recalcitrant admins to upgrade their sites, rather than reduce their users' security by telling them to switch to a less safe way of doing things.

If you want this UI in your Firefox, and assuming the code to support SSL2 hasn't been completely removed by then, feel free to write an extension.

Gerv

Comment 50

[Scott MacGregor]

Hey Kai, could any of these changes have caused:

Bug 328731 --> unable to read secnews newsgroups in seamonkey and Thunderbird? 
 
"SeaMonkey and secnews.netscape.com cannot communicate securely because
they have no common encryption algorithms."

Comment 51

[Kai Engert (:KaiE:)]

> "SeaMonkey and secnews.netscape.com cannot communicate securely because
> they have no common encryption algorithms."

Indeed, while secnews.netscape.com supports SSL 3, it supports weak ciphers with bit sizes < 128 only.

Comment 52

[Joe McCabe]

(In reply to comment #51)
> > "SeaMonkey and secnews.netscape.com cannot communicate securely because
> > they have no common encryption algorithms."
> 
> Indeed, while secnews.netscape.com supports SSL 3, it supports weak ciphers
> with bit sizes < 128 only.

Not to beat a dead horse here, but this is what I was talking about above.

Surely a GUI that allows the user to make an educated decision to proceed anyway is in order?

Comment 53

[Gervase Markham [:gerv]]

For 99.9% of users, in the few seconds they have before they find the "Yeah, whatever" button on the dialog, it's not possible to educate them about the risks of using low grade encryption and/or SSL2. 

Secnews is a bad example, because everyone knows there's nothing remotely secret or worth keeping secure on it. As I understand it, the SSL stuff is merely an anti-spam measure.

We know the admin of that server; asking him to fix it shouldn't be too hard.

Gerv

Comment 54

[Joe Sabash [:JoeS1]]

Two points:
Which one of those pref changes would enable secnews.netscape.com in current trunk
If the server is reconfigured, what about users with older builds.

I would like to use seamonkey and Thunderbird for testing, and secnews is one of my tools.

Comment 55

[Joe McCabe]

(In reply to comment #54)
> Two points:
> Which one of those pref changes would enable secnews.netscape.com in current
> trunk

Go to about:config. Search for SSL. Start turning on ("true") the ciphers that are off ("fasle"). Eventually you'll find the magic one(s) that secnews requires.

Start with the SSL3 ciphers. If none of those work, enable SSL2, rinse and repeat.

> If the server is reconfigured, what about users with older builds.

All builds older than about a week ago won't have this problem.

Comment 56

[Kai Engert (:KaiE:)]

Comment on attachment 212371 [details] [diff] [review]
Patch v3c - UI Removal [checked in]

This patch removes the UI for SSL 2 in both Firefox and SeaMonkey.

We already have approval on this UI change from UI owners, see r+ on patches in this bug.

Bob, can you please review this removal patch?

Comment 57

[Kai Engert (:KaiE:)]

> see r+ on patches

I was trying to say, see r+ on screenshots.
Attachment 211700 [details], attachment 211704 [details], attachment 211706 [details] are all approved.

Comment 58

[Robert Relyea]

Comment on attachment 212371 [details] [diff] [review]
Patch v3c - UI Removal [checked in]

r+ relyea

Comment 59

[Kai Engert (:KaiE:)]

Comment on attachment 212371 [details] [diff] [review]
Patch v3c - UI Removal [checked in]

Mike, do you need to review the small code change that removes the SSL 2 checkbox from the Firefox prefs UI? Note the screenshot is already reviewed.

The respective portion is at the very end of this patch. I made sure the remaining items are aligned, as you can see in attachment 211701 [details]

Comment 60

[Kai Engert (:KaiE:)]

Comment on attachment 212371 [details] [diff] [review]
Patch v3c - UI Removal [checked in]

I figure I should have asked for branch approval right away... I believe the change in mozilla/browser/ requires a superreview as weel.

Comment 61

[Steffen Wilberg]

> I believe the change in mozilla/browser/ requires a superreview as weel.
It doesn't, see http://www.mozilla.org/projects/firefox/review.html.

Comment 62

[Nelson Bolyard (seldom reads bugmail)]

With the control UI gone, there's no "by default" about it.  It's just gone.

Comment 63

[Kai Engert (:KaiE:)]

Comment on attachment 212371 [details] [diff] [review]
Patch v3c - UI Removal [checked in]

checked in to trunk and 1.8 branch. Thanks a lot for your reviews and approvals.

I consider this bug mostly done, as the functionality has changed and SSL 2 UI has been  removed.

What's left is the proposed change to the error messages, as well as updating the firefox prefs help page. Therefore I'll not yet close the bug.

Comment 64

[Ian Neal]

There is also the SeaMonkey help pages that will need updating too.

Comment 65

[u60234]

Comment on attachment 211708 [details] [diff] [review]
Patch v3a - New strings

>Index: mozilla/security/manager/locales/en-US/chrome/pipnss/pipnss.properties
>===================================================================
>+SSLDisabled=It is not possible to connect to %S securely, because the secure SSL protocol is disabled. You may re-enable it on the Security tab of the Advanced pane in your preferences.

This is a helpful advice for Firefox users, but not necessarily for users of other apps that might see this string.

Comment 66

[PeterG]

To give some feedback, I do not use webmail hardly ever, but with the recent Firefox 1.8.1 builds you cannot log into Shaw Cable webmail without getting the error message: http://www.shaw.ca/en-ca (menu at the top)

I spoke to a supervisor at Shaw regarding this and it was suggested that I send an email to [e-mail] but when I asked how effective this would be, I was told "not very effective". Not the largest ISP in North America but they do have over 1.2 million cable modem subscribers. 

Comment 67

[Bob Lord]

Thanks bantry for the update.

Shaw is using RC4 with 40-bit keys, which they should have upgraded after 2000 when the US export regulations were changed.

The error message that comes up about not having ciphers in common might be improved a little so people know that the service is trying to use non-secure encryption.

Comment 68

[Gervase Markham [:gerv]]

bantry: please file a Tech Evangelism bug. Although I assume Shaw's webmail doesn't work with the IE 7 beta either? I suspect that, if that's the case, they'll be working on fixing it pretty soon.

Gerv

Comment 69

[Kai Engert (:KaiE:)]

> The error message that comes up about not having ciphers in common might be
> improved a little so people know that the service is trying to use non-secure
> encryption.

Such improved error messages are the subject of attachment 211708 [details] [diff] [review] in this bug, which are awaiting review and approval.

Comment 70

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 211708 [details] [diff] [review]
Patch v3a - New strings

Some suggestions for making the strings more usable:

>+SSLDisabled=It is not possible to connect to %S securely, because the secure SSL protocol is disabled. You may re-enable it on the Security tab of the Advanced pane in your preferences.

"This site has requested a secure connection, but Firefox can't connect  to this site because SSL has been disabled."

note: We can't say "Preferences", because it's "Options" in Windows. Unless you want to pass that variable along (but then localization kinda sucks). If possible, the better thing to do here would be to include a help button on the dialog that launches a help page about the security preferences/options.

>+SSL2Disabled=It is not possible to connect to %S securely, because it only supports an older, insecure version of the SSL protocol. Please ask the website owner to upgrade their site.

"This site has requested a secure connection, but using an obsolete and insecure system which Firefox does not allow."

note: most users don't know how to ask the website owner to upgrade their site; users who do don't need to be told to do so ;)

>+SSLNoMatchingCiphers=%S and %S cannot communicate securely, because they have no enabled encryption algorithms in common.

"This site has requested a secure connection, but Firefox doesn't support the security system that this site uses."

Also, why are these modal dialogs instead of browsermessages? Using browsermessages we could still render the non-secure content (if any) on the page and simply alert the user to the fact that some of the content was blocked for the stated reason, much like we do for pop up blocking.

Comment 71

[Chris Milne]

Just to chime in, this disabling of support for low-grade encryption is affecting Camino Version 2006062002 (1.0+) as well but without any coherent explanatory error message [(null) and www.site.com cannot communicate securely because they have no commmon encryption algorithms]. The site in question is https://paragon.acs.org/paragon/ which is, for many chemists, not an 'optional-usage' site & could probably be accurately qualified as a deal-breaker (note: no argument ACS is in the wrong here). Either Camino's error message needs to be changed to more accurately reflect what's going on, and/or the ability to allow the user to override this behaviour needs to be added to a Preference pane (Security). Camino needs to cover the same ground Firefox has apparently already been through.

Comment 72

[Bob Lord]

(In reply to comment #71)
> Just to chime in, this disabling of support for low-grade encryption is
> affecting Camino Version 2006062002 (1.0+) as well 

Good catch. Please file a bug against Camino to make sure they see the issue.

Comment 73

[Kai Engert (:KaiE:)]

(In reply to comment #70)
> 
> Also, why are these modal dialogs instead of browsermessages? Using
> browsermessages we could still render the non-secure content (if any) on the
> page and simply alert the user to the fact that some of the content was blocked
> for the stated reason, much like we do for pop up blocking.

We use a modal dialog, because this is shared code, and the same problem can occur with connections in other parts of the application, like email or ldap.

Comment 74

[Kai Engert (:KaiE:)]

Attachment: Patch to remove help for controls that have gone away [checked in]

Carrying forward r+ from steffen.wilberg (see comment 45, patch v3a)

Will check in to trunk now.
Requesting approval for 1.8.1

I separated this chunk from patch v3a, because the other strings need more discussion.

Comment 75

[Kai Engert (:KaiE:)]

Hi Mike, could you please look at the strings again? Here is my answer to your earlier comments. Thanks!


(In reply to comment #70)
> >+SSLDisabled=It is not possible to connect to %S securely, because the secure SSL protocol is disabled. You may re-enable it on the Security tab of the Advanced pane in your preferences.
> 
> "This site has requested a secure connection, but Firefox can't connect  to
> this site because SSL has been disabled."


You are removing the address we can not talk to. IMHO we should not say "this site" but rather "www.something.com", this is why we have the %S in the string.


> note: We can't say "Preferences", because it's "Options" in Windows. Unless you
> want to pass that variable along (but then localization kinda sucks).

agreed


> >+SSL2Disabled=It is not possible to connect to %S securely, because it only supports an older, insecure version of the SSL protocol. Please ask the website owner to upgrade their site.
> 
> "This site has requested a secure connection, but using an obsolete and
> insecure system which Firefox does not allow."

I believe the better error message should not give less information than before. Your proposal does not explain to advanced users / administrators that this problem is due to the SSL protocol version.


> >+SSLNoMatchingCiphers=%S and %S cannot communicate securely, because they have no enabled encryption algorithms in common.
> 
> "This site has requested a secure connection, but Firefox doesn't support the
> security system that this site uses."

I think your proposed wording is not giving enough information to user / to administrators.
The problem might occur because the user has changed (advanced) preferences that disable some encryption ciphers. This is possible using about:config. IMHO the error message should give a clue this might be the reason.

Comment 76

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #75)
> (In reply to comment #70)
> > >+SSLDisabled=It is not possible to connect to %S securely, because the secure SSL protocol is disabled. You may re-enable it on the Security tab of the Advanced pane in your preferences.
> > 
> > "This site has requested a secure connection, but Firefox can't connect  to
> > this site because SSL has been disabled."
> 
> You are removing the address we can not talk to. IMHO we should not say "this
> site" but rather "www.something.com", this is why we have the %S in the string.

As long as we're just using the domain and not the full URI, I'm fine with that. Also, the more I look at my original suggestion, the less I like it, also, we should be using "&prodName;" (or whatever is used to get Firefox/Camino/SeaMonkey, etc.)

Here are some new proposals:

"&prodName; can't connect securely to %s because the SSL protocol has been disabled."

> > >+SSL2Disabled=It is not possible to connect to %S securely, because it only supports an older, insecure version of the SSL protocol. Please ask the website owner to upgrade their site.
> > 
> > "This site has requested a secure connection, but using an obsolete and
> > insecure system which Firefox does not allow."
> 
> I believe the better error message should not give less information than
> before. Your proposal does not explain to advanced users / administrators that
> this problem is due to the SSL protocol version.

"&prodName; can't connect securely to %s because the site uses an older, insecure version of the SSL protocol."

> > >+SSLNoMatchingCiphers=%S and %S cannot communicate securely, because they have no enabled encryption algorithms in common.
> > 
> > "This site has requested a secure connection, but Firefox doesn't support the
> > security system that this site uses."
> 
> I think your proposed wording is not giving enough information to user / to
> administrators.
> The problem might occur because the user has changed (advanced) preferences
> that disable some encryption ciphers. This is possible using about:config. IMHO
> the error message should give a clue this might be the reason.

"&prodName; can't connect securely to %s because the site uses a security protocol which isn't enabled."

^ this assumes that we're talking about SSL and TLS, and not something else. If we are talking about something else, and that something is referred to in the prefs as an encryption algorithm (I couldn't find any such pref) then:

"&prodName; can't connect securely to %s because the site uses an encryption algorithm which isn't enabled."

Comment 77

[Mike Beltzner [:beltzner, not reading bugmail]]

Kai, can we get the bits with 1.8.1 approval checked into the branch?

Comment 78

[Kai Engert (:KaiE:)]

Comment on attachment 227109 [details] [diff] [review]
Patch to remove help for controls that have gone away [checked in]

This patch has been checked in to trunk and 1.8 branch.

Comment 79

[Kai Engert (:KaiE:)]

(In reply to comment #77)
> Kai, can we get the bits with 1.8.1 approval checked into the branch?

done

Comment 80

[Kai Engert (:KaiE:)]

(In reply to comment #76)
> 
> As long as we're just using the domain and not the full URI, I'm fine with
> that.

yes! just domain


> also, we should be using "&prodName;" (or whatever is used to get
> Firefox/Camino/SeaMonkey, etc.)

ok


> "&prodName; can't connect securely to %s because the SSL protocol has been
> disabled."

ok


> "&prodName; can't connect securely to %s because the site uses an older,
> insecure version of the SSL protocol."

ok


> "&prodName; can't connect securely to %s because the site uses a security
> protocol which isn't enabled."

ok


> ^ this assumes that we're talking about SSL and TLS, and not something else. 

yes!

Comment 81

[Kai Engert (:KaiE:)]

Attachment: Patch 5 - strings [checked in]

This patch uses the exact wording proposed by Mike, marking ui-review=beltzner

A minor code chane is required, Bob can you please review?

Comment 82

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Could you please cc someone from Camino ([e-mail] generally will get the message to the right people) when making large changes like this to items that are commonly exposed in Mozilla product UI?  Thanks!  I only happened upon this bug because we were wondering about removing our "warning on weak ciphers" checkbox and stumbled here in looking for sites to test that UI....

I'll also note that with a current trunk build and the "Patch 5 - strings" attachment above, Camino still displays "null" rather than "Camino" in the weak ciphers message:

 "(null) can't connect securely to webmail.shaw.ca because the site uses a security protocol which isn't enabled."

Comment 83

[Mike Shaver (:shaver emeritus)]

(In reply to comment #76)
> "&prodName; can't connect securely to %s because the SSL protocol has been
> disabled."

Has been disabled where?  Site or &prodName;?  I read it the wrong way around the first time, possibly because %s is closer to "has been disabled" than &prodName is.

Don't have any improved suggestions ATM, though. :(

Comment 84

[Kai Engert (:KaiE:)]

(In reply to comment #82)
> I'll also note that with a current trunk build and the "Patch 5 - strings"
> attachment above, Camino still displays "null" rather than "Camino" in the weak
> ciphers message:

Does Caminio not support %1$S notation?
Is there Camino-specific code required to make it work?
Our code to get the product name string is here:
http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/src/nsNSSIOLayer.cpp#533

If Camino-specific code required, this should be addressed in a separate bug.

Comment 85

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

From that code snippet this looks to me a lot like the problem we ran into with neterror.xhtml and its entities not being embedding-friendly (see bug 302309); beltzner might remember for sure.

(The "solution" there was to punt and go with generic terms in the strings, and then Firefox overrode them itself at some later point.)

Comment 86

[Robert Relyea]

Comment on attachment 227640 [details] [diff] [review]
Patch 5 - strings [checked in]

r=rrelyea

Comment 87

[Kai Engert (:KaiE:)]

Comment on attachment 227640 [details] [diff] [review]
Patch 5 - strings [checked in]

As we have disabled the wek ciphers on 1.8 branch, I propose to also check in these improved error strings.

Comment 88

[Kai Engert (:KaiE:)]

all pieces checked in to trunk, marking as fixed.

Comment 89

[Marek Stępień [:marcoos, inactive]]

For 1.8 this would be a late-l10n change, so renaming the property names is required.

CC'ing Pike.

Comment 90

[Axel Hecht [:Pike]]

Reopening, Patch 5 should be backed out.
Please don't do semantic changes to strings without changing their entity names.

Comment 91

[Kai Engert (:KaiE:)]

Attachment: rename strings in v5 [checked in]

Addon-patch to rename string ids and their single occurrence in code.

Comment 92

[Kai Engert (:KaiE:)]

Attachment: combined patch v5 for 1.8 branch

this patch has r=rrelyea for code, ui-review=beltzner for new strings, r=l10n for changed string ids

Comment 93

[Kai Engert (:KaiE:)]

marking fixed on trunk

Comment 94

[Darin Fisher]

Comment on attachment 228034 [details] [diff] [review]
combined patch v5 for 1.8 branch

a=darin on behalf of drivers

Comment 95

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 228034 [details] [diff] [review]
combined patch v5 for 1.8 branch

As the person who (arguably) answers most questions from users about SSL
issues, I have some questions and comments (objections) to the new error 
messages.

>-SSLDisabled=You cannot connect to %S because SSL is disabled. 
>+SSL_Disabled=%1$S can't connect securely to %2$S because the SSL protocol has 
> been disabled.

Where has it been disabled?  At the remote site?  locally? 
I suggest: "%1$S can't connect securely to %2$S because the SSL protocol has 
            been disabled in %1$S."
Also, I might suggest some text that suggests a remedy, e.g. how to turn it 
back on.  We can anticipate the question this message will raise.  Why not 
answer it in the product disalog instead of in bugs and newsgroups?

>-SSL2Disabled=You cannot connect to %S because SSL version 2 is disabled.
>+SSL2_Disabled=%1$S can't connect securely to %2$S because the site uses an 
> older, insecure version of the SSL protocol.

Several comments:
1) You could shorten "the SSL protocol" to just "SSL".
2) The important thing is that the site uses ONLY an older version.
3) Now that there are 3 (soon to be 4) versions of SSL, I think it is important 
   to be precise about which older version you are describing.  
4) I wouldn't describe SSL2 as absolutely "insecure".  It is less secure than
   SSL3+.

So I suggest: "%1$S can't connect securely to %2$S because %2$S uses only SSL2,
               an older, less secure version of SSL, which %1$S no longer uses."

>-SSLNoMatchingCiphers=%S and %S cannot communicate securely because they have 
> no common encryption algorithms.
>+SSL_NoMatchingCiphers=%1$S can't connect securely to %2$S because the site 
> uses a security protocol which isn't enabled.

This is going to raise lots of questions of the form "what security protocol
does the site use?" and "how do I enable it in %1$S" ?

It is a problem because (a) "protocol" suggests something other than SSL, and 
(b) the problem is more likely to be that %1$S doesn't implement it, rather
than it imerely being disabled.  

The "no common" remark is most accurate and IMO understandable by users. 
If you don't like "encryption algorithms", try "ciphers".  

The order of the two arguments is unimportant in this context.

I suggest "%S and %S cannot communicate securely because they have no 
           ciphers in common.  If you have disabled any SSL ciphers, 
           you might need to re-enable them, otherwise contact the site's
           administrator."

Comment 96

[Gervase Markham [:gerv]]

A general problem I see with those suggestions is that we don't actually want people to turn these capabilities back on. That's why we turned them off, and removed the user interface for turning them on again!

I suppose it's possible that this might lead to newsgroup questions; we could perhaps mitigate this by saying "contact the site administrator". But we should not say "please turn them back on", because that leads to the obvious question "If that's a good idea, then why weren't they turned on in the first place?"

Gerv

Comment 97

[Stuart Parmenter]

sounds like this should be marked fixed and a new bug should be filed on error messages.

Comment 98

[Peter da Silva]

"A general problem I see with those suggestions is that we don't actually want
people to turn these capabilities back on. That's why we turned them off, and
removed the user interface for turning them on again!"

If Firefox was Internet Explorer... or even sonething as widely used as Apache or Sendmail... you might have a chance of doing something useful by taking this attitude.

Given some of the other security decisions Firefox has made... for example, the whole XPI installation fiasco (still ongoing)... I think having an "advanced insecurity" pane to turn weak ciphers back on would be useful.

You could put "enable XPI auto install" in there as well, and add a menu item under "File" for installing XPI manually.

Comment 99

[Chris Elmquist]

I think the decision to disallow SSL2 in FF 2.0 has made FF 2.0 non-usable
in a very large number of corporate applications.  Significant amounts of
the internal infrastructure at this company still use SSL2 and we are now
experiencing non-connectivity to these systems from Firefox 2.0 users who
must then revert to FF 1.5 or to IE 7.  FWIW, IE 7 users are not having this problem and the conclusion these people make is that FF 2.0 is broken and IE 7 is not.  This is a horrible situation to now be in.  We will very quickly loose
credability that FF is a viable alternative to IE.

Can't you at least have a control that allows us to turn it back on even if
you default to having it disabled?

Can you try to negotiate SSL3 first and if that fails, revert to SSL2?

The opinion here is that this is a premature decision to terminate SSL2 support.
As much as you want to, you will not be able to force these IT systems to
update.  They will instead push their users to IE 7 or (hopefully) FF 1.5

Chris Elmquist
Network Engineering
SGI

Comment 100

[Jo Hermans]

(In reply to comment #99)
> As much as you want to, you will not be able to force these IT systems to
> update.  They will instead push their users to IE 7 or (hopefully) FF 1.5

SSL2 is also be disabled by default in IE7, according to http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx (I can't verify it it's treally true). But they might find it easier to change the default ; you can in Firefox too, but you'll have to change several preferences.

Comment 101

[Steffen Wilberg]

SSL2 is disabled in IE7 as well. See Tools->Options->Advanced->Security->Use SSL2 (translated from the German version of IE7). Click on "Restore Advanced Settings" just in case.
I've also tried a few sites listed in bug 307271 (e.g. https://register.btinternet.com/), and they all fail in IE7 as well. IE's error message is a general one though ("the website cannot be displayed").

Comment 102

[Nelson Bolyard (seldom reads bugmail)]

SSL 3.0 is now 10+ years old.  TLS 1.0 (SSL 3.1) is 7+ years old.  
TLS 1.1 is now an RFC (though not widely implemented yet), and 
TLS 1.2 is now being drafted.  

It's LONG PAST time for companies to stop being exclusively reliant on SSL2.
Mozilla and FF announced their intention to disable SSL2 in FF2 and IE7 
long ago.  

I reopened this bug because of an unresolved issue with error dialogs, not
because the disabling of SSL2 is a bad idea.  There really should be a 
separate bug about the error dialog text.  I'm re-resolving this bug, fixed,
as it was before I reopened it.

Comment 103

[Chris Elmquist]

(In reply to comment #100)

> SSL2 is also be disabled by default in IE7, according to
> http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx (I can't verify it it's
> treally true). But they might find it easier to change the default ; you can in
> Firefox too, but you'll have to change several preferences.

We have verified it here and for our internal services that still use SSL2.0,
FF 2.0 fails and IE 7 works.  This is using the "out of the box" config of both
browsers without any heroic reconfig.  So my only point is that the impression
the end user now gets in these situations is that FF is broken and IE isn't.
I understand the security risk and how long SSL3.0 has been in existance but
when is the last time you got your IT department to do anything in favor of the users?  It is always about reducing their workload so they are not going to support two browsers and they are not going to upgrade internal (meaning not
accessible to the Internet) systems.  This would cost them time and money and is not economically viable just to make the Open Source browser work. They look at this situation as a whole, see that IE 7 works, make that statement to the world and claim "our work is done here". So, FF _will_ loose ground in this battle.

Clearly you have made up your minds but I still maintain that it is a premature and unfortunate decision.  The problem is even more significant for those of us who use only Linux and FF.  We now have no browser that will access these internal systems unless we stay at FF 1.5--  that is why I suggested that there be at least some way (however hidden or difficult) to still turn SSL2.0 back on.  That way we will not have to keep toggling between FF1.5 for talking to internal web sites and FF2.0 for everything else.

Anyway, thank you for your time and efforts on FF.  Obviously we are committed users and don't want to see it be displaced by IE due to this issue-- that is why I have taken the time to explain the situation we have encountered.
 

Comment 104

[Peter da Silva]

If you want to improve security in Firefox, I would recommend taking a good hard look at the way XPI installs are done and rather than trying to make an inherently insecure process secure, remove the support for the "install" button by default, and add an "install extension" entry to the contextual menu and File menu, so the *user*, not the web page, unambiguously initiates the process of installing an extension.

As for this bug, I agree with the last comment. Make it an "advanced" preferance, make it off by default, give it a description that makes it clear that SSL2 is insecure, but make it possible.

Comment 105

[Mike Shaver (:shaver emeritus)]

(In reply to comment #103)
> We have verified it here and for our internal services that still use SSL2.0,
> FF 2.0 fails and IE 7 works.

Can you provide more detail about the ciphers and such used, preferably in another bug?  I'm surprised to hear that IE7 works with a site that only uses SSL2, and I suspect that Microsoft would be as well.  Is it possible that the IE7 settings were changed by some Group Policy to re-enable SSL2?

> that is why I suggested that there
> be at least some way (however hidden or difficult) to still turn SSL2.0 back
> on.

There is indeed such a way, intentionally hidden and difficult: the pref "security.enable_ssl2".  http://visibleprocrastinations.wordpress.com/2006/10/25/what-we-have-here-is-failure-to-communicate/ has instructions.

Comment 106

[Samuel Sidler (old account; do not CC)]

v.branch & trunk.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.14) Gecko/2008040413 Firefox/2.0.0.14

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050704 Minefield/3.0pre