I'm considering how to handle SSL re-negotiation in the Apache NSS
provider mod_nss to handle the SSL client-initiated handshake bug.
NSS provides a callback, SSL_HandshakeCallback(), which according to the
docs is called when an SSL handshake has completed.
So let's say I have the
On Mon, Nov 30, 2009 at 10:50 AM, Rob Crittenden rcrit...@redhat.com wrote:
I'm considering how to handle SSL re-negotiation in the Apache NSS provider
mod_nss to handle the SSL client-initiated handshake bug.
NSS provides a callback, SSL_HandshakeCallback(), which according to the
docs is
On 30/11/2009 20:46, Kyle Hamilton wrote:
interesting description folded.
Apache's willingness to do per-Location/per-Directory/per-Whatever
renegotiation for client authentication is what forced us into this
situation in the first place. I believe it should be considered a
bug, and fixed on
On 11/30/2009 11:47 PM, Kyle Hamilton:
Twitter was breached. Before they disabled renegotiation on their
servers, the status message POST update was POST [...], and then their
Basic-encoded username and password. Someone injected prior bytes
before allowing the renegotiation, and every time
On 2009-11-30 20:26 PST, Eddy Nigg wrote:
On 11/30/2009 11:47 PM, Kyle Hamilton:
Twitter was breached. Before they disabled renegotiation on their
servers, the status message POST update was POST [...], and then their
Basic-encoded username and password. Someone injected prior bytes
before
On 2009-11-30 19:18 PST, Ian G wrote:
Good article!
Thanks.
On 01/12/2009 01:38, Nelson B Bolyard wrote:
There are two schools of thought about the vulnerabilities related to
the use of renegotiation in SSL 3.x (including TLS 1.x). Briefly, they
are: a) It's SSL/TLS's fault, a failure in
6 matches
Mail list logo