> OTOH, wouldn't renegotiation change the session ID and thus avoid the
> problem? (I'm saying this without checking, but it seems the obvious
> thing to do).
Not always! This is the point I'm trying to figure out.
I had a cursory look at the OpenSSL code last night and all I could see
was that if the renegoitate flag for a connection (an SSL struct?) is
set then the handshake starts again with a blank session ID, forcing the
whole handshake to happen again and making the connection end up with a
new session at the end of it.
I'm trying to avoid doing the whole handshake again - I just want to
change the bulk cipher keys/IVs in use by the connection every now and
again and the SSL and TLS specs say this is done by using the client
hello message with the same session ID as the connection is already
using (see the client hello section).
What I'm really asing is are the ciphers held at session or connection
level? If at session level it seems pretty dangerous to change anything
about them as any connections that didn't expect the change will get
confused and if at connection level, what's the use of a session except
for connection setup? Maybe that is the only point to a session...
I just don't want to write a heap of code to do it one way and find all
other SSL implementations do it another... We solved the problem first
time around by making 1 connection per session and never doing a
renegotiate. :-\
--
Regards,
David Taylor
Forge Research
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
