> 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.
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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
