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 failu
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
>>
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 som
On 30/11/2009 22:47, Kyle Hamilton wrote:
On Mon, Nov 30, 2009 at 1:07 PM, Ian G wrote:
I agree. It breaches that fundamental law of the Iang's mind-space: there
is only one mode, and it is secure. Break the law, time folds and inverts
on itself, and Mallory slips between your bytes.
'secur
Good article!
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 the design of renegotiation, or
b) It's the fault o
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 the design of renegotiation, or
b) It's the fault of the applications that assume (incorrectly) that all
sessions
On Mon, Nov 30, 2009 at 1:07 PM, Ian G wrote:
> I agree. It breaches that fundamental law of the Iang's mind-space: there
> is only one mode, and it is secure. Break the law, time folds and inverts
> on itself, and Mallory slips between your bytes.
'secure' is a state of mind, not too different
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 A
On 2009-11-30 10:50 PST, Rob Crittenden 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.
I hope you realize that there's no difference in vulnerability between
client initiated and server initiated ren
On Mon, Nov 30, 2009 at 10:50 AM, Rob Crittenden 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 called when an SS
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 following:
11 matches
Mail list logo
