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
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
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
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).
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
5 matches
Mail list logo