On May 25, 2:24 pm, Wan-Teh Chang <w...@google.com> wrote: > On Tue, May 25, 2010 at 11:06 AM, Marsh Ray <ma...@extendedsubset.com> wrote: > > But by that logic, the client should refuse to handshake at all with a > > non-RFC-5746 server. (In reality that eventually needs to become the > > default behavior). > > I agree. A strict client should refuse an initial handshake with a > legacy server. If a client is willing to perform an initial handshake > with a legacy server, it should also be willing to perform a renegotiation > initiated by that server.
I agree with both points. > To answer Matt's original question: yes, it is intended to throw a > roadblock into the use of vulnerable servers to force them to upgrade. > I believe another rationale is that a legacy server can also be made > not vulnerable by disabling renegotiations, so if a legacy server > initiates a renegotiation, it is definitely vulnerable. That is really the same rationale: the renegotiation proves to us that the server is vulnerable, so now we refuse to continue talking to the server. This behavior does /not/ help protect the user from attack, since it applies only to a scenario different from the attack scenario. All it does is prevent the user from getting work done until one of the following happens: 1. The server gains RFC 5746 support. 2. The server is reconfigured so that the particular request the user made can be completed without renegotiation. This does /not/ mean the server is no longer vulnerable, because there may still be other situations in which it initiates renegotiation. 3. The user adds the server to security.ssl.renego_unrestricted_hosts after realizing that he does not lose any security by doing so. Experience tells me that #3 is the most likely outcome. Under that assumption, the behavior has bought us nothing compared to a good UI warning (bug 535649), it has only annoyed the user. Thus, I propose to remove the client code that refuses legacy renegotiation and, with it, the preferences security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref and security.ssl.renego_unrestricted_hosts . I will file a bug. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
