Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> Well, if the remote endpoint allows you to initiate a renegotiation. MS
> IIS for example responds with a TCP RST, other implementations may be
> less direct.

>From what Nico said in earlier messages about the Programming Model
for Microsoft's TLS implementation (schannel SSP), the code above
SSPI must know an implement a lot of TLS message flow.

According to that sketch, performing a TLS handshake requires a significant
amount of code above SSPI, and performing a TLS renegotiation requires
an awful huge amount of code above SSPI.  I have never used schannel
myself (and haven't found programming examples yet), but it seems
that the app on top of SSPI _must_ know whether incoming data is
application data, protected application data or handshake messages
and pass each of them to distinct SSPI calls or get an error.
The return calls of those SSPI functions probably indicate which
call to do next (or which kind of data to expect next).

So an app on top of SSPI using the schannel SSP might not expect
the client to request rekeying at arbitrary times during communication
and that unexpected (protected) ClientHello handshake message is then
passed to a Message-unprotection call of SSPI where it is rejected.
When that happens, the server seems to terminate the session
(delete the security context) and close the socket/connection,
which might be the reason why you receive a TCP RST.


Nico also mentioned, that with SSPI, the renegotiation context
uses a different/seperate context handle that the original context.

Which seems to imply, that for a TLS renegotiation by the app on top
of SSPI, the app has to call the message protection/unprotection
calls of the previous context for the initial handshake messages
of the new context -- until the Interator Function(s) indicate
that this is no longer necessary (because ChangeCipherSpec has
been sent).

If TLS renegotiation actually works like this in SSPI, then
an SSPI app is actually playing the MITM-Attack every time
that it renegotiates (i.e. it would perform the MITM-Attack on
its own TLS stack).

-Martin