On 03/31/2010 05:26 AM, Eddy Nigg wrote: > [ 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. >
This issue has been debated extensively on the ieft mailing list. I suggest to read through all of those comments first. 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. This is problematic for 2 reasons: 1) there not an insignificant number of servers out which are not well administered. and 2) it's impossible for clients to tell whether or not a server will be vulnerable. The underlying assumption that "this is a server problem" is false. It's a protocol problem. We must determine that the server is using a sufficiently advanced protocol for us to be safe. > > 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. 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. What are you talking about? The default for this option is *OFF*.... for precisely this reason. We need to stage deployment of RFC 5746. Both clients and servers need to deal with the world that old protocols are out there for a time. > > 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. 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). > 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. 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. Otherwise we would have a much more aggressive schedule for deployment. 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
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
