Re: Purpose of refusing to renegotiate with non-RFC-5746 servers

2010-05-25 Thread Marsh Ray
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

Re: Purpose of refusing to renegotiate with non-RFC-5746 servers

2010-05-25 Thread Marsh Ray
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

Re: Purpose of refusing to renegotiate with non-RFC-5746 servers

2010-05-25 Thread Wan-Teh Chang
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

Re: Purpose of refusing to renegotiate with non-RFC-5746 servers

2010-05-25 Thread Matt McCutchen
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).

Purpose of refusing to renegotiate with non-RFC-5746 servers

2010-05-20 Thread Matt McCutchen
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