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

[Nasko Oskov <[e-mail]>]

Martin Rex wrote:
>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).

It is the return codes from the different APIs that tell you whether you should go back go negotiation or not. The application itself should never look at the actual packets and make decisions on their own.

>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.

That is not entirely true. If a client wants to renegotiate, they just call the proper API with the current context, which emits renegotiation and handshaking begins.

>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).

The way it works is that message protection/unprotection returns a special error code instructing the application to start handshaking again, using the same context.

>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).

It doesn't work this way, so you don't have to play the MiTM game itself. All the details are hidden behind the SSPI APIs and one has to just react based on return values.

Nasko