Alerts on TLS Renegotiation
Eddy Nigg
After some discussion at bug 554594 I'm following up here - the bug was unfortunately misused by me a little for the initial discussion.
At https://wiki.mozilla.org/Security:Renegotiation under item 4.4 the following is proposed:
security.ssl.require_safe_negotiation
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 believe this to be a mistake for various reasons, but first and foremost because an attack on a server without compromise of the client data as well, is basically useless. When a attacker induces renegotiation at the server, the attacker must have client credentials in order to act as if he were the original client. Without those credentials, the attacker would be treated as any other unauthenticated source.
When a client (as in our case Firefox) implements RFC 5746, the client can't be compromised and no data is leaked from the client. I propose that Firefox should support the RFC 5746 extension exclusively, but NOT block or warn on accessing servers which don't support the extension. Any renegotiation attempt to the client will be ignored and no data is leaked.
The advantage for this approach would be earlier support of RFC 5746 which would facilitate safe renegotiation with servers that support it, but still allows to support servers which don't support it.
SSLv2 was disabled in Firefox only a short while ago, despite the fact that newer protocols were available for most of the last 14 years. I expect that it will take years upon years until 90% of all SSL enabled servers will support RFC 5746, not speaking about 99% or higher. Refusing to speak to servers that don't support RFC 5746 - even if the sites probably never need renegotiation - will have an undesired effect, either by breaking SSL entirely or forcing the user to accept unsafe renegotiation, which will leave the user vulnerable once again.
It also must be noted that 99% or more of all SSL enabled web sites will never need renegotiation to work. A server which disabled renegotiation is at least as secure as a server supporting the new extension. Those that need it will probably patch their servers sooner or later and are not a concern IMO.
-- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP: star...@startcom.org Blog: http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg
Kai Engert
> [ Please follow up to mozilla.dev.tech.crypto ]
>
> After some discussion at bug 554594 I'm following up here - the bug was
> unfortunately misused by me a little for the initial discussion.
>
> At https://wiki.mozilla.org/Security:Renegotiation under item 4.4 the
> following is proposed:
>
>
> security.ssl.require_safe_negotiation
>
> attempts to servers that are still using the old SSL/TLS protocol
> and which might be vulnerable to the attack.
>
>
> I believe this to be a mistake for various reasons, but first and
> foremost because an attack on a server without compromise of the client
> data as well, is basically useless. When a attacker induces
> renegotiation at the server, the attacker must have client credentials
> in order to act as if he were the original client. Without those
> credentials, the attacker would be treated as any other unauthenticated
> source.
The attack that made it necessary to develop RFC 5746 is difficult to
understand.
The attacker doesn't need to know the credentials of the user.
It's sufficient that the user's credentials will be sent by the client,
after the renegotiation between MITM and server happened.
The client will see it as an initial negotiation, it will encrypt the
data, readable for the server only, not readable by the attacker. The
attacker will pass through all unreadable encrypted data.
On the server side, a request from the attacker will be combined with
the credentials sent by the client.
It's explained here:
http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html
I'm quoting the relevant example from above document:
====== snip quote begin ======
E.g., the attacker would send:
GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
X-Ignore-This:
And leave the last line empty without a carriage return line feed. Then
when the client makes his own request
GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1
Cookie: victimscookie
the two requests get glued together into:
GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1
Cookie: victimscookie
And the server uses the victim's account to send a pizza to the attacker.
======= snip quote end =======
> When a client (as in our case Firefox) implements RFC 5746, the client
> can't be compromised and no data is leaked from the client. I propose
> that Firefox should support the RFC 5746 extension exclusively, but NOT
> block or warn on accessing servers which don't support the extension.
It doesn't help if the client is the only side supporting RFC 5746.
Imagine the transition from USB 2.0 to USB 3.0, where the plug remains
compatible, but the inner parts of the USB 3.0 plug introduces new
connectors.
If the client uses USB 3.0 and supports additional information, but the
server still uses the older USB 2.0 plug, it won't help anyone. The data
designed to be exchanged using the new USB 3.0 connectors can't flow.
In other words, the parties are unable to exchange information that
would help them to discover that a renegotiation from an unrelated party
(a MITM) was requested.
RFC 5746 requires a communication channel where both parties can speak
the protocol.
> Any renegotiation attempt to the client will be ignored and no data is
> leaked.
Even if the client rejects all incoming requests for renegotiation, the
client has already sent out its credentials as part of a HTTP/SSL
request. Yes, the credentials are not being directly leaked to the
attacker, but that's not necessary.
The credentials will be combined with an arbitrary request chosen by the
attacker, as illustrated above.
Effectively, the attacker can execute a request on behalf of the user,
without needing to know the user's credentials.
Kai
johnjbarton
> [ Please follow up to mozilla.dev.tech.crypto ]
>
> After some discussion at bug 554594 I'm following up here - the bug was
> unfortunately misused by me a little for the initial discussion.
Closely related to bug 554594 is
https://bugzilla.mozilla.org/show_bug.cgi?id=535649
Web developers using Firefox Error Console or tools like Firebug that
use nsIConsoleService are now bombarded with pointless messages like:
services.addons.mozilla.org : potentially vulnerable to CVE-2009-3555
I'm sure the person who put the code in to emit this message thought it
was important. They probably did not realize that developers have to use
the Error Console and console service all day, every day and these
messages are a burden.
Readers of this message are not in a position to prevent the message. It
is not appropriate to write such a message into the error console. Even
if you think it's just the most important bit of technology news you can
imagine, please direct your message to the people who can actually do
something about it.
Thanks,
jjb
Eddy Nigg
> ====== snip quote begin ======
> E.g., the attacker would send:
>
> GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
> X-Ignore-This:
>
> ======= snip quote end =======
This attack is highly theoretical beyond believe, specially the
X-Ignore-This-and-That headers. Is has no real and practical value
whatsoever. Here some interesting observations and opinion by others:
http://blogs.technet.com/srd/archive/2010/02/09/details-on-the-new-tls-advisory.aspx
>> Any renegotiation attempt to the client will be ignored and no data is
>> leaked.
>
> Even if the client rejects all incoming requests for renegotiation,
> the client has already sent out its credentials as part of a HTTP/SSL
> request. Yes, the credentials are not being directly leaked to the
> attacker, but that's not necessary.
Of course this is necessary and the twitter attack worked exactly and
only because data was leaked from the client. Basically if the client
doesn't leak any data (which it shouldn't when implementing RFC 5746,
the attack is not possible (except for very bad coding of the
application layer, but that doesn't count)
> The credentials will be combined with an arbitrary request chosen by
> the attacker, as illustrated above.
If that attack works, no renegotiation would be necessary, such a site
would be vulnerable by simpler means and would work probably in any case.
> Effectively, the attacker can execute a request on behalf of the user,
> without needing to know the user's credentials.
Your assumptions are wrong and the whole thing is over-hyped as I
mentioned in the bug.
Eddy Nigg
> On 03/31/2010 04:45 PM, Kai Engert:
>> ====== snip quote begin ======
>> E.g., the attacker would send:
>>
>> GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
>> X-Ignore-This:
>>
>> And the server uses the victim's account to send a pizza to the
>> attacker.
>> ======= snip quote end =======
>
> This attack is highly theoretical beyond believe, specially the
> X-Ignore-This-and-That headers. Is has no real and practical value
> whatsoever. Here some interesting observations and opinion by others:
> http://blogs.technet.com/srd/archive/2010/02/09/details-on-the-new-tls-advisory.aspx
>
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
Robert Relyea
[ Please follow up to mozilla.dev.tech.crypto ]
After some discussion at bug 554594 I'm following up here - the bug was unfortunately misused by me a little for the initial discussion.
At https://wiki.mozilla.org/Security:Renegotiation under item 4.4 the following is proposed:
security.ssl.require_safe_negotiation
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.
Nutshell. SSL/TLS without RFC 5746 is effectively dead. The renegotiation bug is a bug in the underlying protocol. This means the protocol needs to be patched. Everywhere.
The RFC 5746 specifically states that the client must reject the connection if the extension is not present. This clause is 'watered-down' a bit because the reality is it will take time for servers to get updated. This option is for the ultra-paranoid. At some point in time it will be reasonable to turn it on. At another point in time it will be a default. Note that today it defaults to OFF.
I believe this to be a mistake for various reasons, but first and foremost because an attack on a server without compromise of the client data as well, is basically useless. When a attacker induces renegotiation at the server, the attacker must have client credentials in order to act as if he were the original client. Without those credentials, the attacker would be treated as any other unauthenticated source.
When a client (as in our case Firefox) implements RFC 5746, the client can't be compromised and no data is leaked from the client. I propose that Firefox should support the RFC 5746 extension exclusively, but NOT block or warn on accessing servers which don't support the extension. Any renegotiation attempt to the client will be ignored and no data is leaked.
The only benefit clients have in installing RFC5746 is that servers that require renegotiation and install the update to provide safe renegotiation from the server stand point.
The advantage for this approach would be earlier support of RFC 5746 which would facilitate safe renegotiation with servers that support it, but still allows to support servers which don't support it.
SSLv2 was disabled in Firefox only a short while ago, despite the fact that newer protocols were available for most of the last 14 years. I expect that it will take years upon years until 90% of all SSL enabled servers will support RFC 5746, not speaking about 99% or higher. Refusing to speak to servers that don't support RFC 5746 - even if the sites probably never need renegotiation - will have an undesired effect, either by breaking SSL entirely or forcing the user to accept unsafe renegotiation, which will leave the user vulnerable once again.
It also must be noted that 99% or more of all SSL enabled web sites will never need renegotiation to work. A server which disabled renegotiation is at least as secure as a server supporting the new extension. Those that need it will probably patch their servers sooner or later and are not a concern IMO.
We know there are backwaters of conservative people who don't update their servers. There is a cost associated with that. If they don't update, no modern browser will be able to talk to them.
This is not a mozilla unilateral decision. It's made in concert with other browser vendors.
bob
Daniel Veditz
> security.ssl.require_safe_negotiation
>
> I believe this to be a mistake for various reasons, but first and
> foremost because an attack on a server without compromise of the client
> data as well, is basically useless. When a attacker induces
> renegotiation at the server, the attacker must have client credentials
> in order to act as if he were the original client. Without those
> credentials, the attacker would be treated as any other unauthenticated
> source.
The client supplies the credentials. Not every server or application
is equally vulnerable, not all SSL connections use the HTTP
protocol. Sure, there may be specific attacks due to this flaw that
could be prevented in other ways (a typical anti-CSRF nonce in a web
form, say) but that is not a general defense. SSL is a
building-block and is supposed to guarantee an authenticated,
encrypted, tamper-proof connection to the application layers above.
It was broken and turns out to allow the injection of prefix content
in some situations. Whether that can lead to compromise depends on
what was built above the SSL layer.
> When a client (as in our case Firefox) implements RFC 5746, the client
> can't be compromised and no data is leaked from the client.
You don't know that! Depends on what the client is doing and what
the server is.
What if the attack is to make the client connect to an open
redirector on the target site? The client could leak all kinds of
data by sending it to the wrong site.
> SSLv2 was disabled in Firefox only a short while ago,
Three and a half years ago, October 2006 (longer if you count six
months of 2.0 pre-release builds). But the ability for users to
choose to disable it was available for years before that.
> I expect that it will take years upon years until 90% of all SSL enabled
> servers will support RFC 5746, not speaking about 99% or higher.
Then we would be foolish to toggle the default on that pref any time
soon.
> Refusing to speak to servers that don't support RFC 5746
> [... will force] the user to accept unsafe renegotiation
Why? Those are two separate prefs. The user can easily speak to
servers without rfc 5746 and still refuse unsafe renegotiation. But
you know this because "Minefield" broke client-auth on your site
with precisely these settings. What's your real point?
> It also must be noted that 99% or more of all SSL enabled web sites will
> never need renegotiation to work. A server which disabled renegotiation
> is at least as secure as a server supporting the new extension.
99.9% of bank customers will never have their bank go out of
business. Why should they bother to check whether their bank is
federally insured?
-Dan Veditz
Jean-Marc Desperrier
> Closely related to bug 554594 is
> https://bugzilla.mozilla.org/show_bug.cgi?id=535649
>
> Web developers using Firefox Error Console or tools like Firebug that
> use nsIConsoleService are now bombarded with pointless messages like:
>
> services.addons.mozilla.org : potentially vulnerable to CVE-2009-3555
No, what's closely related to this is
https://bugzilla.mozilla.org/show_bug.cgi?id=555952
Implement RFC 5746 for mozilla.org SSL sites, to avoid Mozilla warning
about CVE-2009-3555
As soon as the proper version of Zeus is deployed, this should be fixed.
Eddy Nigg
> SSL is a
> building-block and is supposed to guarantee an authenticated,
> encrypted, tamper-proof connection to the application layers above.
>
Yes, obviously I agree with this statement entirely and RFC 5746 fixes that.
> You don't know that! Depends on what the client is doing and what
> the server is.
>
My argument is, that you know what a client which implements RFC 5746 does.
> What if the attack is to make the client connect to an open
> redirector on the target site? The client could leak all kinds of
> data by sending it to the wrong site.
>
No, that shouldn't work anymore with a RFC 5746 compliant client.
>> SSLv2 was disabled in Firefox only a short while ago,
>>
> Three and a half years ago, October 2006 (longer if you count six
> months of 2.0 pre-release builds).
>
Phhh....is it really that long ago already? Anyway, it took some ten
years after the introduction of SSLv3 to turn it off. That's a long time.
> Then we would be foolish to toggle the default on that pref any time
> soon.
>
Thank you, that's what I wanted to hear.
> Why? Those are two separate prefs. The user can easily speak to
> servers without rfc 5746 and still refuse unsafe renegotiation.
Correct.
> But
> you know this because "Minefield" broke client-auth on your site
> with precisely these settings. What's your real point?
>
Exactly that was a warning sign for me about how easy it can break.
> 99.9% of bank customers will never have their bank go out of
> business.
>
Don't say never - Lehman Brothers anyone? And another couple of regional
banks in the US alone during the last year, actually in the hundreds :-)
But back to our subject, it also depends on what the other browser
vendors will do and when. When I did the risk assessment I came to the
conclusion that when using an RFC 5746 compliant client, the risk for
exploiting it, is incredible low. I believe the risks of SSLv2 were
higher on a practical level.
johnjbarton
Sorry, but your statement misses exactly the problem here.
Bug 535649 emits a warning message for every https site you visit. The
only people who can see this message are Web developers and users who
have problems with Firefox. These people are almost never in a position
to prevent the message. Only the people who maintain the server software
itself can prevent this message, and they of course never look at the
Firefox Error Console.
While it is embarrassing that one hand of Mozilla would announce to
developers that Mozilla sites are insecure before the other hand fixed
the sites, that entirely misses the point. This obscure message comes
for all https sites and is directed at the wrong people. It causes work
and anxious concern among people who have no control over the problem.
The appropriate way to address this security problem starts by
contacting the major providers of server software. By contacting just
the top 10 teams you can cover >99% of the worlds servers:
http://news.netcraft.com/archives/web_server_survey.html
Web server providers are very concerned about user security and they
would respond promptly to any real security threat. This is not true for
Web devs being spammed with this message: it's not their problem.
jjb
Eddy Nigg
On 04/02/2010 01:34 AM, Robert Relyea:
>
>> When a client (as in our case Firefox) implements RFC 5746, the
>> client can't be compromised and no data is leaked from the client. I
>> propose that Firefox should support the RFC 5746 extension
>> exclusively, but NOT block or warn on accessing servers which don't
>> support the extension. Any renegotiation attempt to the client will
>> be ignored and no data is leaked.
> Not true. Any client can be compromised as long as it accepts
> connections with servers that do not understand RFC 5746. A client
> that does SSL3 or TLS and *NEVER* renegotiates can be vulnerable.
I don't have the intention to continue the argument because I've
received already some answers which addressed part of my concerns. But
for the better understanding I'd be interested to know how a client that
doesn't renegotiate can be vulnerable. Are you saying that the client
can leak data without renegotiation?
> The only benefit clients have in installing RFC5746 is that servers
> that require renegotiation and install the update to provide safe
> renegotiation from the server stand point.
I believe the client will also reject any renegotiation attempt
according to the old protocol.
> There's a difference. There's a real vulnerability. Expect that time
> line to be accellerated for this RFC. (Probably still talk order of
> magnitude 1 year, not 1 decade or 1 month).
Realistically that's perhaps more into a few years. Older Apache and
Windows 2003 servers are still widely deployed and will most likely not
be updated. Newer versions will probably receive updates, there will be
always some which never update. Those will be the "your certificates
don't work" ones we'll have to deal with...
> They are still talking a broken protocol, and clients need to defend
> themselves. It's this fact that allows us to stage deploy. The risk is
> pretty low of a compromise.
That's my understanding as well - part of the argument.
> We know there are backwaters of conservative people who don't update
> their servers. There is a cost associated with that. If they don't
> update, no modern browser will be able to talk to them.
From my experience even a share of 1% can prevent the advantage of
better standards. Just think about non-standard domain names in CN
fields or RSA key sizes above 1024 to mention only a few.
>
> This is not a mozilla unilateral decision. It's made in concert with
> other browser vendors.
If all parties pull at the same string, this might work. So far this has
seldom worked.
Nelson B Bolyard
> Hi Bob,
>
> On 04/02/2010 01:34 AM, Robert Relyea:
>>> When a client (as in our case Firefox) implements RFC 5746, the
>>> client can't be compromised and no data is leaked from the client. I
>>> propose that Firefox should support the RFC 5746 extension
>>> exclusively, but NOT block or warn on accessing servers which don't
>>> support the extension. Any renegotiation attempt to the client will
>>> be ignored and no data is leaked.
>>
>> Not true. Any client can be compromised as long as it accepts
>> connections with servers that do not understand RFC 5746. A client
>> that does SSL3 or TLS and *NEVER* renegotiates can be vulnerable.
>
> I don't have the intention to continue the argument because I've
> received already some answers which addressed part of my concerns. But
> for the better understanding I'd be interested to know how a client that
> doesn't renegotiate can be vulnerable. Are you saying that the client
> can leak data without renegotiation?
Yes, Eddy. Any client that completes just a first handshake (not a
renegotiation, just a first handshake) with a vulnerable server becomes
vulnerable itself. The client becomes vulnerable by virtue of dealing
with the vulnerable server.
It's a real threat, demonstrable. It has been actually exploited.
The ONLY way for a client to protect itself from this vulnerability,
when dealing with a vulnerable server is to detect, early in the client's
first handshake, that the server is vulnerable, and then NOT complete the
first handshake because of that. If the client detects the server's
vulnerability, but goes ahead and completes the handshake, the damage is
done. Believe it.
This is true because the attacker can arrange it so that the victim client's
first handshake is actually a renegotiation for the server.
It's NOT a renegotiation for the client, but it IS for the server.
The server has previously negotiated with the attacker, and thinks that
it is renegotiating with the attacker, but is actually doing a negotiation
with the victim client. To the server it looks like a renegotiation.
To the victim client, it looks EXACTLY like a first handshake, not a
renegotiation. Whatever credentials the victim client provides in its
initial request (client auth, or a cookie, or a basic auth password)
will be seen by the vulnerable server as having come from the attacker,
because the server thinks it's renegotiating with the attacker. That's
how the attack works, and how the attacker uses the victims credentials.
Now, the way that a protects itself from a server's vulnerability is
that, in the client hello message, it asks the server "are you fixed"?
A Fixed server will answer affirmatively in its server hello message, and an
unfixed old server will ignore the request. When the client gets back the
server's hello message, if it doesn't contain the extension that says "yes,
I'm fixed", the client should drop that handshake right then and there, like
a hot potato.
Eddy Nigg
> This is true because the attacker can arrange it so that the victim client's
> first handshake is actually a renegotiation for the server.
> It's NOT a renegotiation for the client, but it IS for the server.
> The server has previously negotiated with the attacker, and thinks that
> it is renegotiating with the attacker, but is actually doing a negotiation
> with the victim client. To the server it looks like a renegotiation.
> To the victim client, it looks EXACTLY like a first handshake, not a
> renegotiation. Whatever credentials the victim client provides in its
> initial request (client auth, or a cookie, or a basic auth password)
> will be seen by the vulnerable server as having come from the attacker,
> because the server thinks it's renegotiating with the attacker. That's
> how the attack works, and how the attacker uses the victims credentials.
>
I can see how this can work in cases where all other data to be
exploited can be prepend by the attacker. Still, those are probably very
rare and unfortunate circumstances, it mustn't happen.
> Now, the way that a protects itself from a server's vulnerability is
> that, in the client hello message, it asks the server "are you fixed"?
> A Fixed server will answer affirmatively in its server hello message, and an
> unfixed old server will ignore the request. When the client gets back the
> server's hello message, if it doesn't contain the extension that says "yes,
> I'm fixed", the client should drop that handshake right then and there, like
> a hot potato.
>
Now I have a question I wanted to ask for a long time. Considering that
this design flaw existed for some 14 years and more...how come nobody
ever thought about this earlier? Isn't it amazing that such a fairly
trivial exploit existed for such a long time? Yourself know the SSL
protocols in and out and never thought about it?
Jean-Marc Desperrier
> The appropriate way to address this security problem starts by
> contacting the major providers of server software
There's no need to contact them, they are well aware of the problem.
AFAIK they have all already issued the necessary updates.
It's the sites that need to catch on those updates.
And web developers can have power to influence those sites to update.
johnjbarton
I think your assessment of the relationship between Web developers and
server infrastructure is based on dated information. These days only a
tiny fraction of the Web pages are served from sites where the developer
even knows who runs the server.
But even if there was a relationship, sending unsolicited, mass
electronic communications in an effort to goad people into lobbying for
your cause abuses your position of responsibility. Please reconsider.
If the *users* of Firefox are truly in jeopardy, then this alert should
be provided to *users*. Since this alert is not shown to users I can
only assume that in fact there is no practical threat here. You're
putting this message in the Error Console because you can.
jjb
Matt McCutchen
> On 03/31/2010 04:45 PM, Kai Engert:
> > ====== snip quote begin ======
> > E.g., the attacker would send:
> >
> > GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
> > X-Ignore-This:
> >
> > And the server uses the victim's account to send a pizza to the attacker.
> > ======= snip quote end =======
>
> This attack is highly theoretical beyond believe, specially the
> X-Ignore-This-and-That headers. Is has no real and practical value
> whatsoever.
There's nothing theoretical about ignoring unrecognized headers.
> Here some interesting observations and opinion by others:
> http://blogs.technet.com/srd/archive/2010/02/09/details-on-the-new-tls-advisory.aspx
To condense the point made there: The attacker cannot inject POST
parameters if he wants the client's Cookie header to be recognized as
such. Servers that perform unsafe actions in response to
unauthenticated GET requests are already vulnerable to browser-based
XSRF. Thus, the only configurations vulnerable specifically to the
renegotiation attack are those that have attackable parameters in the
URL and are authenticated with the Referer or a token in POST data.
Such configurations are uncommon, but they are not intrinsically
unreasonable. Sites that put parameters in URI path components are
likely to keep the same approach for their write requests. For example,
but for Launchpad's refusal of client-initiated renegotiation, it would
be vulnerable to a request to subscribe to one bug being changed to a
different bug. (Note that they use the Referer, not a token for XSRF
protection.)
I'll admit this is not a very serious compromise, but it illustrates the
point. It's totally unfair to expect web developers to have anticipated
that this configuration might be a bad idea. Hence I think the level of
concern about the attack is merited.
--
Matt
Nelson B Bolyard
> On 04/03/2010 01:07 PM, Nelson B Bolyard:
>> This is true because the attacker can arrange it so that the victim
>> client's first handshake is actually a renegotiation for the server.
>> It's NOT a renegotiation for the client, but it IS for the server. The
>> server has previously negotiated with the attacker, and thinks that it
>> is renegotiating with the attacker, but is actually doing a negotiation
>> with the victim client. To the server it looks like a renegotiation.
>> To the victim client, it looks EXACTLY like a first handshake, not a
>> renegotiation. Whatever credentials the victim client provides in its
>> initial request (client auth, or a cookie, or a basic auth password)
>> will be seen by the vulnerable server as having come from the attacker,
>> because the server thinks it's renegotiating with the attacker. That's
>> how the attack works, and how the attacker uses the victims
>> credentials.
>
> I can see how this can work in cases where all other data to be
> exploited can be prepend by the attacker. Still, those are probably very
> rare and unfortunate circumstances, it mustn't happen.
Let me tell you about one very simple attack. (I think this is old enough
now that the details are no longer big news in the hacking community.) The
MITM has an account on an SMTP server on the same host as an https server.
The SMTP server and the https server on that host use the same server
certificate. The attacker arranges to intercept the victim client's https
requests and connect them to the email server (!). The attacker first
connects to the email server and sends it a set of info that looks like it's
starting to send an email. He sends all the email headers, so that it
appears to be sending an email to himself, and is simply awaiting the
message body. Then he starts the renegotiation as seen by the server, and
splices in the connection from the victim client. The victim client
connects to the MITM, thinking that it is connecting to the https server,
and sends its https request, with its usual https request cookie by which it
authenticates itself to the https server. But this information is going into
the body of an email to be mailed to the attacker. The attacker receives
the email, takes the cookies out of it, and then impersonates the victim to
the https server.
This has been exploited more than once. Yes there are some tricks. Email
message bodies are supposed to end with a line that start with a "." and
contains only that ".". This can be arranged. I won't explain how.
There are other methods. An in house attacker can get a corporate expense
check issued to himself just by having someone else who is authorized to
issue such checks to merely login. ("What do you mean "The check you
requested has been issued"? What check? I just logged in?!?!?") That's
been exploited too.
>> Now, the way that a [client] protects itself from a server's
>> vulnerability is that, in the client hello message, it asks the server
>> "are you fixed"? A Fixed server will answer affirmatively in its
>> server hello message, [and later in the handshake will prove that this
>> is true] and an unfixed old server will ignore the request. When the
>> client gets back the server's hello message, if it doesn't contain the
>> extension that says "yes, I'm fixed", the client should drop that
>> handshake right then and there, like a hot potato.
>
> Now I have a question I wanted to ask for a long time. Considering that
> this design flaw existed for some 14 years and more...how come nobody
> ever thought about this earlier? Isn't it amazing that such a fairly
> trivial exploit existed for such a long time? Yourself know the SSL
> protocols in and out and never thought about it?
It's not so trivial. What the MITM must do to arrange this handshake that
appears to the server to be a renegotiation but to the client to be a first
negotiation is quite involved. No one ever though of it until last year,
apparently. It seems to have eluded the entire TLS working group until
last year. I did wonder about this once or twice over 13 years, but didn't
see any way to exploit it and so I thought it was safe. Someone finally
found a way. Thank goodness Marsh Ray wears a white hat!
Matt McCutchen
> Let me tell you about one very simple attack. (I think this is old enough
> now that the details are no longer big news in the hacking community.) The
> MITM has an account on an SMTP server on the same host as an https server.
> The SMTP server and the https server on that host use the same server
> certificate. The attacker arranges to intercept the victim client's https
> requests and connect them to the email server (!).
The real problem there is that TLS uses DNS names and thus does not
distinguish different services on the same server. Using RFC 4985
SRVNames such as _SMTP.example.com in certificates would solve that.
Two issues:
- Astonishingly, a service name for HTTP has not yet been registered
with IANA ( http://www.iana.org/assignments/service-names ). Somebody
should do that!
- RFC 4985 section 4 should be clearer that dNSName constraints as such
apply to SRVNames and the SRVName type is only used for constraints that
contain a service name. I may raise that on the pkix list.
--
Matt
Eddy Nigg
> Such configurations are uncommon, but they are not intrinsically
> unreasonable. Sites that put parameters in URI path components are
> likely to keep the same approach for their write requests. For example,
> but for Launchpad's refusal of client-initiated renegotiation, it would
> be vulnerable to a request to subscribe to one bug being changed to a
> different bug. (Note that they use the Referer, not a token for XSRF
> protection.)
>
Which is simply another user input (modifiable by the user).
> I'll admit this is not a very serious compromise, but it illustrates the
> point. It's totally unfair to expect web developers to have anticipated
> that this configuration might be a bad idea.
>
Well, those are not only bad ideas, they are most likely vulnerable to
all kinds of other attacks. The renegotiation flaw is just another
contributing fact which obviously shouldn't happen, but even without it
it's certainly no guaranty for protection for this kind of coding.
Eddy Nigg
> - RFC 4985 section 4 should be clearer that dNSName constraints as such
> apply to SRVNames and the SRVName type is only used for constraints that
> contain a service name. I may raise that on the pkix list.
>
This might interest you:
http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-02
Matt McCutchen
> On 04/04/2010 10:19 AM, Matt McCutchen:
> > - RFC 4985 section 4 should be clearer that dNSName constraints as such
> > apply to SRVNames and the SRVName type is only used for constraints that
> > contain a service name. I may raise that on the pkix list.
> >
>
> This might interest you:
> http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-02
You're right that it interests me, but I don't see where it addresses
name constraints or distinguishing among services.
--
Matt
Matt McCutchen
> The real problem there is that TLS uses DNS names and thus does not
> distinguish different services on the same server. Using RFC 4985
> SRVNames such as _SMTP.example.com in certificates would solve that.
I meant to add: Server Name Indication should use SRVNames too. That
way, an attempt to connect a client to the wrong service can be caught
at the TLS level even if the same certificate is used, since the
server_name extension is integrity-protected by the Finished hash.
--
Matt
Eddy Nigg
>> This might interest you:
>> http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-02
>>
> You're right that it interests me, but I don't see where it addresses
> name constraints or distinguishing among services.
>
That's just the next steps to include it in the certificates. Peter has
been working with us for the XMPP certificates, but unfortunately we
haven't come about to actually do that. It's still on my plate though...
Eddy Nigg
> It's not so trivial.
It's trivial from the logical point of view.
> I did wonder about this once or twice over 13 years, but didn't
> see any way to exploit it and so I thought it was safe. Someone finally
> found a way. Thank goodness Marsh Ray wears a white hat!
>
Unfortunately we don't know how many times this has been used
successfully. Thanks for the explanations, it broadened my understanding
about its potential misuse.
Matt McCutchen
> On 04/04/2010 07:44 AM, Matt McCutchen:
> > Such configurations are uncommon, but they are not intrinsically
> > unreasonable. Sites that put parameters in URI path components are
> > likely to keep the same approach for their write requests. For example,
> > but for Launchpad's refusal of client-initiated renegotiation, it would
> > be vulnerable to a request to subscribe to one bug being changed to a
> > different bug. (Note that they use the Referer, not a token for XSRF
> > protection.)
> >
>
> Which is simply another user input (modifiable by the user).
That's irrelevant. The Referer is an effective XSRF defense because a
malicious site cannot spoof a Launchpad referrer when sending a request
to Launchpad.
See this article, section 4.2, conclusion #1:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.2584&rep=rep1&type=pdf
--
Matt
Eddy Nigg
>> Which is simply another user input (modifiable by the user).
>>
> That's irrelevant. The Referer is an effective XSRF defense because a
> malicious site cannot spoof a Launchpad referrer when sending a request
> to Launchpad.
>
Huuu? And why not?
> See this article, section 4.2, conclusion #1:
>
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.2584&rep=rep1&type=pdf
>
Where exactly? I haven't see that this information is not subject to
user modification.
Matt McCutchen
> On 04/04/2010 01:49 PM, Matt McCutchen:
> >> Which is simply another user input (modifiable by the user).
> >>
> > That's irrelevant. The Referer is an effective XSRF defense because a
> > malicious site cannot spoof a Launchpad referrer when sending a request
> > to Launchpad.
> >
>
> Huuu? And why not?
How would it? What HTML / JavaScript could https://evil.com use to get
my browser to issue a malicious request to https://launchpad.net with a
referrer of https://launchpad.net ?
> Where exactly? I haven't see that this information is not subject to
> user modification.
You are still missing the point. The user can modify the referrer
header, sure, but the attack site that wishes to forge a cross-site
request cannot (unless the user specifically modified the browser to
allow that, which would be foolish).
--
Matt
Daniel Veditz
> If the *users* of Firefox are truly in jeopardy, then this alert should
> be provided to *users*. Since this alert is not shown to users I can
> only assume that in fact there is no practical threat here. You're
> putting this message in the Error Console because you can.
We plan on alerting users in a future update. This is fair warning
to server operators and those who are debugging their sites.
Matt McCutchen
> It's the sites that need to catch on those updates.
> And web developers can have power to influence those sites to update.
FWIW, I am a DreamHost customer and I just submitted a support ticket
with them to close the vulnerability for customer sites (initially by
refusing client-initiated renegotiation, eventually by implementing
safe renegotiation).
--
Matt
Matt McCutchen
> It's trivial from the logical point of view.
That's easy for you to say. Even things that are logically trivial
are easy to miss unless one goes carefully over every single step of
the process. For instance, I used a little script to check
certificates against private CAs for three months before I realized
that validating against the CA that owns the CN is the wrong thing to
do when the certificate might have matched the expected hostname using
a SAN. Logically trivial, but I wasn't thinking carefully and I
missed it.
--
Matt
johnjbarton
If this is a real threat don't users deserve a fair warning now? How is
it ok to let users be compromised "only for a while"?
The Firefox 3.6.3 release shows how Mozilla can react if it knows about
a real threat. So I have to conclude that you believe this threat is not
significant.
In that case working to close this potential problem is a laudable work
we all thank you for. Just please choose a more appropriate
communications channel.
jjb
Matt McCutchen
> On 4/4/2010 10:41 PM, Daniel Veditz wrote:
> > On 4/3/10 9:30 AM, johnjbarton wrote:
> >> If the *users* of Firefox are truly in jeopardy, then this alert should
> >> be provided to *users*. Since this alert is not shown to users I can
> >> only assume that in fact there is no practical threat here. You're
> >> putting this message in the Error Console because you can.
> >
> > We plan on alerting users in a future update. This is fair warning
> > to server operators and those who are debugging their sites.
>
> If this is a real threat don't users deserve a fair warning now?
I fully agree! If users are vulnerable now, they should be warned now,
(bug 535649 comment #15). The counterargument (comment #24) is that
showing the broken SSL UI for almost all sites will "quickly
neutraliz[e] the awareness/protection it might offer", but I think my
proposal for a yellow Larry button (comment #62) partially addresses
this concern.
--
Matt
Nelson B Bolyard
> On Wed, 2010-04-07 at 09:55 -0700, johnjbarton wrote:
>> On 4/4/2010 10:41 PM, Daniel Veditz wrote:
>>> We plan on alerting users in a future update. This is fair warning
>>> to server operators and those who are debugging their sites.
>>
>> If this is a real threat don't users deserve a fair warning now?
>
> I fully agree! If users are vulnerable now, they should be warned now,
> (bug 535649 comment #15). The counterargument (comment #24) is that
> showing the broken SSL UI for almost all sites will "quickly
> neutraliz[e] the awareness/protection it might offer",
And that argument is now being successfully used by a lot of companies
who make products that directly face the end users. They use it to avoid
doing ANYTHING about this problem. They say "we can't start to warn users
until a majority of the servers on the net have gotten fixed, so that a
minority generate the errors." And so users go unwarned, and they remain
blissfully ignorant of their vulnerability. Coinsequently, they put no
pressure on servers to get fixed. Consequently, there is NO pressure on
servers to get fixed, and servers are not getting fixed at all rapidly.
Inconveniencing the users is a NECESSARY part of getting this vulnerability
fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix
this.
> but I think my proposal for a yellow Larry button (comment #62)
> partially addresses this concern.
Maybe, but you'll have to sell it to product makers who'd prefer not to
annoy their users at all if their lives don't depend on it.
johnjbarton
...
> Inconveniencing the users is a NECESSARY part of getting this vulnerability
> fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix
> this.
The claim is obviously false as the recent update to Firefox 3.6.3
clearly demonstrates. If servers operators believe their users are at
risk, then they will take immediate action to protect them. Using spam
or pop-up ads to badger users in to lobbying on your behalf will drive
them to other browsers.
jjb
Robert Relyea
>
>>>> We plan on alerting users in a future update. This is fair warning
>>>> to server operators and those who are debugging their sites.
>>>>
>>> If this is a real threat don't users deserve a fair warning now?
>>>
>> I fully agree! If users are vulnerable now, they should be warned now,
>> (bug 535649 comment #15). The counterargument (comment #24) is that
>> showing the broken SSL UI for almost all sites will "quickly
>> neutraliz[e] the awareness/protection it might offer",
>>
> who make products that directly face the end users. They use it to avoid
> doing ANYTHING about this problem. They say "we can't start to warn users
> until a majority of the servers on the net have gotten fixed, so that a
> minority generate the errors." And so users go unwarned, and they remain
> blissfully ignorant of their vulnerability. Coinsequently, they put no
> pressure on servers to get fixed. Consequently, there is NO pressure on
> servers to get fixed, and servers are not getting fixed at all rapidly.
>
broken right now. Putting a warning dialog up now would only train users
to ignore the warnings (we've seen this in the past). That is why there
is a console warning. You can still get that information from the
console log, or even set the pref to disallow those connections. In any
case to say that firefox is not doing ANYTHING about the problem is
seriously mischaracterizing the problem.
The current response is in line with other well known and well respected
browsers out there, unless you are acusing Yngve Petterson of security
ignorance or laziness as well... The warnings will come -- when they can
have the most effect (that is pointing the user's wrath at the website
rather than the browser). We are already getting action from websites
from the console log warnings. AFAIK, Microsoft still has not released
any renegotiation patches. NSS's patches are only 1 month old.
> Inconveniencing the users is a NECESSARY part of getting this vulnerability
> fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix
> this.
>
And allowing the security updates on servers to perculate out is also a
necessary part. Don't worry, the hammer of noisy warnings are still in
the tools shed, we just need to use it when it will do the most good.
(Just before those last websites get turned off...).
>> but I think my proposal for a yellow Larry button (comment #62)
>> partially addresses this concern.
>>
> Maybe, but you'll have to sell it to product makers who'd prefer not to
> annoy their users at all if their lives don't depend on it.
>
The yellow larry is a good proposal, and probably implementable much
sooner than noisy warnings.
Matt McCutchen
> On 4/7/2010 9:35 PM, Nelson B Bolyard wrote:
> ...
> > Inconveniencing the users is a NECESSARY part of getting this vulnerability
> > fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix
> > this.
> ...
>
> The claim is obviously false as the recent update to Firefox 3.6.3
> clearly demonstrates. If servers operators believe their users are at
> risk, then they will take immediate action to protect them.
Firefox developers != server operators.
--
Matt
Nelson B
> On 4/7/2010 9:35 PM, Nelson B Bolyard wrote: ...
>> Inconveniencing the users is a NECESSARY part of getting this
>> vulnerability fixed. Without that, the servers have NO INCENTIVE to
>> lift a finger to fix this.
> ...
>
> The claim is obviously false as the recent update to Firefox 3.6.3
> clearly demonstrates. If servers operators believe their users are at
> risk, then they will take immediate action to protect them.
Most server operators have not yet even HEARD of this vulnerability.
In many cases the first way they ever will hear about it is from their
annoyed users.
> Using spam or pop-up ads to badger users in to lobbying on your behalf
> will drive them to other browsers.
On _MY_ behalf? certainly not! On their OWN behalf!
Those users are the ones who stand to lose while their vulnerabilities
and the vulnerabilities of the servers they use remain unfixed. It's
in their own best interest to see those fixed. It is in their own
interest that they will complain to their servers' admins.
Matt McCutchen
> The yellow larry is a good proposal, and probably implementable much
> sooner than noisy warnings.
I'm glad you like it. I guess the next thing needed is for someone to
actually implement it, perhaps me if I can figure out how.
--
Matt
Kai Engert
I wrote about this 3 months ago:
https://bugzilla.mozilla.org/show_bug.cgi?id=535649#c3
Option (d) "invent a new notification" is the same as your proposal to
"show yellow".
We'd have to do everything that I described there, related to (d), which
is more work than simply switching to "broken security" or "adding
console output".
In short, security level detection and GUI display are done at different
layers of the software, so we'd have to add new signaling between layers.
In addition, "color" should never be the only notification mechanism,
because some people are color blind. So, if your proposed change is to
"only" switch Larry to yellow, I believe it would be not sufficient.
Kai
johnjbarton
realistic security threats to their users. Neither group should be
blackmailed into pointless action by badgering users.
jjb
Matt McCutchen
Are you saying that Mozilla shouldn't encourage users to bother their
server operators because if the problem were real, the server operators
would already have fixed it? I think you give the server operators way
too much credit. People are lazy. I trust Mozilla much more than the
average sysadmin to properly assess vulnerabilities.
Besides, in my view, the problem is real. For better or for worse, the
goal of SSL has always been to provide complete protection against a
middleman who controls the network. And for certain designs of Web apps
which are not intrinsically unreasonable (see my other message), it
completely fails to prevent a middleman from subverting your requests.
--
Matt
johnjbarton
> On Fri, 2010-04-09 at 09:34 -0700, johnjbarton wrote:
>> On 4/8/2010 12:13 PM, Matt McCutchen wrote:
>>> On Thu, 2010-04-08 at 09:35 -0700, johnjbarton wrote:
>>>> On 4/7/2010 9:35 PM, Nelson B Bolyard wrote:
>>>> ...
>>>>> Inconveniencing the users is a NECESSARY part of getting this vulnerability
>>>>> fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix
>>>>> this.
>>>> ...
>>>>
>>>> The claim is obviously false as the recent update to Firefox 3.6.3
>>>> clearly demonstrates. If servers operators believe their users are at
>>>> risk, then they will take immediate action to protect them.
>>>
>>> Firefox developers != server operators.
>>>
>> Both groups are committed to their users and both groups will respond to
>> realistic security threats to their users. Neither group should be
>> blackmailed into pointless action by badgering users.
>
> Are you saying that Mozilla shouldn't encourage users to bother their
> server operators because if the problem were real, the server operators
> would already have fixed it? I think you give the server operators way
> too much credit. People are lazy. I trust Mozilla much more than the
> average sysadmin to properly assess vulnerabilities.
Your assessment of the relative commitment and competence of these two
groups of people is unjustified by facts.
> Besides, in my view, the problem is real. For better or for worse, the
> goal of SSL has always been to provide complete protection against a
> middleman who controls the network. And for certain designs of Web apps
> which are not intrinsically unreasonable (see my other message), it
> completely fails to prevent a middleman from subverting your requests.
>
I appreciate your commitment to improving Web security. Please channel
this passion in a respectful fashion. Rather than arrogantly asserting
superiority over server admins and irresponsibly exhorting users to
harass them, build a clearer case for the potential dangers here. Then
contact the communications people in Mozilla, large international Web
service companies, professional organizations of server administrators,
news organizations, slash.dot, and so forth. Explain the problem and the
fix. This procedure will prepare you and the people you contact for
future similar problems and strengthen our entire system.
jjb
Nelson Bolyard
> On 04/07/2010 09:35 PM, Nelson B Bolyard wrote:
>>>>> We plan on alerting users in a future update. This is fair warning
>>>>> to server operators and those who are debugging their sites.
>>>>>
>>>> If this is a real threat don't users deserve a fair warning now?
>>>>
>>> I fully agree! If users are vulnerable now, they should be warned now,
>>> (bug 535649 comment #15). The counterargument (comment #24) is that
>>> showing the broken SSL UI for almost all sites will "quickly
>>> neutraliz[e] the awareness/protection it might offer",
>>>
>> And that argument is now being successfully used by a lot of companies
>> who make products that directly face the end users. They use it to avoid
>> doing ANYTHING about this problem. They say "we can't start to warn users
>> until a majority of the servers on the net have gotten fixed, so that a
>> minority generate the errors." And so users go unwarned, and they remain
>> blissfully ignorant of their vulnerability. Coinsequently, they put no
>> pressure on servers to get fixed. Consequently, there is NO pressure on
>> servers to get fixed, and servers are not getting fixed at all rapidly.
>>
> What in the world are you talking about here?
You know very well what I'm talking about.
> The entire internet is broken right now.
Correct. And intranets, too.
> Putting a warning dialog up now would only train users
> to ignore the warnings (we've seen this in the past).
It will do more than that. It will alert people to the fact that the
internet and all those intranets are entirely broken right now, a fact to
which they are otherwise ENTIRELY IGNORANT.
Case in point. I work in a small company, about 600 people. They have an
IT department that uses mostly Microsoft servers. They use SSL on every
server they can do so, yet all their servers are broken in this way. They
are completely unaware of this problem. It will do me NO GOOD to go and
tell them that all their servers are broken. They will think I'm a kook.
They will say "If our servers are broken, why don't all our client programs
complain?"
> That is why there
> is a console warning. You can still get that information from the
> console log, or even set the pref to disallow those connections. In any
> case to say that firefox is not doing ANYTHING about the problem is
> seriously mischaracterizing the problem.
I believe our employees could not find that console report even if they were
told about it and told to go look for it. It's too well buried by
people who are deathly afraid of giving users a "bad experience".
> The current response is in line with other well known and well respected
> browsers out there, unless you are acusing Yngve Petterson of security
> ignorance or laziness as well.
Yngve is also begging the browser community to start sounding the alarm.
The browsers are all deathly afraid of doing so. They all say "we will
start doing so when all the other browsers start doing so."
> .. The warnings will come --
WHEN? In 2010? In 2011?
johnjbarton
They will think you are a kook if you run in yelling "The Sky is
Falling!!!!" All you end up doing is annoying everyone. Consider a
different approach.
>
>> That is why there
>> is a console warning. You can still get that information from the
>> console log, or even set the pref to disallow those connections. In any
>> case to say that firefox is not doing ANYTHING about the problem is
>> seriously mischaracterizing the problem.
>
> I believe our employees could not find that console report even if they were
> told about it and told to go look for it. It's too well buried by
> people who are deathly afraid of giving users a "bad experience".
>
>> The current response is in line with other well known and well respected
>> browsers out there, unless you are acusing Yngve Petterson of security
>> ignorance or laziness as well.
>
> Yngve is also begging the browser community to start sounding the alarm.
> The browsers are all deathly afraid of doing so. They all say "we will
> start doing so when all the other browsers start doing so."
>
>
>> .. The warnings will come --
>
> WHEN? In 2010? In 2011?
When we see something more than an acorn.
jjb
>
>
Eddy Nigg
>> .. The warnings will come --
>>
> WHEN? In 2010? In 2011?
>
Whenever it will be, it will become an entire mess. That's because
updated servers need updates clients and break older ones, whereas old
servers will not allow new clients.
Basically if not the whole Internet moves to the new protocol in one
day, there is going to be nightmare. It's starting already with updated
clients or updated servers, we'll have always a group which isn't served.
Jean-Marc Desperrier
> updated servers need updates clients and break older ones, whereas old
> servers will not allow new clients.
I haven't seen one yet, that doesn't have a flag to accept older
clients. If you set that flag, *and* disable renegotiation at least for
older clients, you're safe.
Eddy Nigg
Well, I think a client that doesn't implement RFC 5746 can't do
renegotiation with a server that implements RFC 5746 and vice versa.
Marsh Ray
> renegotiation with a server that implements RFC 5746 and vice versa.
In coming up with the wording of RFC 5746 we wanted to spell out what it
would take to restore the (stated and implied) integrity guarantees
offered by SSL/TLS, but we had to be a little realistic. After all, some
may take the option of just not implementing it.
Here are some excerpts from http://tools.ietf.org/html/rfc5746
I tried to cut out some of the irrelevant details so as not to
"desensitize" everybody with too much information :-)
> [] merely because the server does not
> acknowledge the extension does not mean that it is vulnerable; it
> might choose to reject all renegotiations and simply not signal it.
> However, it is not possible for the client to determine purely via
> TLS mechanisms whether or not this is the case.
>
> If clients wish to ensure that such attacks are impossible, they need
> to terminate the connection immediately upon failure to receive the
> extension without completing the handshake. Such clients MUST [...]
> However, it is expected that many TLS servers that do
> not support renegotiation (and thus are not vulnerable) will not
> support this extension either, so in general, clients that implement
> this behavior will encounter interoperability problems. There is no
> set of client behaviors that will guarantee security and achieve
> maximum interoperability during the transition period. Clients need
> to choose one or the other preference when dealing with potentially
> un-upgraded servers.
> It is possible that un-upgraded servers will request that the client
> renegotiate. It is RECOMMENDED that clients refuse this
> renegotiation request. Clients that do so MUST [...]
> It is possible that the
> apparently un-upgraded server is in fact an attacker who is then
> allowing the client to renegotiate with a different, legitimate,
> upgraded server. If clients nevertheless choose to renegotiate, they
> MUST behave as described below.
> It is RECOMMENDED that servers not permit legacy renegotiation. If
> servers nevertheless do permit it, they MUST follow the requirements
> in this section.
So the RFC RECOMMENDED many times against doing things that are
ultimately unsafe, but is also realistic.
I was counting on the vendors of user agents and minimally-inspecting
firewalls to inform and motivate the patching process. We need visible
warnings which increase in prominence over time if we are going to dig
our way out of this.
This argument about the scary page desensitizing users is a valid one,
from one perspective. But that point of view only goes so far!
The whole point of displaying a lock icon is that there exists a
possibility that someday it does _not_ indicate the secure locked state.
Failing to show the scary page when the scary page is appropriate is
hardly better than a situation where some subset of users don't take it
seriously (which will probably be the case regardless).
If the connection fails to provide data integrity and/or confidentiality
against a demonstrable MitM, at some point we just have to admit it's
not a secure connection worthy of a locked icon.
Let's call it a duck, get everyone patched, and move on.
- Marsh
Eddy Nigg
> Here are some excerpts from http://tools.ietf.org/html/rfc5746
> I tried to cut out some of the irrelevant details so as not to
> "desensitize" everybody with too much information :-)
>
Thanks for your response here...
> So the RFC RECOMMENDED many times against doing things that are
> ultimately unsafe, but is also realistic.
>
Perhaps quite right so...
> I was counting on the vendors of user agents and minimally-inspecting
> firewalls to inform and motivate the patching process. We need visible
> warnings which increase in prominence over time if we are going to dig
> our way out of this.
>
It might be possible for the clients to ping the server if renegotiation
(in old way) is supported at all. There are quite some servers out there
that don't do that by default. With this, the pain could be perhaps
mitigated.
> If the connection fails to provide data integrity and/or confidentiality
> against a demonstrable MitM, at some point we just have to admit it's
> not a secure connection worthy of a locked icon.
>
The claim was made here that the client software can only truly know if
a server is secure in case RFC 5746 is supported.
> Let's call it a duck, get everyone patched, and move on
If that would have be as easy as you say it, we'd be living truly in a
better world :-)
Perhaps the best thing which will happen, is that old browsers finally
will see the end of their time once most servers did upgrade. When that
will happen, who knows...
Marsh Ray
>
> It might be possible for the clients to ping the server if renegotiation
> (in old way) is supported at all. There are quite some servers out there
> that don't do that by default. With this, the pain could be perhaps
> mitigated.
> a server is secure in case RFC 5746 is supported.
You can do a simple test with openssl's s_client utility. Connect to the
server and type capital 'R'. That will tell you how the server responds
client-initiated renegotiation. Unfortunately, there's no way for a
client to tell if a server will ever do unsafe server-initiated
renegotiation. It could be that by requesting an URL from one tiny
little subdirectory on the site will cause the server to initiate
renegotiation for the purpose of changing crypto requirements or
requesting a client certificate.
Yes, there lots of servers out there that will never renegotiate and are
thus not vulnerable. Unfortunately, there's just no way for an SSLv3 or
TLS client to determine this during the handshake.
In the case of providing a client certificate to an HTTPS server, it's
even worse. The server accepts a valid Finished message from the client
and retro-actively authenticates the (attacker's) request. Because the
client is required to send his Finished message before receiving the
server's, the client does not have a chance to fully complete the
process of strongly authenticating the server. Client cert credentials
can thus be forwarded from the server to which the client intended to
connect to an (unpatched) attacker-chosen server that will accept those
credentials.
>> Let's call it a duck, get everyone patched, and move on
>
> If that would have be as easy as you say it, we'd be living truly in a
> better world :-)
Hey, somebody's gotta dream the impossible dream :-)
> Perhaps the best thing which will happen, is that old browsers finally
> will see the end of their time once most servers did upgrade. When that
> will happen, who knows...
This is a really sticky protocol bug to fix. The worst part is that
there are a lot of mitigations that seem like they would just almost
work "if...". But unfortuantely a solid fix for the general case
requires a breaking protocol change.
But this is not the first time a bug required everybody to patch or even
migrate to a new protocol version. Yes, vendors, users, and admins will
all have to use good judgment and find the tradeoff between security and
compatibility for their own situation. But that is our responsibility
after all, and I don't see it as necessarily bad to be having this
discussion.
- Marsh
Matt McCutchen
> On 09.04.2010 00:41, Matt McCutchen wrote:
> > On Thu, 2010-04-08 at 09:59 -0700, Robert Relyea wrote:
> >> The yellow larry is a good proposal, and probably implementable much
> >> sooner than noisy warnings.
> >
> > I'm glad you like it. I guess the next thing needed is for someone to
> > actually implement it, perhaps me if I can figure out how.
>
> I wrote about this 3 months ago:
> https://bugzilla.mozilla.org/show_bug.cgi?id=535649#c3
>
> Option (d) "invent a new notification" is the same as your proposal to
> "show yellow".
>
> We'd have to do everything that I described there, related to (d), which
> is more work than simply switching to "broken security" or "adding
> console output".
>
> In short, security level detection and GUI display are done at different
> layers of the software, so we'd have to add new signaling between layers.
I understand.
> In addition, "color" should never be the only notification mechanism,
> because some people are color blind. So, if your proposed change is to
> "only" switch Larry to yellow, I believe it would be not sufficient.
Users who cannot see hue may still notice the difference in brightness
of the background compared to the text, at least on Linux where the blue
background is dark. On Mac, I believe it is lighter.
To help all users, even users who only get the text (e.g., using a
screen reader), I propose to also add a question mark at the end of the
text, e.g., "mattmccutchen.net ?" .
--
Matt
Matt McCutchen
> On 4/9/2010 6:06 PM, Matt McCutchen wrote:
> > Are you saying that Mozilla shouldn't encourage users to bother their
> > server operators because if the problem were real, the server operators
> > would already have fixed it? I think you give the server operators way
> > too much credit. People are lazy. I trust Mozilla much more than the
> > average sysadmin to properly assess vulnerabilities.
>
> Your assessment of the relative commitment and competence of these two
> groups of people is unjustified by facts.
Indeed, but do you have facts supporting the opposite conclusion?
> I appreciate your commitment to improving Web security. Please channel
> this passion in a respectful fashion. Rather than arrogantly asserting
> superiority over server admins and irresponsibly exhorting users to
> harass them, build a clearer case for the potential dangers here. Then
> contact the communications people in Mozilla, large international Web
> service companies, professional organizations of server administrators,
> news organizations, slash.dot, and so forth. Explain the problem and the
> fix. This procedure will prepare you and the people you contact for
> future similar problems and strengthen our entire system.
A coordinated PR effort led by Mozilla would be great. However, I don't
see what is wrong with users contacting their sysadmins individually to
advocate that a vulnerability be patched, just as they would make any
other request of the sysadmins. If the sysadmins want to make an
argument that it isn't important in their particular case, fine, but the
users have every right to ask.
--
Matt
johnjbarton
> On Sat, 2010-04-10 at 08:10 -0700, johnjbarton wrote:
>> On 4/9/2010 6:06 PM, Matt McCutchen wrote:
>>> Are you saying that Mozilla shouldn't encourage users to bother their
>>> server operators because if the problem were real, the server operators
>>> would already have fixed it? I think you give the server operators way
>>> too much credit. People are lazy. I trust Mozilla much more than the
>>> average sysadmin to properly assess vulnerabilities.
>>
>> Your assessment of the relative commitment and competence of these two
>> groups of people is unjustified by facts.
>
> Indeed, but do you have facts supporting the opposite conclusion?
I assume this groups are equally committed, based on personal experience
with both groups and common sense.
>
>> I appreciate your commitment to improving Web security. Please channel
>> this passion in a respectful fashion. Rather than arrogantly asserting
>> superiority over server admins and irresponsibly exhorting users to
>> harass them, build a clearer case for the potential dangers here. Then
>> contact the communications people in Mozilla, large international Web
>> service companies, professional organizations of server administrators,
>> news organizations, slash.dot, and so forth. Explain the problem and the
>> fix. This procedure will prepare you and the people you contact for
>> future similar problems and strengthen our entire system.
>
> A coordinated PR effort led by Mozilla would be great. However, I don't
> see what is wrong with users contacting their sysadmins individually to
> advocate that a vulnerability be patched, just as they would make any
> other request of the sysadmins. If the sysadmins want to make an
> argument that it isn't important in their particular case, fine, but the
> users have every right to ask.
>
I see nothing wrong with users contacting sysadmins. I object to using
the browser as a platform for badgering Web developers to contact
sysadmins on your behalf.
jjb
Nelson B Bolyard
> I see nothing wrong with users contacting sysadmins. I object to using
> the browser as a platform for badgering Web developers to contact
> sysadmins on your behalf.
You continue to make the mistake of assuming that users have no vested self
interest in having access to secure servers, and that they are merely
doing a favor for some set of developers, rather than acting in their own
self interest, by asking server admins to fix their servers.
johnjbarton
So by this argument we should warn users whenever they access
pornographic sites, radical right wing sites, socialist sites, religious
and atheist sites. We need to inform them, for their own self interest,
that the server admins need to fix their servers. But why stop there?
Users self interest surely extent beyond the browser. Should we send
them messages to lobby against air pollution, poverty, government
intrusion, and so on? Is it really true that CVE-2009-3555 is the only
issue worthy of their attention?
There are appropriate channels for advertising this problem and
educating users and servers about it. The current Error Console spam
campaign and the propose pop-up ads campaign are simply not appropriate
actions for the browser.
The browser's legitimate role here informs users on the connection they
have to a server. If Firefox is presenting a user interface that shows a
secure connection for https, but the connection is not secure according
to the browser's security experts, then Firefox is broken. The
legitimate action by browser developers is to fix their bug.
jjb
Nelson B Bolyard
> On 4/19/2010 1:42 AM, Nelson B Bolyard wrote:
>> On 2010-04-18 21:16 PST, johnjbarton wrote:
>>
>>> I see nothing wrong with users contacting sysadmins. I object to
>>> using the browser as a platform for badgering Web developers to
>>> contact sysadmins on your behalf.
>>
>> You continue to make the mistake of assuming that users have no vested
>> self interest in having access to secure servers, and that they are
>> merely doing a favor for some set of developers, rather than acting in
>> their own self interest, by asking server admins to fix their
>> servers.
>
> So by this argument we should warn users whenever they access
> pornographic sites, radical right wing sites, socialist sites, religious
> and atheist sites.
That's silly. https doesn't protect users from site content. It protects
users from interception and modification or falsification of content while
in flight, provided that the client AND the server are both implementing
SSL correctly. Users care about that because they don't want their
passwords and other secrets stolen, as can now be done when used with
broken servers.
> We need to inform them, for their own self interest, that the server
> admins need to fix their servers.
Right. We've fixed the SSL code in the browser. Now it's the servers
that need to be fixed. The users won't be fully protected until the
servers are fixed.
> But why stop there? Users self interest surely extent beyond the
> browser. Should we send them messages to lobby against air pollution,
> poverty, government intrusion, and so on? Is it really true that
> CVE-2009-3555 is the only issue worthy of their attention?
That's silly. It has nothing to do with the charter of https. The
issues I'm discussing have everything to do with the charter of https.
> There are appropriate channels for advertising this problem and
> educating users and servers about it. The current Error Console spam
> campaign and the propose pop-up ads campaign are simply not appropriate
> actions for the browser.
Your opinion is duly noted.
> The browser's legitimate role here informs users on the connection they
> have to a server. If Firefox is presenting a user interface that shows
> a secure connection for https, but the connection is not secure
> according to the browser's security experts, then Firefox is broken.
I agree with that, too. The NSS SSL library accurately tells the browser
about the reality of the situation. How the browser then informs the user
of that situation is up to the browser, not up to NSS (NSS does no UI).
> The legitimate action by browser developers is to fix their bug.
But that, by itself, does not provide the users with transport security.
The industry is largely sticking its head in the sand, saying "don't bother
me with the facts, don't give me errors or warnings. I'd rather be
ignorant of this huge security hole (and keep my users largely ignorant of
it) than fix it." Someone has to watch out for the users' interest.
Telling us that you'd prefer that Mozilla products kept silent about it
tells us something about where you stand on the security-vs-convenience
issue. It's not likely to engender much sympathy here.
In this case, Mozilla has chosen to tell the users about this problem by
this particular means. I'd prefer a more blatant means, but it's better
than nothing. I appreciate that some effort is being made.
johnjbarton
> On 2010/04/19 08:33 PDT, johnjbarton wrote:
>
>> There are appropriate channels for advertising this problem and
>> educating users and servers about it. The current Error Console spam
>> campaign and the propose pop-up ads campaign are simply not appropriate
>> actions for the browser.
>
> Your opinion is duly noted.
>
>> The browser's legitimate role here informs users on the connection they
>> have to a server. If Firefox is presenting a user interface that shows
>> a secure connection for https, but the connection is not secure
>> according to the browser's security experts, then Firefox is broken.
>
> I agree with that, too. The NSS SSL library accurately tells the browser
> about the reality of the situation. How the browser then informs the user
> of that situation is up to the browser, not up to NSS (NSS does no UI).
If this were true, I would not be here to complain. NSS does write to
the Error Console, and that is my UI.
>
>> The legitimate action by browser developers is to fix their bug.
>
> But that, by itself, does not provide the users with transport security.
>
> The industry is largely sticking its head in the sand, saying "don't bother
> me with the facts, don't give me errors or warnings. I'd rather be
> ignorant of this huge security hole (and keep my users largely ignorant of
> it) than fix it." Someone has to watch out for the users' interest.
You're making this up. No industry spokeperson, company representative,
or unincorporated server admin has said any such thing.
But suppose that in fact someone did say exactly what you quote. Why
should you follow up by writing error messages in a console that no one
in "the industry" ever sees?
Direct your energy at the problem you want to solve. Talk to some server
admins. Ask them why they are reluctant to take action. Find some real
industry representatives. Ask for their help. The first thing they need
from you is a convincing argument that this is real problem. Once they
understand that their users are exposed to a security threat they will
take prompt action.
>
> Telling us that you'd prefer that Mozilla products kept silent about it
> tells us something about where you stand on the security-vs-convenience
> issue. It's not likely to engender much sympathy here.
I do not appreciate your continued misrepresentation of my comments on
this newsgroup.
I have made no comments on security-vs-convenience here.
The only sympathy I seek concerns the repeated, pointless, obscure
messages that you are putting in my user interface about problems I did
not cause and cannot fix.
> In this case, Mozilla has chosen to tell the users about this problem by
> this particular means. I'd prefer a more blatant means, but it's better
> than nothing. I appreciate that some effort is being made.
jjb
Marsh Ray
> On 2010/04/19 08:33 PDT, johnjbarton wrote:
>
Right, both the client and server have to be patched. It's not a bug in
either one, but in the protocol itself.
> The industry is largely sticking its head in the sand, saying "don't bother
> me with the facts, don't give me errors or warnings. I'd rather be
> ignorant of this huge security hole (and keep my users largely ignorant of
> it) than fix it." Someone has to watch out for the users' interest.
I think many vendors have been quite concerned, but have been blocked on
shipping a patch until the underlying library made it available. In some
cases they could move faster because they wrote their own. In other
cases the vendor really is taking it seriously but simply has a zillion
products affected. For example, Opera was the first to ship a patch and
they lead the way in accurately reflecting the security of the connection.
Opera will currently decline to turn the address bar green for EV certs
if the connection is vulnerable. That is a great first step, and they
intend to make that more prominent over time, too.
Mozilla also has the benefit of an internally developed TLS stack which
implements a fix. Yet using Firefox 3.6.3 I don't see any visible
indication of my https being vulnerable even in the "Technical Details"
section of the Page Info dialog.
It's not going to look so great for Mozilla when another prominent
browser vendor ships another patch which also notifies the user of the
insecure connection.
People might legitimately ask at that point how such a prominent open
source product as Mozilla ended up putting other considerations ahead of
their user's security, whereas multiple commercial closed source vendors
are really taking it seriously. It might be hard to come up a good
answer for that one. Better start thinking about it now.
- Marsh
Marsh Ray
> On 4/19/2010 10:52 AM, Nelson B Bolyard wrote:
>>
>> The industry is largely sticking its head in the sand, saying "don't
>> bother
>> me with the facts, don't give me errors or warnings. I'd rather be
>> ignorant of this huge security hole (and keep my users largely
>> ignorant of
>> it) than fix it." Someone has to watch out for the users' interest.
>
> You're making this up. No industry spokeperson, company representative,
> or unincorporated server admin has said any such thing.
No, they say "I'd rather keep the entire world completely ignorant of it
until we have a chance to fix it in secret and release the fix in
oh....how about a year from now?"
> But suppose that in fact someone did say exactly what you quote. Why
> should you follow up by writing error messages in a console that no one
> in "the industry" ever sees?
You saw it.
I say you can make a difference!
> Direct your energy at the problem you want to solve. Talk to some server
> admins. Ask them why they are reluctant to take action. Find some real
> industry representatives. Ask for their help. The first thing they need
> from you is a convincing argument that this is real problem.
Good plan, we've been at that process since last September.
http://www.google.com/search?q=ssl+tls+"project+mogul"
> Once they
> understand that their users are exposed to a security threat they will
> take prompt action.
I thought so too. :-) And to their credit some have. It is for them that
I think the process should be optimized.
But in reality most users and admins are just stuck until they get a
clean patch from their upstream vendor. The vast majority are waiting
for it to be pushed down automatically.
>> Telling us that you'd prefer that Mozilla products kept silent about it
>> tells us something about where you stand on the security-vs-convenience
>> issue. It's not likely to engender much sympathy here.
>
> I do not appreciate your continued misrepresentation of my comments on
> this newsgroup.
I've had this conversation with Nelson many times. I don't think he's
trying to misrepresent your comments as much as he's responding to some
much more general and abstract forces. Nevertheless, to the extent that
he is being specific I agree with him.
> I have made no comments on security-vs-convenience here.
Well you're on a development list for an open source project here. The
only reason I can see why you would object to the insecurity warning is
that you find it 'inconvenient' to build the app for yourself with the
one line that prints the warning commented out.
> The only sympathy I seek concerns the repeated, pointless, obscure
> messages that you are putting in my user interface about problems I did
> not cause and cannot fix.
Well yeah. None of us here caused this, and none of us can fix it
ourselves. We've worked hard to put together a fix to the protocol and
to implement the fix in code. Now we need to get people to patch in a
compatible way.
I advocate informing the affected parties through whatever channels are
appropriate. I think a error log message is very appropriate but do not
want to stop there!
I don't agree at all that such a message is pointless. I have spent huge
amounts of time trying to get the accurate information out so that this
very serious bug is not "obscure". Obscurity only favors the bad guys here.
- Marsh
Robert Relyea
>
> Opera will currently decline to turn the address bar green for EV certs
> if the connection is vulnerable. That is a great first step, and they
> intend to make that more prominent over time, too.
>
> Mozilla also has the benefit of an internally developed TLS stack which
> implements a fix. Yet using Firefox 3.6.3 I don't see any visible
> indication of my https being vulnerable even in the "Technical Details"
> section of the Page Info dialog.
>
There's an error logged to the java console.... it logs all unsafe
websites, not just EV.
> It's not going to look so great for Mozilla when another prominent
> browser vendor ships another patch which also notifies the user of the
> insecure connection.
>
Mozilla is phasing in, just like Opera. You can see some in the list is
violently opposed to any kind of notification. If you are really
worried, Mozilla gives you the option of only making safe connections;).
You'll see more of this over time. If you want to complain about keeping
the internet from being safe, I suggest talking to some of the vendors
who haven't even released renogotiation patches yet.
> People might legitimately ask at that point how such a prominent open
> source product as Mozilla ended up putting other considerations ahead of
> their user's security, whereas multiple commercial closed source vendors
> are really taking it seriously. It might be hard to come up a good
> answer for that one. Better start thinking about it now.
>
On this issue, Mozilla is far from dragging it's feet. The criticism may
hold more water if more major browsers actually implemented the
renegotiation extension! You were told this will be a slow process.
We're working are way through it Marsh.
bob
> - Marsh
>
Nelson B
> On 4/19/2010 10:52 AM, Nelson B Bolyard wrote:
>> On 2010/04/19 08:33 PDT, johnjbarton wrote:
>>> The browser's legitimate role here informs users on the connection they
>>> have to a server. If Firefox is presenting a user interface that shows
>>> a secure connection for https, but the connection is not secure
>>> according to the browser's security experts, then Firefox is broken.
>>
>> I agree with that, too. The NSS SSL library accurately tells the browser
>> about the reality of the situation. How the browser then informs the user
>> of that situation is up to the browser, not up to NSS (NSS does no UI).
>
> If this were true, I would not be here to complain. NSS does write to
> the Error Console, and that is my UI.
Not true. Go find the line of code that writes to the error console.
You will find that it is not in mozilla/security/NSS.
> But suppose that in fact someone did say exactly what you quote. Why
> should you follow up by writing error messages in a console that no one
> in "the industry" ever sees?
Why should I? I do not, and have not. I work on NSS, a crypto library
used in browsers and servers, which does no UI and calls no browser error
console functions. The code about which you complain is not in NSS. You
are complaining to the wrong person.
> Direct your energy at the problem you want to solve. Talk to some server
> admins. Ask them why they are reluctant to take action. Find some real
> industry representatives. Ask for their help. The first thing they need
> from you is a convincing argument that this is real problem. Once they
> understand that their users are exposed to a security threat they will
> take prompt action.
I am a supplier of software. My relationship with any such people is like
a person on the supplier's end of a rope. I can't get very far by pushing.
The rope must be pulled. The people who will pull it from me will do so
when others pull on a similar rope from them. Those others are the users.
The users will pull their end of their ropes with their suppliers when they
perceive they have a problem. But they don't read RFCs or CVEs where
they'd see Marsh's name and mine. Someone must put this in their faces.
I don't do UI. I am at the mercy of Firefox browser developers to inform
the users of the problem. They have chosen to bother you about it rather
than to bother the end users about it. That doesn't make me any happier
than it makes you because the users who remain unaware of the problem
will continue not to pull on the ropes between themselves and their server
sys admins, and you complain to me, not to the Firefox developers who
chose to annoy you.
I repeat:
Matt McCutchen
> > Direct your energy at the problem you want to solve. Talk to some server
> > admins. Ask them why they are reluctant to take action. Find some real
> > industry representatives. Ask for their help. The first thing they need
> > from you is a convincing argument that this is real problem.
>
> Good plan, we've been at that process since last September.
> http://www.google.com/search?q=ssl+tls+"project+mogul"
Umm... I see lots of mentions of the "Project Mogul" name but no
definitive project page giving the status of the PR effort. A more
specific link, please?
--
Matt
Matt McCutchen
> > It's not going to look so great for Mozilla when another prominent
> > browser vendor ships another patch which also notifies the user of the
> > insecure connection.
> >
> Mozilla is phasing in, just like Opera. You can see some in the list is
> violently opposed to any kind of notification.
Does that mean you have accepted those people's arguments? Don't
equivocate.
--
Matt