Re: Purpose of refusing to renegotiate with non-RFC-5746 servers
On 5/20/2010 7:20 PM, Matt McCutchen wrote: When security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref is off, Firefox will refuse to perform a server-initiated renegotiation with a non-RFC-5746 server. What is the purpose of this behavior? It doesn't mitigate the vulnerability because in the attack scenario, the client believes it is performing an initial negotiation. If the client goes ahead and completes the handshake, sending his client cert and/or cookies, he may be giving those authentication credentials to the bad guy's malicious request being buffered at the server. So even though (in this attack scenario) it's the server that sees the renegotiation, the client and server both have an equal interest in ensuring the security of the connection. - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Purpose of refusing to renegotiate with non-RFC-5746 servers
Arguing with myself a bit here. On 5/25/2010 12:06 PM, Marsh Ray wrote: On 5/20/2010 7:20 PM, Matt McCutchen wrote: When security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref is off, Firefox will refuse to perform a server-initiated renegotiation with a non-RFC-5746 server. What is the purpose of this behavior? It doesn't mitigate the vulnerability because in the attack scenario, the client believes it is performing an initial negotiation. If the client goes ahead and completes the handshake, sending his client cert and/or cookies, he may be giving those authentication credentials to the bad guy's malicious request being buffered at the server. 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). Seeing a server-initiated renegotiation from a non-RFC-5746 server is bad because you now know that the server is more than just theoretically vulnerable. I suspect that some of the security.ssl.* parameters may equally apply to server side uses of NSS, in which case it is clearly a useful mitigation. - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Purpose of refusing to renegotiate with non-RFC-5746 servers
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. 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. I suspect that some of the security.ssl.* parameters may equally apply to server side uses of NSS, in which case it is clearly a useful mitigation. Those parameters are Mozilla client preferences. None of the Mozilla clients (Firefox, Thunderbird, etc.) act as SSL servers. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Purpose of refusing to renegotiate with non-RFC-5746 servers
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
Purpose of refusing to renegotiate with non-RFC-5746 servers
When security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref is off, Firefox will refuse to perform a server-initiated renegotiation with a non-RFC-5746 server. What is the purpose of this behavior? It doesn't mitigate the vulnerability because in the attack scenario, the client believes it is performing an initial negotiation. If it is just intended to throw a roadblock into the use of vulnerable servers to force them to upgrade, I think that's inappropriate and would rather rely on a UI warning (bug 535649) as the sole means of evangelization for RFC 5746. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
