535649 - log console warnings regarding CVE-2009-3555 and RFC 5746 (SSL renegotiation)

Status: RESOLVED FIXED

(Core Graveyard :: Security: UI, defect)

Description

[Kai Engert (:KaiE:)]

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555

Once http://tools.ietf.org/html/draft-ietf-tls-renegotiation-02 has been finalized and a NSS release has been made available that supports it, we'll need to enhance PSM.

PSM will need to make decisions based on server support for the new TLS extension.

When talking to a server not indicating support for this TLS indication, PSM may drop the connection or continue anyway.

The default behavior shall change in phases:
- (1) be lenient and continue anyway, 
  but show some indication in UI to warn about the potentially vulnerable server
- (2) block connection by default,
  but allow the user to override manually
- (3) always block the connection

As of today it's unclear whether or not we'll ever do (3), although it's desirable.

It seems necessary to do (2) at some point, when enough servers have been upgraded, so that only very few sites will require a manual override.

We should do (1) as soon as possible for evangelism purposes.


I'll start this bug as security sensitive initially, as I'm not sure whether our plans can already be made public.

Comment 1

[Kai Engert (:KaiE:)]

Johnathan:

Initially, we may allow connections anyway.

Soon afterwards, we will need to block connections by default, and I propose to show a (new) error page, similar to what we do for bad certificate errors, but with adjusted wording.

We'll need an override mechanism for users to connect anyway to selected servers.

I propose to leverage the existing override mechanisms for cert problems, and introduce a new 4th error category for "server uses potentially vulnerable protocols". This means we'll need additional wording around the "add cert/server exception" UI.

We might have to get this implemented quickly, and potentially have this backported. We'll need this at least in FF 3.6 and probably even FF 3.5.

Therefore I'm proposing to leverage existing UI as much as possible.

However, we'll need new strings that explain the problem and remind the user of the new dangers.

I propose to make an exception for this vulnerability, and initially add english strings, only (assuming that localization may take more time and might be a real hassle for the stable branches).

This should happen quickly.
I'd like to see this shipped in February 2010.

This assumes the draft to be finalized before xmas, and the supporting NSS version available 30 days afterwards.

Comment 2

[Kai Engert (:KaiE:)]

Here is more recent thinking:

- the 3-phase plan described in the initial comment in this bug
  still sounds like a good plan

- the draft is still not finalized, but it's "very close", so we are able
  to start playing with code, and test connections (We know a test server)

- once the draft is final, we want to do step 1:
  release NSS 3.12.6 and ship a new Firefox that advertizes
  the new SSL/TLS renego-extension in handshakes,
  in order to bootstrap its use on the web.

  This means:
  - Firefox continues to connect anywhere
  - optionally show some chrome for old (not-yet-upgraded) sites
  - add hidden config option to control our requirements 
    regarding servers and their support for the new extension (renego-ext)
    (for testing and for paranoid people)

- we must decide how exactly chrome will be in step 1

- for step 2 (= block-by-default, require override)
  we've got a bit more time to make our decisions


Step 2 will require user friendly messages for sites that are not yet upgraded.
We have some time to polish this, however, because of the pref-for-paranoids introduced with step 1, we'll need at least "some" UI right away.

I'll add another comment where I make proposals for step 1.

Comment 3

[Kai Engert (:KaiE:)]

Regarding the chrome for step 1:

Our options when connecting to an old server (initially most of the web) are:

(a) don't show any warning indicators in chrome

(b) hide security indicators (padlock and green)

(c) use mixed mode security indicator (broken lock icon, no green)

(d) invent a new notification


(a) is trivial to do, but it will delay evangelism


In order to do (b) (c) or (d), we'll need the patch from bug 540304.


(b) and (c) can be done without any new UI code or strings, but users won't understand what exactly is wrong with the server.


(d) will require us to add some new state to nsIWebProgressListener (like we did for EV).

(d) could be done using some new icon, only, which would avoid to add new strings, but may be unclear to users without text.

(d) could be done as a clickable icon that brings up some explanatory text, but this will require us to add strings to stable branches (assuming we want this on 3.6, at least)


I think (b) and (c) are confusing, although I could accept them, if there is a consensus.

Ideally I'd prefer (d-with-text), but realistically I'll expect we don't get this done quickly.

Therefore I'd like to recommend (d-with-icon-only) for the initial release.

We could show one additional icon next to the existing padlock icon (status bar).

What icon? My idea is to show text "CVE-2009-3555" next to the padlock icon. Users can google for this, and can learn what this is about, without requiring any text in the UI, without requring localization.

As soon as a server upgrades, the text "CVE-2009-3555" will no longer be shown for the server.

Johnathan, what do you think?

Comment 4

[Kai Engert (:KaiE:)]

The icon showing text "CVE-2009-3555" could be a link that opens a web page that briefly describes the problem in a (localized) web site.

Comment 5

[Kai Engert (:KaiE:)]

My above comments covered the scenario:
- we connect anyway
- we discover an old not-yet-upgraded server and want to warn the user

Now I'd like to talk about the "block connection to server" scenario.

As said, we'd like to introduce a hidden pref that allows paranoid users (or testers) to block connections to not-yet-upgraded servers.

This should bring up an error page.

Once we get to step 2 (block by default) at some later time,
this should (?) produce a nice and helpful error page.

For now (in the initial patch I'll propose), this will produce a simple error page that mentions NSS' new error code around renegotiation:
  SSL_ERROR_RENEGOTIATION_NOT_ALLOWED

This will get mapped to string
  "Renegotiation is not allowed on this SSL socket."
however, it requires bug 540332.


(I wonder if NSS should report a different error code when connections to potentially vulnerable servers are disabled by policy, like 
  SSL_ERROR_UNSUPPORTED_VERSION
  Peer using unsupported version of security protocol.
)

Comment 6

[Kai Engert (:KaiE:)]

@Bob Relyea

We talked about adding prefs to Mozilla to control the handshake requirements.

First new pref:
- add "bool" pref "security.ssl.require_safe_negotiation"
  which directly maps to the NSS SSL socket option of the same name
    SSL_REQUIRE_SAFE_NEGOTIATION

  In step 1, this will be set to "false".
  Later in step 2, this will be set to "true" by default,
  but can be overriden.


For the second new NSS SSL socket option named
  SSL_ENABLE_RENEGOTIATION
we will use the default setting
  SSL_RENEGOTIATE_REQUIRES_XTN

Some power users may want to allow renego. with a not-yet-upgraded server.
Instead of a global pref, I recommend to use a site specific pref.
No UI, but a hidden string pref.

For this, I propose to add a second new pref:

- add "string" pref "security.ssl.renego_unrestricted_hosts"
  which is a comma separated list of hostnames.
  When we connect to a hostname listed in this pref,
  we'll configure the socket to use:
    SSL_REQUIRE_SAFE_NEGOTIATION = false
    SSL_ENABLE_RENEGOTIATION = SSL_RENEGOTIATE_UNRESTRICTED


I see there is also socket option 
  SSL_ENABLE_RENEGOTIATION = SSL_RENEGOTIATE_NEVER

I understand this option makes sense for servers.

But I understand this setting, when used in the client,
can't prevent the initial server-renego MITM attack.

I can't think of a need to set this option in a client.
Do you agree?

But if you can think of a need, we could introduce a third pref, 
"string" pref "security.ssl.renego_never_hosts"

Comment 7

[Kai Engert (:KaiE:)]

Attachment: Patch v1

Asking Johnath for his thoughts around UI for step 1.

Asking Bob for his thoughts around the prefs.

Comment 8

[Kai Engert (:KaiE:)]

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

Initial patch.

It needs NSS 3.12.6 prerelease, bug 527659 attachment 411906 [details] [diff] [review], bug 540304 attachment 422112 [details] [diff] [review], bug 540332 attachment 422121 [details] [diff] [review], bug 537356 attachment 420681 [details] [diff] [review].

It implements option (c) from comment 3.

It implements the first 2 prefs described in comment 6.

If pref 1 is manually set to true, it will produce the error page described in comment 5

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

It must be understood that merely completing an SSL handshake with a 
vulnerable server, and nothing more than that, is enough to make a browser
user be a victim of the renegotiation attack.  

If you do a handshake with a vulnerable server, and then afterwords, see 
that the server did not return a renegotiation info extension in the server
hello, it's too late the protect the user from any harm.  Any harm has 
already been done at that time.  The only way to protect the user is to 
not let things get that far.  To protect the user, you must not allow a 
handshake to complete until you know that either
a) the server is not vulnerable, or 
b) the user is OK with proceeding, even though the server is vulnerable.
That means, you don't allow NSS to complete a vulnerable handshake without 
the user's consent FIRST.

Comment 10

[Kai Engert (:KaiE:)]

Nelson, yes I understand.

I'm not sure why you remind us.

Nobody claims that step 1 will provide any protection.

I thought you were aware of the proposed strategy, but I'll reiterate:

Step 1 is the first preparation towards a solution, bootstrapping the use of renego-ext between clients and servers, and trying to evangelize the world about broken servers (by showing some chrome about unsecure servers, after-the-fact).

Yes, in order to provide protection, we must proceed to step 2 as soon as possible, but I hear that browser vendors don't want to break the web at once.

We want to do a first release that warns, hope that servers will upgrade quickly.

As soon as some serverupgrading milestone gets reached == as soon as "most" sites support renego-ext == as soon as the safe default behavior of Firefox will only show a small percentage of broken sites, 
  -> then we'll enable the safe default == step 2

Comment 11

[Honza Bambas (:mayhemer)]

Personally I vote for 'a' (=do nothing) but have an option (defaulted to false) to let the handshake fail for old servers and show an error page similar to certificate error page, potentially allowing user continue by click of a button.  That would then be IMO also a final version of the UI.  We may change the option to true even in a minor security update w/o a risk after majority of server are updated.

When I move to a place like open wifi in a cafe I am allowed to manually turn the option on and have the protection.  However, this is suitable only for expert users.

As an ordinary user I simply want to open a page in my browser.  If we do not allow such a user do that, he goes to a different browser.  Any icon on top, broken lock or what ever, common people will just ignore.  And BTW, it has just an informal value like "you probably had just been subject of an attack we didn't protect you from, have a nice rest of your day".

Comment 12

[Johnathan Nightingale [:johnath]]

I find it hard to disagree with much that Honza has said in comment 11. I am concerned about the idea of a UI indicator that:

a) will be activated most of the time in the early days
b) which, as Nelson points out, alerts people that they've already lost

I understand why we want an intermediate stage as an advocacy tool, but separate icons, with cryptic-to-most CVE identifiers are going to confuse a lot of our users in order to win the participation of a small portion of them as advocates. What's more, when the site continues to load and function, I strongly suspect that most users will conclude the problem is not serious. Now we'd end up with an ineffective indicator taking up a fair bit of primary chrome.

I think a pref that enables/disables blocking of connections with broken renegotiation, pref'd off at first but available for people who want it, is the right first step.

When true, I think an error page that explains the situation is a good idea, but I don't think it should use the existing exception mechanism. That interaction is used when the identity of a site is unknown, letting the user extend trust where we haven't, and having a safe connection thereafter. Adding an exception to allow a particular site to use insecure renegotiation will never be a safe connection thereafter, so I don't think we should re-use the mechanism. An error page that explains the problem and points users at (e.g.) a SUMO page describing the problem and the prefs necessary to change it feels like a better approach, there. That may not be pleasant with netError.xhtml, but I think it's what I'd want users to see.

Comment 13

[Kai Engert (:KaiE:)]

I hear you want (a) as described in comment 3.

The bool pref for people to toggle is security.ssl.require_safe_negotiation as described in comment 6.

I agree we should not reuse the exception mechanism for bad certs for this new problem category.

For those who prefer to set the pref to "true", I think it's helpful to have the additional whitelist pref I described (and implemented).

If we go with this proposal:
- no warnings for old servers (a)
- allow all connecctions

then nobody will see the new error page. Only people who manually switch the pref will get it. This means only people already being educated about the problem will get the error page.

Because of this, the simple error page seems sufficient for the first step.

In the future, at the time we switch the pref to "block by default, require override", we'll need the enhanced error page with explanations and link to SUMO.

Comment 14

[Kai Engert (:KaiE:)]

Attachment: Patch v2

This updated patch implements (a)

I simply removed the change to nsNSSCallbacks.cpp.
This patch no longer requires the NSS code from bug 540304.

Comment 15

[Kai Engert (:KaiE:)]

While I can accept (a) if that's the consensus, I'd like to state that I'm really surprised we want to go that path.

SSL is broken. Period. It's broken until we disallow connections to potentially vulnerable servers. And it's our responsibility to push the world into upgrading.

From the Mozilla manifesto at http://www.mozilla.org/about/manifesto.en.html :
"4. Individuals' security on the Internet is fundamental and cannot be treated as optional."

Since this bug became public, I'm scared each time I use SSL and especially when I use online banking or Paypal. I think you should be, too.

Being a pragmatic person I agree that we can't break the web at once. But giving no hint about broken sites whatsoever? Continuing to give our users the impression that everything is just fine, without any warnings or chrome by default?

I feel that's wrong. I feel that doesn't match the self advertisement of Firefox being the "safer way to surf the web". (seen today on http://www.mozilla-europe.org/en/firefox/ )

Even the smart people who will learn about the new pref, how many of them will turn it on?
A pref that is like shooting yourself in the foot, because afterwards there is no comfortable way to connect to 99.99% percent of the web anyway?

If we don't show any blame, all 300 million users will think we're just fine and everyone will assume no further action is necessary.
People will be lazy.

Server admins have the responsibility to take action, but who suffers from un-upgraded servers? The users.

How will users know that they are in danger, despite them using the most recent version of Firefox, despite Firefox implementing support for the latest protocol?

If we do (a), nobody will know, and users will be "unshielded", both in software and, more importantly at this time, shielded from awareness.
They won't be aware that their service providers are lazy or slow, and whether the service provider cares about them.

If we do (a), will anyone using Firefox put pressure on their ISP and tell them to upgrade their server? I don't think so. Well, maybe a handful of evangelists.

If we do (a), only, and if the thinking is to directly go to "block by default" at some later point... then how can we ever reach the point where we feel the upgrade percentage is high enough so we can block by default?

In my opinion, it will take much much longer, because there is no pressure for admins to upgrade their sites.

I understand that Opera will have such an indicator to warn users about out-of-date servers.

To somewhat support my point, I'd like to cite what Bob said in bug 540304 comment 11:

"The purpose of the UI indicator is to shame sites into updating. (Why doesn't
firefox show that my site is secure? Answer: because it isn't until you upgrade
your server).

Obviously when we turn on that indicator will depend on how fast sites upgrade
their servers. It doesn't do any good if the indicator is on for 90% of the
websites."


To conclude:

I believe SSL is broken, and I believe we must make the world aware.

I believe this issue is sufficiently critical to deserve some chrome space by default, even if many people will ignore it, because the following users won't ignore it:
- the press will gladly notice that we assist our users
- the tech savvy people will kick their server admins
- the bosses will kick their IT staff to make this scary indicator go away for their company site

Yes, I know that it's an indicator after the fact, but hey: The educated users will see this indicator when they open the start page of their bank. It will be there even before they hit submit. Yes, agreed, there will be SOME sites where the actual login data is sent to a different server that may have a different upgrade status. But is that potential mis-information an argument to not warn in the other scenarios?

I think we MUST turn on some indicator very soon, long before we'll see success and come close to the upgrade percentage reach 90%.

Comment 16

[Honza Bambas (:mayhemer)]

Kai, I do agree with you.

I'm just afraid that most people are not lazy, but stupid - my experience.  Many people will report that we show something that they don't understand and will claim that Firefox "shows that their site is broken from a certain FF version, but it works well in IE, because IE doesn't indicate any problem".  We know that it is because IE will never care of things like these (maybe will and I'll be wrong!).

However, let's hope that some people are intelligent, as Kai lists in the previous comment and to have such UI makes sense. Yes, it's better then do nothing, because it actually is what we are able to do at the moment from the UI/UX perspective.

We have to have a good indicator. What about a combination of broken or better even none security and a bar at the top of the content page? The would be explaining "this site might potentially be risky to use because it uses an old vulnerable version of the software, [CVE-2009-3555], [block sites like these]".

Comment 17

[Johnathan Nightingale [:johnath]]

(In reply to comment #15)
> While I can accept (a) if that's the consensus, I'd like to state that I'm
> really surprised we want to go that path.

Just to be clear here, because re-reading my comment above, I can see that I wasn't:

 - I don't think a novel indicator, and reference to a CVE, is a good idea, for the reasons stated
 - I do think that a pref to make this problem a hard stop, with an error page that, at best, links to sumo articles, but offers no exception mechanism, is a thing we should do immediately
 - *** I have not closed the book on all forms of intermediate behaviour. 

I actually think the thing I would favour is that we use the broken ssl icon for this, with helpful text that describes (possibly in Larry, definitely in Page Info) the problem. We sometimes refer to that icon as the "mixed content" icon, but the visual metaphor has always been "broken security" and that's what we have, here.

Losing SSL status (broken padlock, no more blue/green identity button and identity text) should be enough to push many sites to upgrade, but more importantly, it accurately reflects the state of security to the user. I don't want to pretend they're safe when they aren't any more than anyone else does, which I hope you know well enough to not need to quote the Manifesto to me, but you're nevertheless correct that the problem is real, and a response is required.

I would like to see all of this land on trunk before we talk about branch, but if it can land very soon, we can make a case to have the necessary strings translated as part of the Lorentz release plan, which is ushering in Out of Process Plugins, ideally as a minor 3.6.x update. That isn't a guarantee, that release is very locked down, but there will be some string work, so it's possible that we can make that request.

Does this plan make sense to you, Kai? I think we'd want a different pref for the broken ssl behaviour, too, so that we can talk about when to enable it independently of getting the rest of this code reviewed, but I'd be interested in your opinion on that as well.

Comment 18

[Kai Engert (:KaiE:)]

(In reply to comment #17)
>  - *** I have not closed the book on all forms of intermediate behaviour. 

I'm glad to hear this, I'm sorry for misinterpreting your words earlier. I'm happy to hear you're open to showing some indicator as soon as we can. Thanks for the clarification! I'll reply in more detail shortly.

Comment 19

[Kai Engert (:KaiE:)]

> I do think that a pref to make this problem a hard stop, with an error page
> that, at best, links to sumo articles, but offers no exception mechanism, is a
> thing we should do immediately

We agree that we want this pref.
I call it "security.ssl.require_safe_negotiation"
For our first step: set to false (don't require).

Users can set to true (require) and get error pages for servers not yet upgraded.

No exception mechanism shown in nor on error page.

I propose to add the additional hidden (no UI) pref 
  "security.ssl.renego_unrestricted_hosts"
where users having set the pref to "require upgraded servers" 
may specify some override sites.


> I think we'd want a different pref for
> the broken ssl behaviour, too, so that we can talk about when to enable it
> independently of getting the rest of this code reviewed

I'm not clear what you refer to when you talk about a second pref.

I think we agree to have a pref for the "block bad sites", as I described above in this comment.

I must speculate what second pref you'd like to see. Do you want a pref that controls whether or not we'll show an indicator for not-yet-upgraded sites?

Comment 20

[Kai Engert (:KaiE:)]

Johnathan, I think you said in comment 17 that you'd prefer to do (c) as proposed in 3. I'm fine with that idea, and I agree we'd need some additional wording to explain what happened.

This will mean that we need a new notification / status that PSM communicates to the host application (e.g. Firefox, SeaMonkey).

I propose to add a new status bit to nsIWebProgressListener, as we did before, when we introduced support for "EV".

I wonder, should we use a nsIWebProgressListener::bit specifically for CVE-2009-3555 saying "bad old server", or should we rather introduce a generic nsIWebProgressListener::bit that means "server uses potentially vulnerable security protocol and should get updated" in general?

Given that we might run out of bits at some point, I'd tend to do the latter (generic bit).

Comment 21

[Kai Engert (:KaiE:)]

It's great to hear we may have a string addition opportunity very soon.

I guess l10n would like to limit the number of strings to be added?

While bug 540332 proposes to add 19 strings, only 2 of them are related to this SSL negotiation problem, so we could limit it to those 2.

Of course, in addition to any Larry/error page enhancements desired.

Comment 22

[Axel Hecht [:Pike]]

Rules for lorentz include hacking up the patch so that it uses the added strings if possible, and falls back to not needing them. And of course, you gotta jump high to get on. Can we discuss taking this or not in public?

Comment 23

[Kai Engert (:KaiE:)]

(In reply to comment #22)
> Rules for lorentz include hacking up the patch so that it uses the added
> strings if possible, and falls back to not needing them. And of course, you
> gotta jump high to get on. Can we discuss taking this or not in public?

The SSL error page falls back to not needing them, it will still display a text presentation of the english error code identified.

Thanks for making us aware that code for Larry and page info would need to get done that way.

Regarding public, unless anyone has an argument to keep this private, I'm personally OK to open this bug up.

Comment 24

[Johnathan Nightingale [:johnath]]

(In reply to comment #19)
> > I do think that a pref to make this problem a hard stop, with an error page
> > that, at best, links to sumo articles, but offers no exception mechanism, is a
> > thing we should do immediately
> 
> We agree that we want this pref.
> I call it "security.ssl.require_safe_negotiation"
> For our first step: set to false (don't require).

Right - on this we are all agreed.

> > I think we'd want a different pref for
> > the broken ssl behaviour, too, so that we can talk about when to enable it
> > independently of getting the rest of this code reviewed
> 
> I'm not clear what you refer to when you talk about a second pref.
> 
> I think we agree to have a pref for the "block bad sites", as I described above
> in this comment.
> 
> I must speculate what second pref you'd like to see. Do you want a pref that
> controls whether or not we'll show an indicator for not-yet-upgraded sites?

Basically. In comment 17, I described an intermediate approach (before we block vulnerable servers completely) where we treat it as STATE_IS_BROKEN or equivalent - where we don't invent new indicators, but where we use the existing "broken SSL" indicator for a new thing (beyond its current use in mixed content scenarios).

If we agree on that approach, the pref I was describing was just a switch that would turn this on - security.ssl.treat_unsafe_renegotiation_as_broken or something less wordy. The purpose for this is that it would allow us to land the patch sooner, and make the decision about when to enable that behaviour independently of discussions about the quality of this patch or the localization impacts or anything else. We could land this code with no (default) behaviour change, and file a bug to flip the pref once we are confident it's the right trade between raising awareness/protecting users and breaking 100% of the time, quickly neutralizing the awareness/protection it might offer.

Does that make more sense?


(In reply to comment #22)
> Rules for lorentz include hacking up the patch so that it uses the added
> strings if possible, and falls back to not needing them. And of course, you
> gotta jump high to get on. Can we discuss taking this or not in public?

If Kai agrees, I think we can open this bug up - it's not a secret that renegotiation is broken, nor that we will want to respond. And it would be good to have more eyes involved.

Comment 25

[Kai Engert (:KaiE:)]

(In reply to comment #24)
> 
> "security.ssl.treat_unsafe_renegotiation_as_broken"
> Does that make more sense?

Got it, thanks.

The pref makes sense if we are able to land this code earlier than we want to start showing it.

Maybe "security.ssl.treat_unsafe_negotiation_as_broken" (because it's about properties of the initial negotiation (handshake), even when no re-negotiation has happened yet).

I'll do a new patch, but it will still take a bit more time before we can land anywhere, we're still waiting for the SSL implementation (and review) to get completed and 3.12.6 to be published.

Comment 26

[Kai Engert (:KaiE:)]

I'd like to start with ideas for text that could be shown in page info and/or Larry.

I'll prefix my proposals with the strings that we use today for broken security.

Ideally we shouldn't collapse the following into a single wording,
but have different wording for
  "potentially vulnerable, only" 
and
  "both mixed content and potentially vulnerable".

Because parts of the content may have been injected by the vulnerability, a statement about "without encryption" seems applicable to both new scenarios.

Because we've seen the twitter attack where account information was stolen, I conclude it's OK to say the new vulnerability doesn't prevent eavesdropping (even though all information exchanged between client and server can not be read by the MITM).

I'm wording carefully, because we don't know for sure whether the connection is actually vulnerable, it depends on server configuration. We only know it "might be vulnerable". I guess we shouldn't blame sites unnecessarily, to cool the down the heat from sites that did re-configure their sites to disallow renegotiation, and are not vulenerable, despite still using the old protocol.


All new strings are prefixed with *
No prefix for existing strings.


Proposals for Larry
===================
If "mixed, but not potentially vulnerable",
keep the existing:
    Your connection to this site is only partially encrypted, 
      and does not prevent eavesdropping.

If "both mixed and potentially vulnerable":
*   Your connection to this site uses a vulnerable protocol, 
*     and is only partially encrypted.
*   The connection does not prevent eavesdropping, 
*     and might not protect your login information.

If "all https, but potentially vulnerable":
*   Your connection to this site uses a vulnerable protocol, 
*     and might be only partially encrypted.
*   The connection might not prevent eavesdropping,
*     and might not protect your login information.


Proposals for page info
=======================
If "mixed, but not potentially vulnerable",
keep the existing:
    Connection Partially Encrypted
    Parts of the page you are viewing were not encrypted 
      before being transmitted over the Internet.
    Information sent over the Internet without encryption can
      be seen by other people while it is in transit.

If "both mixed and potentially vulnerable":
*   Connection Potentially Vulnerable and Partially Encrypted
*   This site uses an older protocol version and it's unknown whether the connection
*     is vulnerable to a manipulation attack and might not protect your login information.
    Parts of the page you are viewing were not encrypted 
      before being transmitted over the Internet.
    Information sent over the Internet without encryption can
      be seen by other people while it is in transit.

If "all https, but potentially vulnerable":
*   Connection Potentially Vulnerable and Potentially Partially Encrypted
*   This site uses an older protocol version and it's unknown whether the connection
*     is vulnerable to a manipulation attack and might not protect your login information.
*   Parts of the page you are viewing might not have been encrypted 
*     before being transmitted over the Internet.
    Information sent over the Internet without encryption can
      be seen by other people while it is in transit.


Let me illustrate the old and proposed new strings side by side, so we have a better impression how many
new strings we'll need and how different they might be from the existing ones.

The following strings are the same as above, simply re-grouped as they'd appear 
in the "language properties" file.


(strings in firefox/browser):
  Your connection to this site is only partially encrypted, and does not prevent eavesdropping.
* Your connection to this site uses a vulnerable protocol, and is only partially encrypted.
* Your connection to this site uses a vulnerable protocol, and might be only partially encrypted.
* The connection does not prevent eavesdropping, and might not protect your login information.
* The connection might not prevent eavesdropping, and might not protect your login information.

(strings in core/PSM):
  Connection Partially Encrypted
* Connection Potentially Vulnerable and Partially Encrypted
* Connection Potentially Vulnerable and Potentially Partially Encrypted
* This site uses an older protocol version and it's unknown whether the connection is vulnerable to a manipulation attack and might not protect your login information.
  Parts of the page you are viewing were not encrypted before being transmitted over the Internet.
* Parts of the page you are viewing might not have been encrypted before being transmitted over the Internet.


As Axel told us, we'd have to fall back to existing strings, if the new strings are not available.
In that case we'd always display the old text for all mixed security, regardless whether it includes the potential vulnerability or not.

Comment 27

[Nelson Bolyard (seldom reads bugmail)]

About the string issue:
Izzit possible to use a flashing bright red lock icon?  
The "broken lock" indicator *NEVER* gets my attention.

About the whole error page vs passive indicator issue, 
Have we EVER responded to a security flaw with a UI change that tells users 
that security is lost now, but in some number of weeks or months hence, security may be restored?  Imagine discovering a little sticker with a 
picture of a broken lock on the door of your safe deposit box in your bank
(do banks outside the USA have safe deposit boxes?) and upon asking about it,
being told "Oh, we discovered that for years the night time janitorial staff
has been able to open the vault and open any safe deposit box they want to,
so we wanted to let you know that we expect to have it fixed in a few months."

It feels like we're trying to coax users into taking a path of higher security.
Have we EVER done that before?  Has that EVER worked before?

Why are we responding to this security vulnerability so differently than to 
others?  This is arguably one of the most severe ever, and yet it is being 
"soft pedalled" (described and responded to as if it was not severe) by many 
vendors.  I object to soft pedalling the message of this vulnerability.

Comment 28

[Kai Engert (:KaiE:)]

Nelson, how would you do it?

Comment 29

[Honza Bambas (:mayhemer)]

Isn't this the right time to open this bug or start to discuss this issue in public?  Maybe largely public discussion would help to find the solution, probably raise this issue in dev-paltform or dev-tech-crypto, to avoid spam of this particular bug?

Comment 30

[Kai Engert (:KaiE:)]

Nobody vetoed against opening this bug, and we have 3 people agreeing to it, so opening.

Comment 31

[Kai Engert (:KaiE:)]

Attachment: Patch v4

Updated patch.

This patch does NOT yet change any UI (by default).

It has both prefs I had mentioned before.

It adds a new pref to globally allow renogitations to any bad sites (named as a temporary pref with the idea that it should go away.)

It adds a new pref, false by default, which users could manually switch to true. It enables the "after the fact" chrome indicator. It does so by showing the broken lock icon. It does not yet do any of the new strings. I believe this is an appropriate help us with testing. We can update the strings/page info/Larry later, when we switch the pref to "true" by default.

Comment 32

[Kai Engert (:KaiE:)]

The patch contains an unrelated chunk, which turns off TLS compression (security/manager/Makefile.in), please ignore (already reviewed in bug 527659).

Comment 33

[Kai Engert (:KaiE:)]

Attachment: Patch v5

Updated patch, minor fixes after self-review:

- removed the unrelated makefile change

- removed the incorrect "if (enabled)" from:

+  mPrefBranch->GetBoolPref("security.ssl.treat_unsafe_negotiation_as_broken", &enabled);
+  if (enabled) {
+    nsSSLIOLayerHelpers::setTreatUnsafeNegotiationAsBroken(enabled);
+  }

Comment 34

[Kai Engert (:KaiE:)]

Attachment: Patch v6 [checked in]

Added simple error console logging to the patch, as it had been suggested in the NSS meeting.

Right now this will spam the console a lot.

Comment 35

[Robert Relyea]

Comment on attachment 425477 [details] [diff] [review]
Patch v6 [checked in]

r+ rrelyea

Comment 36

[Eddy Nigg (StartCom)]

(In reply to comment #29)
> Isn't this the right time to open this bug or start to discuss this issue in
> public?

Just my advise is, don't push it too hard initially and make sure the most popular servers support the new extensions (and it works with your implementation). 

Further, the ones which need the most attention, are the web site operators, not the users. And they are jealously watching that all indicators are in place as expected, therefore once  this is ready for prime time, mixed content indicator (which it really isn't, but Johnath explained) seems to me the right approach.

Comment 37

[Kai Engert (:KaiE:)]

Checked in patch v6 together with the NSS 3.12.6 (beta)
http://hg.mozilla.org/mozilla-central/rev/88e27b100e45

Will keep bug open for the ongoing discussion and implementation of default UI.

Comment 38

[Nomis101]

Since today Thunderbird 3.2a1pre tells me:
> pop3.web.de : potentially vulnerable to CVE-2009-3555
I've never seen this before, so I guess this is an implication form this (and the NSS) checkin today. Is this a false positive warning or what does this mean? Or can I safely ignore this?

Comment 39

[Kai Engert (:KaiE:)]

(In reply to comment #38)
> Since today Thunderbird 3.2a1pre tells me:
> > pop3.web.de : potentially vulnerable to CVE-2009-3555
> I've never seen this before, so I guess this is an implication form this (and
> the NSS) checkin today. Is this a false positive warning or what does this
> mean? Or can I safely ignore this?


I wrote a wiki page to explain the current state and the prefs.
https://wiki.mozilla.org/Security:Renegotiation

If you'd like to comment on this or have questions regardind the explanation, please let's use the "talk" feature of the wiki.

Comment 40

[Wan-Teh Chang]

Comment on attachment 425477 [details] [diff] [review]
Patch v6 [checked in]

Kai, I'd like to suggest two changes to this patch.

In security/manager/ssl/src/nsNSSCallbacks.cpp, function HandshakeCallback,
you have:

>+  PRBool siteSupportsSafeRenego;
>+  if (SSL_HandshakeNegotiatedExtension(fd, ssl_renegotiation_info_xtn, &siteSupportsSafeRenego) != SECSuccess
>+      || !siteSupportsSafeRenego) {

This condition should be
    if (SSL_HandshakeNegotiatedExtension(...) == SECSuccess
        && !siteSupportsSafeRenego) {

because if SSL_HandshakeNegotiatedExtension fails, either secure renegotiation
is not applicable, or you don't know anything about its status.

>+      msg.Append(NS_LITERAL_STRING(" : potentially vulnerable to CVE-2009-3555"));

"CVE-2009-3555" is too obscure.  Please say "SSL renegotiation man-in-the-middle attacks".

Comment 41

[Michael Kraft [:morac]]

It would be nice if there was a way to suppress the warnings in the console or at least limit them to once per site.  Currently because every web site triggers these warnings, the console is filling up with them and pushing out errors and other things that I'm trying to look for.

Comment 42

[Ralf Hauser]

see also bug 554594

Comment 43

[Wan-Teh Chang]

Kai: the log message should say something neutral.  I suggest
"does not support the TLS renegotiation_info extension".

If console messages have logging levels, these messages should
be logged at the lowest, "informational" level today.

Comment 44

[John J. Barton]

(In reply to comment #37)
> Checked in patch v6 together with the NSS 3.12.6 (beta)
> http://hg.mozilla.org/mozilla-central/rev/88e27b100e45
> 
> Will keep bug open for the ongoing discussion and implementation of default UI.

My error console is now being bombarded by this message:
   .... potentially vulnerable to CVE-2009-3555

As a user this message has no value. I don't know what a CVE-2009-3555 is. There is no practical action I can take to avoid the message. I don't even see the message unless I am trying understand some problem with my browser, and then the message interferes with that process.

As a developer this message is a burden. It fills all of my error tracking windows and adds time overhead to every page load. It provides no value to me, there nothing I can do about this.

Please can we remove this nonsense? I'm sure the CVE thing is terribly important, but spamming everyone's error console is a completely inappropriate way to fix it. Please direct your communications to the person or persons who understand this CVE thing and are in a position to do something about it.

Comment 45

[Ben Bucksch (:BenB)]

wtc said:
> Kai: the log message should say something neutral.  I suggest
> "does not support the TLS renegotiation_info extension".

Agreed, I filed bug 549641 about that a while ago.

security.ssl.require_safe_negotiation = true looks nice, I immediately set it when I learned about it, and immediately resetted it again, because I couldn't even go to bugzilla. Probably versioncheck.mozilla.org also breaks, which makes this pref security-dangerous even. Bug 555952 is about fixing the mozilla.org sites, but I have a feeling that won't happen fast, because RFC 5647 support is probably simply not available.

Comment 46

[Kai Engert (:KaiE:)]

(In reply to comment #45)
> 
> Bug 555952 is about fixing the mozilla.org
> sites, but I have a feeling that won't happen fast, because RFC 5647 support is
> probably simply not available.

Not 5647, it's 5746

It's already available.

Today the availability of OpenSSL 1.0.0 got announced, which supports it.

Also, a couple of weeks ago the stable branch of OpenSSL got also updated to include support, it's included in 0.9.8m and later.

Servers that use NSS can use NSS 3.12.6 to get support.

Comment 47

[Ben Bucksch (:BenB)]

> It's already available.

Not for other software and hardware (SSL accelerators) that are in use.
If you have 200 million hits per day (e.g. versioncheck.mozilla.org or ebay), the situation looks a bit different.

Comment 48

[Eddy Nigg (StartCom)]

How many years from now do you expect 90% of all SSL enabled servers will support the new extension?

Comment 49

[Robert Relyea]

> security.ssl.require_safe_negotiation = true looks nice, I immediately set it
> when I learned about it, and immediately resetted it again, because I couldn't
> even go to bugzilla.

That's why it's not the default. There is a staged issue going on here, both clients and servers need to support the extension before full checking can be enabled. 

> Not for other software and hardware (SSL accelerators) that are in use.
> If you have 200 million hits per day (e.g. versioncheck.mozilla.org or ebay),
> the situation looks a bit different.

Depends on your hardware accelerator. Few accelerators take over the entire SSL stack. If you are running an accelerator under NSS, the NSS patch will be sufficient to add extension support without changing your hardware.

Patches for these products should be rolling out in the next couple of months. The open source products just happened to be able to get their patches out sooner than the rest. (Also, the open source products are often the upstream for the other hardware products:).

bob

Comment 50

[John J. Barton]

Perhaps you may appreciate my frustration better if I post the warning I see to this bug report?
addons.mozilla.org : potentially vulnerable to CVE-2009-3555
aus2.mozilla.org : potentially vulnerable to CVE-2009-3555

Comment 51

[Nelson Bolyard (seldom reads bugmail)]

John, I hope those warnings frustrate a LOT of people, to the point where
those servers get FIXED.  THAT's the right solution here, not ignoring the
security problem, or defeating the security notice.  

I will add that I think PSM should not give this notice more than once 
per server name per process lifetime.

Comment 52

[John J. Barton]

I (In reply to comment #51)
> John, I hope those warnings frustrate a LOT of people, to the point where
> those servers get FIXED.  

I don't own these servers and I cannot fix them.

> THAT's the right solution here, not ignoring the
> security problem, or defeating the security notice.

The right solution here is to contact the owners of theses servers and provide them with information on why this fix benefits them and how to make the fix. If you do not have the resources to do this, then seek those resources from the Mozilla Foundation, major Internet companies, international information technology societies, and so on. 

It is not appropriate to send your message of frustration about this problem of servers to every Web developer using Firefox.  The problem is not ours to solve. We did not create this problem and we cannot fix it.

Comment 53

[Eddy Nigg (StartCom)]

Additionally please see my comment at the dev.tech.crypto mailing list: http://groups.google.com/group/mozilla.dev.tech.crypto/msg/7da205284de93ed5

Implementing RFC 5746 at the client side provides sufficient protection.

Comment 54

[Daniel Veditz [:dveditz]]

> Implementing RFC 5746 at the client side provides sufficient protection.

The IETF TLS working group disagrees with you.

Comment 55

[Eddy Nigg (StartCom)]

Than it should be fairly easy to prove your stance with a practical demonstration of the attack. The example of Kai is by implementation a bug in itself and has not much to do with the renegotiation issue itself (which obviously should get fixed and this is what IETF has done).

Comment 56

[Michael Kraft [:morac]]

(In reply to comment #52)
> I (In reply to comment #51)
> > John, I hope those warnings frustrate a LOT of people, to the point where
> > those servers get FIXED.  
> 
> I don't own these servers and I cannot fix them.
> 

I agree 100% with this.  Spamming the error console with these messages does nothing to get the servers working.  The average Firefox user won't know what to do with them.  I'm certainly not going to send emails to the hundreds of web sites that show up in there.  Even if I did, I doubt the webmasters would listen to me.  If most web sites had already started upgrading, then maybe the warnings would be useful, but at this point they aren't.

Comment 57

[Eddy Nigg (StartCom)]

(In reply to comment #54)
> > Implementing RFC 5746 at the client side provides sufficient protection.
> 
> The IETF TLS working group disagrees with you.

X-Abuse-Me:
X-Description: I will ignore any content in Abuse-Me header
X-More-Description: I accept headers also after the body part has been sent
X-Conclusion: I'm vulnerable to user input and on transit

Comment 58

[Jean-Marc Desperrier]

(In reply to comment #50)
> Perhaps you may appreciate my frustration better if I post the warning I see to
> this bug report?
> addons.mozilla.org : potentially vulnerable to CVE-2009-3555
> aus2.mozilla.org : potentially vulnerable to CVE-2009-3555

There's bugg 555952 about updating those servers. It should be done soon.

Comment 59

[Jean-Marc Desperrier]

A reasonable middle ground would be to send an error to the error console only once per server and per session, instead of doing it for every request.

Would there be a way to do that filtering inside javascript ? Right now it's c++ that calls directly console->LogStringMessage so doing it properly with expiry handling would probably require quite a bit of code.

Comment 60

[Matt McCutchen]

FWIW, I've enabled security.ssl.treat_unsafe_negotiation_as_broken and am starting to kick my server admins, pointing them to this bug.  I definitely notice the absence of the blue badge on almost all the sites I use: a bit startling, but only a reflection of the truth.

Comment 61

[Matt McCutchen]

(In reply to comment #54)
> > Implementing RFC 5746 at the client side provides sufficient protection.
> 
> The IETF TLS working group disagrees with you.

See my analysis on the newsgroup:

https://groups.google.com/group/mozilla.dev.tech.crypto/msg/8a1d3f2eeeeeb6da

In short, at least some minor parts of Launchpad would be vulnerable if they didn't refuse client-initiated renegotiation.

Comment 62

[Matt McCutchen]

Attachment: Proposed yellow Larry button

I'd like to propose UI for the Larry button to go along with comment #26.  The Larry button should turn yellow and have the same text it would otherwise.  Compared to the gray button, this will be more noticeable and will not deprive users of identity information that is valid except for the renegotiation issue, potentially allowing us to turn on the new UI sooner.  Please see the attached mockup image I made by hacking the chrome jar files.

Comment 63

[Matt McCutchen]

Adding a better search term to the summary.

Comment 64

[Jonathan Watt [:jwatt]]

Setting security.ssl.treat_unsafe_negotiation_as_broken to true does not seem to produce a visual indication in ff4b7. Is this expected to change for the final release?

Comment 65

[:Gavin Sharp [email: [e-mail]]]

That pref works fine for me in a trunk build - https://www.mozilla.org/ is given the "broken ssl" treatment (due to bug 555952). Bugzilla doesn't, but presumably that's because the warning is produced by a linked image from www.mozilla.org, not from the bugzilla.mozilla.org connection itself. I don't know whether that's intentional, but if not then it should be filed separately.

Comment 66

[Kai Engert (:KaiE:)]

Regarding comment 64 and 65:

I partially can confirm both Johnathan's and Gavin's finding, but I think there's a need for clarification.

There is no longer a visual indication about broken security, because the Firefox UI was changed, and the padlock has been removed.

In the past, we had these states:
- no security (no padlock)
- attempted but broken security (broken padlock)
- validated security (padlock)

I realize there is no longer an indicator for "attempted but broken security".
This state is now being shown identically to "no security at all".

Gavin, when you say "broken ssl treatment", I believe you mean "missing security / identity indicator shown in url bar", because I couldn't see any indicator.


Regarding the effectiveness of the pref to remove SSL indicators, I can confirm it will works. Go paypal.com with security.ssl.treat_unsafe_negotiation_as_broken=true and you should see no identity indicator.

Comment 67

[Kai Engert (:KaiE:)]

Thanks to Johnathan Watt for recently working on the renegotiation topic and inspiring me to update page https://wiki.mozilla.org/Security:Renegotiation

I hope the new workding on the page is OK with you, if not, I'd appreciate your comments. (See the recent history)

In particular I've added stronger wording, that makes it more obvious why sites should upgrade, and what the risks are by not upgrading and claiming to have the renego feature disabled.


This brings me to a question regarding Firefox 4.

A while ago we had decided to introduce preference 
security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref
which we had set to "true" in Firefox 3.x versions for compatibility reasons.

For the development versions, we had chosen to use "false".


====> Question:
Is everyone OK to keep the default value "false" for Firefox 4 final release?


The value "false" means that, by default, we will break deployments that run old software and at the same time depend on renegotiations.
(The preferences described on the wiki page can be used to work around that default.)

Comment 68

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 66, ISTR there's a hidden FF pref that allows one to 
re-enable the lock in the status bar.  In fact, I'm sure I've used it, and 
continue to see a lock every day with FF 3.latest.  
Two questions:
1) Is that pref still going to work in FF4?  Will I still have the option to 
see the lock icon?
2) Will the lock icon show me something is wrong when I have that pref set??

Comment 69

[Kai Engert (:KaiE:)]

(In reply to comment #68)
> In reply to comment 66, ISTR there's a hidden FF pref that allows one to 
> re-enable the lock in the status bar.  In fact, I'm sure I've used it, and 
> continue to see a lock every day with FF 3.latest.  

I'm not aware of such a pref.

Comment 70

[Reed Loden [:reed]]

(In reply to comment #69)
> I'm not aware of such a pref.

There is no such pref. The lock icon is gone in Firefox 4.

Comment 71

[Jesse Ruderman]

Google Chrome's equivalent to Larry says "The server does not support the TLS renegotiation extension." (https://www.paypal.com/)

Chrome's more-info page (https://www.google.com/support/chrome/bin/answer.py?answer=95617&hl=en-US) is missing an explanation for this one.

Comment 72

[WADA:World Anti-bad-Duping Agency]

Adding some bugs to Blocks: field, because bug 545206 is already put.

Comment 73

[Anje]

Suddenly receiving error console messages
Thunderbird 12.0.1  OS Vista

www.mozilla.org : server does not support RFC 5746, see CVE-2009-3555
mail.btinternet.com : server does not support RFC 5746, see CVE-2009-3555

At exactly the same time, links in received messages do not open the default browser.
Timestamp: Tue 8/05/12 15:43:05
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIExternalProtocolService.loadUrl]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://communicator/content/contentAreaClick.js :: openLinkExternally :: line 188"  data: no]

Comment 74

[Kai Engert (:KaiE:)]

reassign bug owner.
mass-update-kaie-20120918

Comment 75

[Penny Lake]

Every minute I am getting this error message in the Error Console of Thunderbird 31.4.0
Error: pop.verizon.net : server does not support RFC 5746, see CVE-2009-3555

Timestamp: 1/16/2015, 2:52:28 PM
Error: pop.verizon.net : server does not support RFC 5746, see CVE-2009-3555

Timestamp: 1/16/2015, 2:53:26 PM
Error: pop.verizon.net : server does not support RFC 5746, see CVE-2009-3555

Timestamp: 1/16/2015, 2:54:28 PM
Error: pop.verizon.net : server does not support RFC 5746, see CVE-2009-3555

Timestamp: 1/16/2015, 2:55:28 PM
Error: pop.verizon.net : server does not support RFC 5746, see CVE-2009-3555

Timestamp: 1/16/2015, 2:56:30 PM
Error: pop.verizon.net : server does not support RFC 5746, see CVE-2009-3555

Timestamp: 1/16/2015, 2:57:27 PM
Error: pop.verizon.net : server does not support RFC 5746, see CVE-2009-3555


I looked up CVE-2009-3555 and was taken to this page (National Vulnerability Database) http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-355

For my pop.verizon.net account I am using Port: 995, Connection Security: SSL/TLS, Application Method: Normal password

Comment 76

[Penny Lake]

Attachment: error_message_every_1_minute.png

Attached a screen capture of the messages in the Error Console.

Comment 77

[Alexander Beaverhausen]

Since this vulnerability has reached it's fifth anniversary and there's still no warning that users are connecting to potentially vulnerable servers I'd like to propose a new solution.

Google is currently phasing out support for SHA1. They published the schedule with the requirements and "penalty" for not meeting those requirements. I like that idea since it gives websites a generous amount of time to adapt. Thinking about the bigger picture with this vulnerability and the BEAST and POODLE vulnerabilities I asked why are so many servers vulnerable when TLS 1.2 has been around for over six years. While TLS 1.2 isn't a silver bullet it's far better than SSL 3 and TLS 1.0.

I think the biggest issue in the past has been the chicken and the egg syndrome. The server admins don't want to implement features the browsers don't support and browser developers feel the same way. I think the burden must be placed on the browsers to drive updates since there are only four major browsers and countless server software and appliances that they connect to. Also, admins generally want to make access to servers available to as many people as possible which means minimally acceptable security.

To combat the secure negotiation issue, heartbleed, BEAST, POODLE, and ALL future issues the "padlock" indicator is no longer sufficient. I propose that it be replaced with a rating system like the Qualys SSL Server Test and that rating be displayed on or near the lock. Clicking on the lock/rating would show an explanation for the rating like in comment 26. Publish the requirements for each rating and the timeline on when the requirements will be increasing. I'd say that vulnerabilities like SHA1 and mixed content, or not using TLS 1.2 OCSP, Forward Secrecy, and Strict Transport Security (HSTS) should be given a grade no higher than B. Vulnerabilities like CVE-2009-3555 should be graded no higher than "D". As time goes on the grades will go down for those vulnerabilities to "F, click to override the security risks" and the higher grades will be for TLS 1.3 when released and better Cipher Suites. It also allows for a quick update to the rating system when new vulnerabilities are discovered.

If possible, I think it would be good if every connection to a secure server rated below A could have Firefox send an error/information message to the server with a link to the rating system. I notify websites of security vulnerabilities I find but I'm just one person and don't always get the attention of the decision makers.

Comment 78

[Jesse Ruderman]

Re the last comment, you might be interested in bug 711816, "Larry should include a checklist of optional security measures". A letter grade or score might be a reasonable way to summarize the info.

Comment 79

[Alexander Beaverhausen]

I inform webmasters every time I encounter a site that doesn't support safe negotiation. A few have upgraded but most haven't. Since I'm only one customer out of thousands or millions I doubt my email or support ticket makes it past level one support to reach the true decision makers.

With security.ssl.require_safe_negotiation set to true in FF 36 I now get the "Report this error" option for sites that don't support safe negotiation. I know that this was added to report certificate pinning issues but I think it's a great way to report the unsafe negotiation too and other issues too. 

If Mozilla contacted these sites about this security vulnerability I think they'd have much better luck at getting a response and getting the issue resolved. If Mozilla just setup and publicized a site to track these reports of vulnerable and weak security websites I think most sites would quickly resolve their issues. I think the fastest and easiest way that wouldn't involve Mozilla doing any communication with sites is if FF had a security rating system like I mentioned in comment 77. I think most websites would quickly resolve their issues and/or implement best practices to get an A+ rating if they saw that their site had a lower ranking.

Thanks Jesse! I'll checkout that bug.

Comment 80

[Daniel Veditz [:dveditz]]

So many users would be blocked from so many sites that changing the "require_safe_negotiation" is a non-starter for the general release. Changing the security.ssl.treat_unsafe_negotiation_as_broken pref to give people a warning triangle instead of a lock might be feasible at this point.

That won't really help folks like Penny in comment 75 because there's no lock display for mail servers which means not much incentive for mail server admins to use good security.

Comment 81

[Yuhong Bao]

Interestingly there are even TLS 1.2 servers that don't support secure renegotiation, and SChannel probably accounts for only a small minority of them since the original Server 2008 R2 RTM is now obsolete and TLS 1.2 was disabled by default back then anyway.

Comment 82

[Yuhong Bao]

Most of them have insecure renegotiation disabled I think but didn't bother to implement RFC 5746.

Comment 83

[Yuhong Bao]

IMO this is probably not worth spending much time on since TLS 1.3 will get rid of renegotiation anyway.

Comment 84

[ivanagui2]

Does "security.ssl.renego_unrestricted_hosts" and "security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref" work on Firefox 38?

Comment 85

[Yuhong Bao]

(In reply to ivanagui2 from comment #84)
> Does "security.ssl.renego_unrestricted_hosts" and
> "security.ssl.
> allow_unrestricted_renego_everywhere__temporarily_available_pref" work on
> Firefox 38?

No, see bug 1123020

Comment 86

[Dana Keeler (she/her) (use needinfo) [:keeler]]

This bug got out of hand, so I'm revising the summary to describe what it actually did and closing it. If there's any follow-up work to be done, it can be done in another bug.

Comment 87

[sjw]

I can't confirm this as fixed.
Even when security.ssl.treat_unsafe_negotiation_as_broken there is no such security warning or error in the Web Console (see e.g. on https://support.apple.com/).
This seems more likely to be a dupe of bug 883674 or bug 1122695 now.

Comment 88

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Not really a duplicate. Those bugs describe further work to improve this (e.g. right now I see warnings in the browser console (Ctrl+Shift+J) when visiting https://support.apple.com ).