I'm writing an SSL client application, and I'm
having some problems with session resuming when
connecting to a Netscape server.
Here's what's happening:
1 - I send a v2 client hello message to the
server.
2 - The server returns a v3 server hello, we
agree on v3. Handshaking proceeds normally.
Since the random value sent with the v2 client
message was a 16-byte value, it's padded out with
opening zeros to make a 32-byte value. This
seems to work, because on the initial session
both the cipher and the MAC secrets generated
from that keyblock work.
3 - After completing handshaking and retrieving
a page, I try to resume the session by sending a
v3 client hello with the session ID in it, and a
new 32-byte client random value. The server
agrees to resume the session, sending back the
session ID and a new server random value. I
retrieve the master secret from the SSL cache,
and generate the keyblock again, using the
standard algorithm.
4 - When I try to read the finished message sent
after the server hello and change cipher spec
messages, the keys and MAC values generated are
invalid, and I can't read the finished message.
What's bizarre about this (and why I think that
it's not just my code for generating the keyblock
being wrong) is that
1 - If I initially send a v3 client hello, and
then resume it works just fine. It's only if I
initiate the connection with a v2 client hello.
2 - If I send a v2 client hello followed by a v3
client hello resume to a server running either
IIS or Stronghold (the other two servers I've
tested against) my code works just fine, and the
resume works OK. It's only Netscape servers that
this dies on.
I've tested against servers running both
Enterprise 3.6 and Enterprise 2.01c, and it
happens with both of those two.
So, does anyone know if Enterprise server does
something funky with that "finished" message and
its MAC during the resume. Are there any
workarounds? Am I just being stupid?
Thanks a lot,
ian.
Sent via Deja.com http://www.deja.com/
Before you buy.