Last Comment Bug 554594 - Alerts on CVE-2009-3555 TLS Renegotiation in Error Log
: Alerts on CVE-2009-3555 TLS Renegotiation in Error Log
Status: RESOLVED DUPLICATE of bug 549641
:
Product: Core
Classification: Components
Component: Security: PSM (show other bugs)
: unspecified
: x86 Windows Vista
: -- enhancement (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-24 02:42 PDT by Ralf Hauser
Modified: 2010-10-31 11:42 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Ralf Hauser 2010-03-24 02:42:53 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729)

on https://www.privasphere.com renegotiation is turned off on the server-side, but the error log as per https://wiki.mozilla.org/Security:Renegotiation 

Do we possibly need a "security.ssl.renego_restricted_hosts" for sites where the new protocol is not yet implemented, but the renegotiation server-side disabled?
Such that the error need no longer to be displayed

Reproducible: Always




see also https://bugzilla.redhat.com/show_bug.cgi?id=533125
Comment 1 zug_treno 2010-03-25 16:55:53 PDT
Related to/duplicate of Core bug 535649?
Comment 2 Ralf Hauser 2010-03-25 21:21:19 PDT
Reading the wiki again, it appears to me we need two client-side properties

1) security.ssl.treat_unsafe_renegotiation_as_broken
     default value: true

Since the old protocol is ok as long as we only do negotiation and not *re*negotiation, we only need to evangelize on old servers that really do renegotiate.

2) since security.ssl.require_safe_negotiation apparently already vetoes connection attempts and not renegotiation attempts, we will not want this.
If we want to be less strict than in 1), we should add a white-list approach security.ssl.treat_unsafe_renegotiation_as_broken_hosts where we could enter our e-banking hostnames, ...
Comment 3 Daniel Veditz [:dveditz] 2010-03-25 22:46:26 PDT
(In reply to comment #2)
> Since the old protocol is ok as long as we only do negotiation and not
> *re*negotiation

But there's no difference in the vulnerable protocol. There is no way for a client to know when it negotiates that the server isn't thinking it's a RE-negotiation due to a MITM. Twitter got hacked this way, before it turned off renegotiation on its servers. As you browse from web site to web site how in the world will you know which ones you can safely negotiate with? As you say there could theoretically be a list of known-good sites, but realistically users aren't going to maintain such a list and sites aren't going to advertise they've turned off renegotiation.

There's another bug suggesting we warn only once per site per session. That's a much more realistic solution to error console spew, but it's hard to justify the work when there are real bugs we could be working on. And ultimately we need all servers to start supporting the new protocol extension, and when they do that also solves the problem.
Comment 4 Daniel Veditz [:dveditz] 2010-03-25 22:49:30 PDT
The "false positive" in the summary isn't quite right. We are accurately positive that the server does not support the new renegotiation extension.
Comment 5 Ralf Hauser 2010-03-26 00:04:55 PDT
hhmmm, openssl has allowed to disable renegotiation, but keep legacy-negotiation; tomcat has it fixed along this way with a clever new option  "allowUnsafeLegacyRenegotiation" that can be set to false (https://issues.apache.org/bugzilla/show_bug.cgi?id=48236)

Why couldn't firefox do the same on the client side: Allow negotiation with the legacy protocol, but disallow the flawed renegotiation (at least for a some destination by a black- or white-list approach)?
Sure, the majority of users will not do, but similarly to adding certificate exceptions of self-signed certificates, firefox might assist them in building up a white-list of domains that did not yet either adopt the new protocol nor re-architect their server-side with the legacy protocol such that no renegotiation is needed. As soon as firefox detects that a site has adopted the new extension, it will drop the site from the white-list...

Also, is there a site that keeps track to the major server-side open source packages (openssl, Java JCE/JSSE, ...) that have adopted the new protocol extensions?
Comment 6 Daniel Veditz [:dveditz] 2010-03-27 15:45:07 PDT
(In reply to comment #5)
> hhmmm, openssl has allowed to disable renegotiation, but keep
> legacy-negotiation;

NSS can be set up that way too, and in fact that's how this landed in Minefield. But that broke a bunch of sites so we're not yet going to disable renegotiation. In any case, that helps on the server side (NSS runs on servers, too) but only disabling unsafe renegotiation on the client doesn't protect clients from the most likely attack.

> Why couldn't firefox do the same on the client side: Allow negotiation with
> the legacy protocol, but disallow the flawed renegotiation (at least for a
> some destination by a black- or white-list approach)?

I'm not understanding what's different from what we've implemented. I assume you've read the wiki page you referenced in comment 0. There are prefs where you can allow legacy negotiation or not (current firefox setting allows), a pref where you can disable legacy RE-negotiation (unsafe renegotiation disabled in Minefield, allowed in Firefox 3.6/3.5), and a pref where you can whitelist host to which you allow unsafe legacy renegotiation.

We need some UI for managing this in Minefield. Firefox 3.6 will likely have to stumble along as-is.

> Also, is there a site that keeps track to the major server-side open source
> packages (openssl, Java JCE/JSSE, ...) that have adopted the new protocol
> extensions?

Slightly out of date (both Firefox and Opera have released their implementations; I've mailed) but the situation is at least as good as:
http://www.phonefactor.com/sslgap/ssl-tls-authentication-patches
Comment 7 Christopher Schultz 2010-03-29 09:49:12 PDT
What is the means by which ff determines whether to flag a warning to the user? I can see, on our website, the message "[host] : potentially vulnerable to CVE-2009-3555" is posted to the error console, which could freak-out some of our customers.

We run on Debian Etch and our apache2 version is 2.2.3-4+etch11 which is allegedly fixed (http://security-tracker.debian.org/tracker/CVE-2009-3555) yet this warning is still presented to the user.

Is there something we can do on the server to convince ff that the site is safe? Or would this kind of thing require that ff have a database of server versions that are safe (which isn't practical).

I'm interested in how ff does its check... the Server response header we send is simply "Apache/2.2" (i.e. no point release version info), so is there information coming from the SSL negotiation that ff is using?
Comment 8 Kai Engert (:kaie) 2010-03-29 12:10:39 PDT
(In reply to comment #7)
> What is the means by which ff determines whether to flag a warning to the user?

RFC 5746

http://www.rfc-editor.org/rfc/rfc5746.txt

If the server does not implement RFC 5746, the client is unable to tell whether you're vulnerable or not, and you will get the warning.


> I can see, on our website, the message "[host] : potentially vulnerable to
> CVE-2009-3555" is posted to the error console, which could freak-out some of
> our customers.
> 
> We run on Debian Etch and our apache2 version is 2.2.3-4+etch11 which is
> allegedly fixed (http://security-tracker.debian.org/tracker/CVE-2009-3555) yet
> this warning is still presented to the user.

I think you need at least version openssl 0.9.8-m
(or openssl 1.0.0 beta 5)

See the changelog at http://www.openssl.org/news/changelog.html
Search for section heading
  Changes between 0.9.8l and 0.9.8m [25 Feb 2010]
Within that block search for RFC5746

I believe the earlier openssl 0.9.8-l may have had a hotfix to disable renegotiation on the server side, but that's not sufficient, because the browser doesn't know it's safe. We need support for RFC 5746 in order to know we're safe.


> Is there something we can do on the server to convince ff that the site is
> safe? Or would this kind of thing require that ff have a database of server
> versions that are safe (which isn't practical).

Can you update to openssl 0.9.8-m?

If you'd like to see a positive test, you can connect to https://kuix.de
That's my server, which is running openssl 1.0.0 beta 5


> I'm interested in how ff does its check... the Server response header we send
> is simply "Apache/2.2" (i.e. no point release version info), so is there
> information coming from the SSL negotiation that ff is using?

The Apache version is irrelevant for the warning.
The decision is being made in the SSL handshake, the channel that wraps the http protocol.
Comment 9 Kai Engert (:kaie) 2010-03-29 12:13:26 PDT
I'm removing the "false positive" from the bug description.
It's not a false positive.
(Unless you can point us to a server that does support RFC 5746 and we're still showing the message.)

The log message "potentially vulnerable" is correct from the browser point of view. The error is shown only for servers that don't support RFC 5746, and from the browser point of view it's unknown whether the connection is safe or vulnerable.
Comment 10 Kai Engert (:kaie) 2010-03-29 12:16:08 PDT
(In reply to comment #2)
> Reading the wiki again, it appears to me we need two client-side properties
> 
> 1) security.ssl.treat_unsafe_renegotiation_as_broken
>      default value: true
> 
> Since the old protocol is ok as long as we only do negotiation and not
> *re*negotiation, we only need to evangelize on old servers that really do
> renegotiate.

The old protocol is not ok. We're the browser. We don't know what the server does. If the server isn't fixed, connections are vulnerable, even if the browser never sees any renegotiation.

We need the world to upgrade their servers and support RFC 5746.
Comment 11 Eddy Nigg (StartCom) 2010-03-29 13:14:53 PDT
Is it really the browser's job to determine if a server is vulnerable to just about anything? I'm not aware that client software ever has done that. As long as no unsafe renegotiation happens, I believe it's not browser's tasks to decide.
Comment 12 Kai Engert (:kaie) 2010-03-29 14:02:44 PDT
(In reply to comment #11)
> Is it really the browser's job to determine if a server is vulnerable to just
> about anything? I'm not aware that client software ever has done that. As long
> as no unsafe renegotiation happens, I believe it's not browser's tasks to
> decide.

Your comment really surprises me.
Comment 13 Eddy Nigg (StartCom) 2010-03-29 14:21:52 PDT
Show me one example where the browser determines if a server is save or not...of course you have commonly supported algorithms etc., but beyond that? Maybe I'm missing something.
Comment 14 Kai Engert (:kaie) 2010-03-29 14:24:35 PDT
(In reply to comment #11)
> I'm not aware that client software ever has done that. As long
> as no unsafe renegotiation happens, I believe it's not browser's tasks to
> decide.


Eddy, do you understand the attack?

Using the renegotiation vulnerability, a MITM can inject content into an SSL connection and thereby abuse a user's credentials.

When this happens, the browser will not notice.
The browser will not know whether the attack happened.

The browser will NOT SEE the renegotiation.

Only the server will know about the renegotiation.

If the client does not know, whether the server allows renegotiation, the client does not know if the connection is vulnerable.

If the browser has a connection to a server without RFC 5746, there is a 50% chance the connection is vulnerable (renegotiation either enabled on server or disabled).

Given how hard we try to ensure a good protocol to the server (not using insecure v2),
given how hard we try to verify domain ownership (require a certificate that proves domain ownership from a trustworthy CA),
etc.,
I'd say we shouldn't ignore a 50% MITM risk that invalidates our other attempts.
Comment 15 Kai Engert (:kaie) 2010-03-29 14:35:26 PDT
(In reply to comment #13)
> Show me one example where the browser determines if a server is save or
> not...of course you have commonly supported algorithms etc., but beyond that?

one example: server offers to use encryption key of sizes 40 or 56 bits, only.

The browser can support 40 bits encryption (code is in NSS), but it doesn't allow it, because it has been declared "too weak".
Comment 16 Eddy Nigg (StartCom) 2010-03-29 15:22:42 PDT
(In reply to comment #14)
> Using the renegotiation vulnerability, a MITM can inject content into an SSL
> connection and thereby abuse a user's credentials.

Only to servers which

A) support renegotiation
B) have no other controls

and doesn't apply for servers which

C) don't support renegotiation
B) require client certificate authentication

> When this happens, the browser will not notice.

Which is however not the problem of the browser, but of the server. 

> The browser will not know whether the attack happened.

Which adverse affect would that have on the client? Isn't it the server which has to protect against that? 

> The browser will NOT SEE the renegotiation.

Exactly! And effectively the client is out of the game. Most important, NO data is seen by he MITM prior to any renegotiation attempt.

> Only the server will know about the renegotiation.

In case the server supports it. However you imply that a server which doesn't support the RFC 5746 extension is vulnerable to such an attack. This assumption is not correct.

> If the browser has a connection to a server without RFC 5746, there is a 50%
> chance the connection is vulnerable (renegotiation either enabled on server or
> disabled).

Thanks for confirming that. I don't know if it's 50%, but it's not 100%.

> I'd say we shouldn't ignore a 50% MITM risk that invalidates our other
> attempts.

I believe that it's not the browser which has to decide for the server side, only if a renegotiation attempt originates at the server (or other source), the client can decide that it doesn't want to play nice.
Comment 17 Eddy Nigg (StartCom) 2010-03-29 15:24:00 PDT
(In reply to comment #15)
> (In reply to comment #13)
> > Show me one example where the browser determines if a server is save or
> > not...of course you have commonly supported algorithms etc., but beyond that?
> 
> one example: server offers to use encryption key of sizes 40 or 56 bits, only.

As I said, beyond the supported algorithms.
Comment 18 Robert Relyea 2010-03-29 15:52:17 PDT
> As I said, beyond the supported algorithms.

At this point, non-RFC 5746 connections are roughly equivalent to allowing ssl2 connections. Unfortunately it will take some time for the servers to upgrade, but it is essential that servers do upgrade. Until they do, there is no way for clients to know if they are vulnerable or not. Refusing to renegotiate isn't sufficient (the attack can complete once the initial, from the clients point of view, handshake is complete).

This warning is important because some time in the future the client will refuse to connect (by default) to any non-RFC 5746. This is not just Firefox, but all the browsers. 

bob
Comment 19 Eddy Nigg (StartCom) 2010-03-29 16:08:44 PDT
(In reply to comment #18)
> Until they do, there is no way for
> clients to know if they are vulnerable or not.

Does the browser know if a server is vulnerable to cross-site-scripting attacks or SQL injections? Or just any other possible attack? If not, why not?

To reiterate, no data is compromised before any renegotiation was successfully completed, something which the client can control (and reject). The rest is not the browsers business. Otherwise the browser should start checking for many other and more common potential vulnerabilities at servers.

> This warning is important because some time in the future the client will
> refuse to connect (by default) to any non-RFC 5746.

But before that, we have to support a lot of clients which don't support RFC 5746. I don't want to get alerts and warnings for servers which are not vulnerable to such an attack and which don't support the new extension.
Comment 20 Kai Engert (:kaie) 2010-03-29 17:23:31 PDT
(In reply to comment #19)
> (In reply to comment #18)
> > Until they do, there is no way for
> > clients to know if they are vulnerable or not.
> 
> Does the browser know if a server is vulnerable to cross-site-scripting attacks
> or SQL injections? Or just any other possible attack? If not, why not?


Scenario (a):
I walk to my house, a person with wild hair approaches me and tells me "don't go into your house, it may collapse, I've had a vision!".

Scenario (b):
I walk to my house, and in front of the house there is a car labeled "construction engineering". A man with a hardhat approaches me and tells me "you shouldn't go into your house, because there has been a water line damage below your house and the fundament has weakened. There is a 50% chance the house will collapse in the next 24 hours."


You say, "why don't we warn about potential SQL injection attacks on the server"?

Because we have no knowledge about it. Warning about it would be like scenario A.

Why do Dan, Bob and I say, we should warn about servers not supporting RFC 5746? Because we already know something about the server, we're not speculating. We know it's not using a safe protocol. We know there is a risk for the user, because the user usually won't have talked to the server administrator and usually is at risk. It's more like scenario B. We feel that we should warn the user, because we KNOW there is a risk.

Eddy, let's say scenario B happened to your house. Would you appreciate being warned, or would you prefer to be left uninformed?
Comment 21 Kai Engert (:kaie) 2010-03-29 17:27:52 PDT
(In reply to comment #19)
> To reiterate, no data is compromised before any renegotiation was successfully
> completed, something which the client can control (and reject).

Wrong.

The client can neither control nor reject.

Nobody will ask the browser if a renegotiation occurs between MITM and server.

Nobody will tell the browser that a renegotiation occured between MITM and server.
Comment 23 Daniel Veditz [:dveditz] 2010-03-29 18:06:03 PDT
(In reply to comment #16)
> Which is however not the problem of the browser, but of the server. 

Our job as a browser--what we're promising when we show ssl indicia--is to get our user safely connected to the server they are trying to reach. Unless the server supports RFC 5746 we cannot guarantee that there was not a MITM (for example, the Twitter hack using this attack). Maybe the site has turned off renegotiation, maybe it hasn't. We don't know, so we issue a warning. Not an error, a warning, on an dialog most users don't even know exists.

Some time in the comming months we're not even going to show SSL indicia for such servers. Today Opera 10.5 won't show EV for servers that don't support rfc 5746. It's coming, patch your servers.

> I believe that it's not the browser which has to decide for the server side,

SSL is a two way communication, both sides have to agree it's a safe channel.

I'm certainly open to changing the wording on the current warning (of course I don't have the final say, it's Kai's module). Something strictly factual with no speculation, perhaps? "<site> does not support RFC 5746. see CVE-2009-3555"
Comment 24 Daniel Veditz [:dveditz] 2010-03-29 18:14:51 PDT
(In reply to comment #19)
> Does the browser know if a server is vulnerable to cross-site-scripting attacks
> or SQL injections? Or just any other possible attack? If not, why not?

We are, in fact, implementing features in the browser to help sites protect themselves against XSS and CSRF attacks (Content Security Policy and the Origin header). IE implemented X-Frame-Options to prevent sites from being framed against their will. The EcmaScript standard added the JSON object to help sites keep from screwing up by dangerously misparsing their AJAX stuff. Strict-Transport-Security gets users over to the SSL site they intended even if they forget and type http:// or the web coder forgets and leaves in an http://. Everywhere we can browsers and web sites are cooperating to protect our mutual users.
Comment 25 Eddy Nigg (StartCom) 2010-03-30 06:17:26 PDT
(In reply to comment #21)
> The client can neither control nor reject.

Of course the client can reject a renegotiation attempt. Renegotiation can be initiated from either side. The client can reject server side initiated attempts.

> Nobody will ask the browser if a renegotiation occurs between MITM and server.

True.

> Nobody will tell the browser that a renegotiation occured between MITM and
> server.

Correct, I still believe the server side is not the browser's business on something which potentially happens between a different party and the server.

Look, the server side needs to keep track and verify that only authorized clients access protected and other resources. You shouldn't solved that in the browser (IMO).

For example it's not the browsers job to verify if the credentials (for example client certificate) are legit, it's the server application job. My expectation is that each side has its own fields of responsibilities. It's probably a principal question.

For now lets agree that we disagree. :-)
Comment 26 Christopher Schultz 2010-03-30 06:54:56 PDT
Kai,
> If the server does not implement RFC 5746, the client is unable to tell whether
> you're vulnerable or not, and you will get the warning.
> 
> I think you need at least version openssl 0.9.8-m
> (or openssl 1.0.0 beta 5)

Okay, neither of those are really options for me, because I have chosen to allow Debian to manage these packages for me on our production servers: my openssl version is 0.9.8c-4etch9 which is nominally 0.9.8c plus (among others) a patch to disable SSL renegotiation.

> I believe the earlier openssl 0.9.8-l may have had a hotfix to disable
> renegotiation on the server side, but that's not sufficient, because the
> browser doesn't know it's safe. We need support for RFC 5746 in order to know
> we're safe.

I'm guessing this hotfix is what makes me "safe" although ff and other clients can't actually tell this is the case.

Thanks for the info.
Comment 27 Christopher Schultz 2010-03-30 06:57:00 PDT
Eddy,

(In reply to comment #13)
> Show me one example where the browser determines if a server is save or
> not...of course you have commonly supported algorithms etc., but beyond that?
> Maybe I'm missing something.

There /is/ what whole SSL root certificate chain thing. Does that count?
Comment 28 Kai Engert (:kaie) 2010-03-30 07:16:49 PDT
(In reply to comment #26)
> 
> I'm guessing this hotfix is what makes me "safe" although ff and other clients
> can't actually tell this is the case.

Correct, if you're using an SSL toolkit that disables all renegotiations by default, and haven't changed the configuration to allow it anyway.
Comment 29 Kai Engert (:kaie) 2010-03-30 07:17:08 PDT
(In reply to comment #25)
> (In reply to comment #21)
> > The client can neither control nor reject.
> 
> Of course the client can reject a renegotiation attempt. Renegotiation can be
> initiated from either side. The client can reject server side initiated
> attempts.

The client can not reject the renegotiation attempt that we are worried about.

The client can not reject a renegotiation between a MITM and a server, although as a result the client's credentials can be abused.


> > Nobody will ask the browser if a renegotiation occurs between MITM and server.
> 
> True.

I'm glad you acknowledge this.


> > Nobody will tell the browser that a renegotiation occured between MITM and
> > server.
> 
> Correct

I'm glad you acknowledge this.


> I still believe the server side is not the browser's business on
> something which potentially happens between a different party and the server.

I disagree.

It appears you say the browser shouldn't attempt to detect a MITM.

If you really think the browser shouldn't try to detect the presence of a MITM, then please explain to me, what's the purpose of having the browser verify a server certificate?

If you really think the browser shouldn't try to detect the presence of a MITM, then please explain to me, what's the purpose to have the browser reject the use of an insecure protocol like SSL v2?

Eddy, as a test, I've disabled SSL v3 and TLS v1 in my browser, and enabled SSL v2, only. I've attempted to connect to https://www.startcom.org/ using the SSL v2 protocol. It didn't work, your server doesn't allow the use of SSL v2. 

Why don't you allow your server to talk to old SSL v2 clients?

I conclude you also think that it's necessary that the channel between server and client uses an appropriately modern SSL protocol.
I conclude you believe it's the server's business to worry about the protocols used in the connection to the browser.

However, you argue the browser shouldn't worry about the protocol used in the connection to a server?


> Look, the server side needs to keep track and verify that only authorized
> clients access protected and other resources. You shouldn't solved that in the
> browser (IMO).

You say the server is responsible for access control to server resources.
Sure, but I don't see how this relates to our discussion.

First there is establishment of a secure channel (ensure the user's data is secure and can't be captured or abused by a MITM using known attack vectors), *afterwards* the server may limit access to resources as it considers appropriate.

You claim the server needs the right to control whom it may give access to its resources.
That's an easy claim to make from the point of view of an https server, because the client speaks first, the server responds.

The https protocol requires the client to speak first, to send out it's credentials in the hope it's going to the intended party, only, and can't be abused by a MITM.
If you demand control over your server resources, you should grant the same right to the browser user's resources, which is the browser user's credentials, and acknowledge it's the browser's responsibility to help protect the user's credentials, by avoiding communication channels with known attack vectors.


> For example it's not the browsers job to verify if the credentials (for example
> client certificate) are legit, it's the server application job.

Of course, the server verifies the client credentials, and the client verifies the server credentials (the server certificate). Why does the client does that? Because the client wants to ensure the client is really talking to his bank, not talking to a MITM. Ensure that the user's credentials can't be abused by a MITM who inserts a rogue request into the channel.


> My expectation
> is that each side has its own fields of responsibilities.

Exactly. That's why the browser verifies the channel appears to be secure and uses an appropriate protocol.
Comment 30 Eddy Nigg (StartCom) 2010-03-30 12:22:55 PDT
(In reply to comment #29)
> The client can not reject a renegotiation between a MITM and a server, although
> as a result the client's credentials can be abused.

This is the thing I find problematic and over-hyped about this whole issue. HOW should the client's credentials become abused if the client doesn't support (unsafe) renegotiation?

> If you really think the browser shouldn't try to detect the presence of a MITM,
> then please explain to me, what's the purpose of having the browser verify a
> server certificate?

However the browser can not detect anything which doesn't involve the browser. You confirmed that.

> If you really think the browser shouldn't try to detect the presence of a MITM,
> then please explain to me, what's the purpose to have the browser reject the
> use of an insecure protocol like SSL v2?

So why don't you propose to simply reject unsafe renegotiation and instead attempt to impose a protocol which most likely will not be supported by more than 90% of the SSL enabled web servers for the next few years to come?

As you mentioned, you can't detect if a server supports renegotiation or not, so why attempt it?

> I conclude you believe it's the server's business to worry about the protocols
> used in the connection to the browser.

Sure.

> However, you argue the browser shouldn't worry about the protocol used in the
> connection to a server?

That's not what I said. I propose that the browser should only support safe renegotiation (if at all) and reject others.

> You say the server is responsible for access control to server resources.
> Sure, but I don't see how this relates to our discussion.

Server applications have scores of opportunities to fail on that. This is just another one, isn't it? This is really an application layer thing.

> The https protocol requires the client to speak first, to send out it's
> credentials in the hope it's going to the intended party, only, and can't be
> abused by a MITM.

Right - and renegotiation doesn't happen at this stage.

> If you demand control over your server resources, you should grant the same
> right to the browser user's resources, which is the browser user's credentials,
> and acknowledge it's the browser's responsibility to help protect the user's
> credentials, by avoiding communication channels with known attack vectors.

That's fine. Reject unsafe renegotiation and prevent the users credentials.

> Because the client wants to ensure the client is really talking to his bank,
> not talking to a MITM. Ensure that the user's credentials can't be abused by a
> MITM who inserts a rogue request into the channel.

Excellent, do that. Reject unsafe renegotiation and prevent the users credentials.

> Exactly. That's why the browser verifies the channel appears to be secure and
> uses an appropriate protocol.

Fine. Clients and servers that don't perform renegotiation are secure and use an appropriate protocol. Support only safe renegotiation if necessary.
Comment 31 Eddy Nigg (StartCom) 2010-03-30 12:26:11 PDT
s/prevent/protect/
Comment 32 Kai Engert (:kaie) 2010-03-30 12:43:14 PDT
Eddy, there's only one way for the browser to ensure there will be no unsafe renegotiations on the channel between the browser and the server, it's to set 

 security.ssl.require_safe_negotiation = true

as explained in
https://wiki.mozilla.org/Security:Renegotiation

Is this what you're trying to convince us to do?

Eddy, could you please summarize in one or two sentences what we should do in your opinion?
Comment 33 Eddy Nigg (StartCom) 2010-03-30 12:53:15 PDT
Daniel, Kai, 

It's just a short while ago that SSLv2 has been disabled in FF by default. Preceding that were more than a decade of the introduction of better protocols and support by 99.99% of the servers for these better protocols.

Opera has always been a bit extreme and I suspect you don't want to switch position with them. If your statement is correct, than they effectively disabled 99% of all EV web sites. For no apparent benefit.

The Twitter attack only worked because both clients and servers supported renegotiation and their application didn't have any other controls in place to protect the sessions. With a client that supports only safe renegotiation or none at all, this attack would have failed. Food for thought!
Comment 34 Eddy Nigg (StartCom) 2010-03-30 12:56:03 PDT
(In reply to comment #32)
> Eddy, could you please summarize in one or two sentences what we should do in
> your opinion?

Support only safe renegotiation. But don't warn on servers that don't support it, don't try to detect.
Comment 35 Kai Engert (:kaie) 2010-03-30 12:59:17 PDT
(In reply to comment #34)
> 
> Support only safe renegotiation.

Eddy, in your opinion, what mechanism should the browser use to achieve this?
Comment 36 Eddy Nigg (StartCom) 2010-03-30 13:06:42 PDT
(In reply to comment #35)
> (In reply to comment #34)
> > 
> > Support only safe renegotiation.
> 
> Eddy, in your opinion, what mechanism should the browser use to achieve this?

Disable support for any other renegotiation?
Comment 37 Kai Engert (:kaie) 2010-03-30 13:12:00 PDT
(In reply to comment #36)
> > 
> > Eddy, in your opinion, what mechanism should the browser use to achieve this?
> 
> Disable support for any other renegotiation?

How?
Comment 38 Eddy Nigg (StartCom) 2010-03-30 13:16:37 PDT
Do you want a patch or what? :-)

I'm not sure if security.ssl.require_safe_negotiation = true does that, it might be. You'll tell.
Comment 39 Kai Engert (:kaie) 2010-03-30 13:28:59 PDT
(In reply to comment #38)
> Do you want a patch or what? :-)

As you don't like what we've proposed, I would like to hear a constructive explanation of what you're proposing and how it would work technically.


> I'm not sure if security.ssl.require_safe_negotiation = true does that, it
> might be. You'll tell.

I've explained it on this page:
https://wiki.mozilla.org/Security:Renegotiation
Comment 40 Robert Relyea 2010-03-30 13:41:57 PDT
Hi Eddy,

> Disable support for any other renegotiation?

This is not sufficient. The client does not have to renegotiate to be attacked, it only needs to negotiate. The attacker can force a server that in all other ways looks benign to renegotiate. The only way for the client to be safe is to check the flag.

This semantic has been worked out and discussed thoroughly in the ietf and among the various browser vendors. The question isn't if the browsers will ever require_safe_negotiation, the question is only when. If you have a server, your best move is to upgrade it as soon as possible.

NOTE: this is exactly what the RFC requires.

The warning is a courtesy reminder that this change is coming. Over time that warning will get more and more insistent.

bob
Comment 41 Eddy Nigg (StartCom) 2010-03-30 13:46:34 PDT
Reading your explanation of ssl.require_safe_negotiation this is certainly not something I'd like to support (and actually my opposition). In particular:

If set to true, a Mozilla client will reject all connection attempts to servers that are still using the old SSL/TLS protocol and which might be vulnerable to the attack.

I would support rejecting all unsafe renegotiation attempts to the client.
Comment 42 Eddy Nigg (StartCom) 2010-03-30 13:57:03 PDT
(In reply to comment #40)
> The attacker can force a server that in all other
> ways looks benign to renegotiate.

Correct.

> The only way for the client to be safe is to check the flag.

No, the client can reject renegotiation in order to prevent an attack (on its credentials).

> This semantic has been worked out and discussed thoroughly in the ietf and
> among the various browser vendors. The question isn't if the browsers will ever
> require_safe_negotiation, the question is only when.

Alright.

> If you have a server, your best move is to upgrade it as soon as possible.

Don't worry about my servers. But what are your expectations? When will 90% of all SSL enabled server support the new extension? When will 99% support it?

Or do you intend to break more than 10% of SSL enabled web sites because they don't support the new extension?
Comment 43 Kai Engert (:kaie) 2010-03-30 14:03:02 PDT
(In reply to comment #42)
> 
> > The only way for the client to be safe is to check the flag.
> 
> No, the client can reject renegotiation in order to prevent an attack (on its
> credentials).


Eddy, I'm sorry, you're wrong.
Comment 44 Kai Engert (:kaie) 2010-03-30 14:06:39 PDT
(In reply to comment #43)
> (In reply to comment #42)
> > 
> > > The only way for the client to be safe is to check the flag.
> > 
> > No, the client can reject renegotiation in order to prevent an attack (on its
> > credentials).
> 
> 
> Eddy, I'm sorry, you're wrong.


If you disagree with this, then please ask yourself, without RFC 5746, how exactly (who sends what), at what point of the data exchange (timing) will the client have the possibility to reject a renegotiation between the MITM and the server?
Comment 45 Kai Engert (:kaie) 2010-03-30 14:12:30 PDT
(In reply to comment #42)
> Don't worry about my servers. But what are your expectations? When will 90% of
> all SSL enabled server support the new extension? When will 99% support it?

If everyone who is bothered about the error console log message kicks their server admins, it will be sooner.
Comment 46 Robert Relyea 2010-03-30 14:21:50 PDT
> > The only way for the client to be safe is to check the flag.

> No, the client can reject renegotiation in order to prevent an attack (on its
> credentials).

This is completely false. The client never sees the renegotiation. For the client the entire negotiation was an initial SSL negotiation. A client that never renegotiates is still completely vulnerable. For client auth, once the client clicks 'finish' that attack is complete.

> Don't worry about my servers. But what are your expectations? When will 90% of
> all SSL enabled server support the new extension? When will 99% support it?

That's a market decision of the various browsers. Most likely it will be stages (massive warnings in the early stages before complete renegotiation. What you are seeing is stage 1....

bob
Comment 47 Christopher Schultz 2010-03-30 14:32:29 PDT
Eddy, it sounds like you think the MITM is you. It's not: its someone else impersonating you. In this case, the client is the MITM, not you. The MITM (client) can re-negotiate with the server and you're fooked.

Let me repeat something Robert said quite simply:

"The client does not have to renegotiate to be attacked, it only needs to negotiate."

ff is simply issuing a warning during negotiation that the server could be attacked and that you could be the victim.
Comment 48 Eddy Nigg (StartCom) 2010-03-30 14:40:29 PDT
(In reply to comment #47)
> Eddy, it sounds like you think the MITM is you.

Nonono....give me a couple of hours, I'll try to do better and come back to you all.

> ff is simply issuing a warning during negotiation that the server could be
> attacked and that you could be the victim.

That's not my understanding. The proposal is that a Mozilla client will reject *all* connection attempts to servers that are still using the old SSL/TLS protocol and which might be vulnerable to the attack.
Comment 49 Daniel Veditz [:dveditz] 2010-03-31 03:09:44 PDT
(In reply to comment #48)
> That's not my understanding. The proposal is that a Mozilla client will reject
> *all* connection attempts to servers that are still using the old SSL/TLS
> protocol and which might be vulnerable to the attack.

Eventually, yes. Likely not ever in Firefox 3.6 (though we might get to the "show a broken lock" stage). That's not what this bug is about, though, this bug is about the wording of the warning on the error console. I suppose that could be extended to be about whether to warn or not, but it seems unfair to stop talking to people's servers if we haven't given fair warning first.

This discussion/policy debate going on here (which has not been about the wording of the warning for dozens of comments) belongs in a public newsgroup. Probably mozilla.dev.security, or maybe mozilla.dev.platform or at a stretch mozilla.dev.planning if you want a broader audience.
Comment 50 Daniel Veditz [:dveditz] 2010-03-31 03:13:19 PDT

*** This bug has been marked as a duplicate of bug 549641 ***
Comment 51 Eddy Nigg (StartCom) 2010-03-31 04:52:16 PDT
(In reply to comment #46)
> This is completely false. The client never sees the renegotiation.

Of course in case the attacker only induces renegotiation at the server, the client doesn't see anything. But in this case NO credentials nor any other data is leaked from the client. In which case the attack is entirely useless.

> A client that
> never renegotiates is still completely vulnerable. For client auth, once the
> client clicks 'finish' that attack is complete.

I didn't propose the client keeps supporting unsafe renegotiation. The opposite.

> That's a market decision of the various browsers. Most likely it will be stages
> (massive warnings in the early stages before complete renegotiation. What you
> are seeing is stage 1....

Experience has show that it will take a looong time until this will be possible. I'll take the discussion now to the news group. Thanks all.
Comment 52 Kai Engert (:kaie) 2010-03-31 06:22:42 PDT
(In reply to comment #51)
> 
> Of course in case the attacker only induces renegotiation at the server, the
> client doesn't see anything. But in this case NO credentials nor any other data
> is leaked from the client. In which case the attack is entirely useless.


The user's credentials can be abused to execute an arbitrary request on the target server, as it has been explained in the original announcement of the renegotiation attack.


> > A client that
> > never renegotiates is still completely vulnerable. For client auth, once the
> > client clicks 'finish' that attack is complete.
> 
> I didn't propose the client keeps supporting unsafe renegotiation. The
> opposite.


Here is the error in your thinking:

You think the client can disable unsafe renegotiation on its own, by a feature only present in the client.

But the browser can't do that, it's not possible.

Only if it talks to a supporting server, the client will know that the risk of unsafe renegotiations between MITM and the server has been eliminated.
Comment 53 Eddy Nigg (StartCom) 2010-03-31 06:35:01 PDT
(In reply to comment #52)
> The user's credentials can be abused to execute an arbitrary request on the
> target server, as it has been explained in the original announcement of the
> renegotiation attack.

Not without having knowledge of the clients credentials. This happens on the application layer, not at the secure socket layer.

> Here is the error in your thinking:
> 
> You think the client can disable unsafe renegotiation on its own, by a feature
> only present in the client.

If the client doesn't support unsafe renegotiation, the only attack possible is on the server. Which is useless without having compromised the clients data (session cookie for example).

I believe that you are looking only at the socket layer, which however is not a practical attack. So what if an attacker speaks to the server instead of a client if the attacker can't provide the credentials necessary and doesn't act as an MITM (because the client doesn't support old-fashioned renegotiation). Anybody can speak to the server, renegotiated or not, it's not a compromise in itself.
Comment 54 Kai Engert (:kaie) 2010-03-31 07:06:56 PDT
(In reply to comment #53)
> (In reply to comment #52)
> > The user's credentials can be abused to execute an arbitrary request on the
> > target server, as it has been explained in the original announcement of the
> > renegotiation attack.
> 
> Not without having knowledge of the clients credentials. This happens on the
> application layer, not at the secure socket layer.


Your assumption (that the attacker needs to know the client credentials in order to cause harm) is wrong, from my point of view, and I believe this is the view of Bob Relyea, Dan Veditz and other's, too.

Eddy, I think it's not constructive that we alternating say "I'm right, you're wrong".

If you believe, an attacker must know the credentials (unencrypted) in order to execute an attack using the credentials, I propose you try to prove it.

You could look at the documents where CVE-2009-3555 is explained in detail, which currently state that it's NOT necessary for the attacker to know the credentials (they state that forwarding the encrypted credentials is sufficient).

I propose you produce a technical explanation, that points the errors in the description of CVE-2009-3555 which, in your opinion, everyone else has interpreted incorrectly.

I propose to stop adding comments to this bug regarding the feasibility of the attack, until you have a prove that the existing attack descriptions are wrong.

Note You need to log in before you can comment on or make changes to this bug.