[[EMAIL PROTECTED] - Wed Nov 20 09:21:07 2002]:
Hi,
When trying to use sessions under 0.9.7 beta 4 I get:
1424:error:140920C5:SSL routines:SSL3_GET_SERVER_HELLO:old session cipher
not re
turned:.\ssl\s3_clnt.c:705:
This also seems to happen with s_server/s_client when specifying
[jaenicke - Wed Nov 20 10:01:23 2002]:
The change I made was that the cipher_id was compared instead of the
pointer to the CIPHER structure. This made the external caching
work fine (which I of course tested after the change) but made
the internal cache fail (which I did not test, because I
[levitte - Fri Nov 15 00:46:03 2002]:
This ticket looks resolved, so I'll mark it as such.
No, it is not resolved. There is a reliable workaround
(REUSE_CIPHER_CHANGE_BUG). As this is part of OP_ALL, the problem can
only arise for those few applications not enabling the default
workarounds.
[jaenicke - Fri Nov 15 09:38:15 2002]:
I will fix it over the weekend.
Ok, I have finally decided to go with the solution proposed by Steve
Haslam and perform the check based on the id instead of the pointer
to the cipher object (c-id != s-session-cipher_id).
Best regards,
Lutz
This ticket looks resolved, so I'll mark it as such.
[[EMAIL PROTECTED] - Wed Sep 18 16:07:15 2002]:
On Wed, Sep 18, 2002 at 04:03:26PM +0200, Steve Haslam via RT
wrote:
On Wed, Sep 18, 2002 at 09:18:22AM +0200, Lutz Jaenicke via RT
wrote:
Workaround: the problem is does not
Hi,
I'm working on putting SSL/TLS session caching into Exim, and I've almost
got it working, borrowing heavily from the mod_ssl dbm caching code.
The problem I'm getting is that when I reuse a session from the client side,
I get this:
Initialised TLS
DBM file record @192.168.254.1 suggests
On Wed, Sep 18, 2002 at 02:58:53AM +0100, Steve Haslam wrote:
So, according to ssldump, the cipherSuite entry in the ServerHello is the
same the second time round. Is it a problem that the client seems to be in
read server hello B state twice?
OK, can anyone advise me? Is ssldump really
On Wed, Sep 18, 2002 at 09:09:41AM +0200, Steve Haslam via RT wrote:
On Wed, Sep 18, 2002 at 02:58:53AM +0100, Steve Haslam wrote:
So, according to ssldump, the cipherSuite entry in the ServerHello is the
same the second time round. Is it a problem that the client seems to be in
read
On Wed, Sep 18, 2002 at 03:47:52AM +0100, Steve Haslam wrote:
SSL DEBUG HACK: s-hit=1, c=0x815217c (EDH-DSS-DES-CBC3-SHA),
s-session-cipher=(nil) ((NONE))
In fact.. (talking to myself again, sorry), I looked in d2i_SSL_SESSION(),
and it sets cipher to NULL, although it sets cipher_id. So is
On Wed, Sep 18, 2002 at 09:18:22AM +0200, Lutz Jaenicke via RT wrote:
On Wed, Sep 18, 2002 at 09:09:41AM +0200, Steve Haslam via RT wrote:
SSL DEBUG HACK: s-hit=1, c=0x815217c (EDH-DSS-DES-CBC3-SHA),
s-session-cipher=(nil) ((NONE))
maybe there's a problem with deserialising the
On Wed, Sep 18, 2002 at 04:03:26PM +0200, Steve Haslam via RT wrote:
On Wed, Sep 18, 2002 at 09:18:22AM +0200, Lutz Jaenicke via RT wrote:
Workaround: the problem is does not appear, when
SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG is enabled, which is part of
SSL_OP_ALL (see man
On Wed, Sep 18, 2002 at 09:18:22AM +0200, Lutz Jaenicke via RT wrote:
On Wed, Sep 18, 2002 at 09:09:41AM +0200, Steve Haslam via RT wrote:
SSL DEBUG HACK: s-hit=1, c=0x815217c (EDH-DSS-DES-CBC3-SHA),
s-session-cipher=(nil) ((NONE))
maybe there's a problem with deserialising the
12 matches
Mail list logo
