Mark M.
2003-08-28 18:23:40 UTC
Hi Folks - (in particular Vishal Mishra & John Banes from MS...)
A question regarding SSL session key renegotiation in SChannel.
(FYI - Vishal has previously pointed out that in fact CLIENT-side initiated
Session Renegotiation is NOT supported by SChannel on W2K(before SP5) or WXP
(before SP2). The first time thats been mentioned anywhere by MS AFAIK)
Anyway - here goes for SERVER-side initiated Renegotation (the usual
scenario...)
Question: How are Encrypted Application Layer Records from the server
handled by an Schannel client
during a Session renegotiation?
Detail:
1. A server requests a renegotiation by sending a HELLO_REQUEST, that the
clients DecrpytMessage() recognises by returning SEC_I_RENEGOTIATE.
2. The client can then kick off a new handshake loop at its leisure (the
server MAY enforce the renegotiation, or it may not). The client could in
fact ignore the request...lets say it'd like to comply.....
3. The client makes repeated calls to InitializeSecurityContext() during the
handshake loop, the first one passing in empty buffers & building a
CLIENT_HELLO, which it sends back to the server begin the renegotiation
proper.
4. The client read() 's data returned by the server & passes it into
InitializeSecurityContext() until complete....
BUT: PROBLEM: When a client is in a "handshake loop" in it is entirely
possible to read()
application layer records (not "handshake" records) "from-the-wire" -
sent by the server before IT received the
initial CLIENT_HELLO.
If the SDK samples are followed, these records will all be handled by
InitializeSecurityContext().
This works fine if the records are indeed all handshake records, but
what is InitializeSecurityContext()'s behaviour if passed in data that
contains an application layer record encrypted
with the "old" session keys?
There is no reason for the server NOT to continue sending encrypted data
having requested a renegotiation, as it is allowed for the client to ignore
the renegotiate request!
Of course once the server receives the CLIENT_HELLO - it should stop sending
further encrypted data.
One _could_ have a look at the records as they come in (during the handshake
loop) & explicitly check for handshake type messages
[first byte in the record - 0x17 for application layer data, 0x16 for
Handshake messages]
Then pass any App records to DecryptMessage, until we get a Handshake
message, at which point we continue
with our InitializeSecurityContext loop as normal.
[ Even then - whats to stop the Handshake message being another
HELLO_REQUEST, which is properly handled by DecryptMessage ???? ]
But isn't the API supposed to take care of that kind of stuff.....?
Any further insight would be much appreciated. .......(a bit long I know -
but then again what do you expect with such an unwieldy API.....)
Thanks a lot folks
Regards......................Mark.
A question regarding SSL session key renegotiation in SChannel.
(FYI - Vishal has previously pointed out that in fact CLIENT-side initiated
Session Renegotiation is NOT supported by SChannel on W2K(before SP5) or WXP
(before SP2). The first time thats been mentioned anywhere by MS AFAIK)
Anyway - here goes for SERVER-side initiated Renegotation (the usual
scenario...)
Question: How are Encrypted Application Layer Records from the server
handled by an Schannel client
during a Session renegotiation?
Detail:
1. A server requests a renegotiation by sending a HELLO_REQUEST, that the
clients DecrpytMessage() recognises by returning SEC_I_RENEGOTIATE.
2. The client can then kick off a new handshake loop at its leisure (the
server MAY enforce the renegotiation, or it may not). The client could in
fact ignore the request...lets say it'd like to comply.....
3. The client makes repeated calls to InitializeSecurityContext() during the
handshake loop, the first one passing in empty buffers & building a
CLIENT_HELLO, which it sends back to the server begin the renegotiation
proper.
4. The client read() 's data returned by the server & passes it into
InitializeSecurityContext() until complete....
BUT: PROBLEM: When a client is in a "handshake loop" in it is entirely
possible to read()
application layer records (not "handshake" records) "from-the-wire" -
sent by the server before IT received the
initial CLIENT_HELLO.
If the SDK samples are followed, these records will all be handled by
InitializeSecurityContext().
This works fine if the records are indeed all handshake records, but
what is InitializeSecurityContext()'s behaviour if passed in data that
contains an application layer record encrypted
with the "old" session keys?
There is no reason for the server NOT to continue sending encrypted data
having requested a renegotiation, as it is allowed for the client to ignore
the renegotiate request!
Of course once the server receives the CLIENT_HELLO - it should stop sending
further encrypted data.
One _could_ have a look at the records as they come in (during the handshake
loop) & explicitly check for handshake type messages
[first byte in the record - 0x17 for application layer data, 0x16 for
Handshake messages]
Then pass any App records to DecryptMessage, until we get a Handshake
message, at which point we continue
with our InitializeSecurityContext loop as normal.
[ Even then - whats to stop the Handshake message being another
HELLO_REQUEST, which is properly handled by DecryptMessage ???? ]
But isn't the API supposed to take care of that kind of stuff.....?
Any further insight would be much appreciated. .......(a bit long I know -
but then again what do you expect with such an unwieldy API.....)
Thanks a lot folks
Regards......................Mark.