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 wrote: > On Tue, May 25, 2010 at 11:06 AM, Marsh Ray 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 sh

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 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 serv

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-

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

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