Re: [TLS] TLS or HTTP issue?

[Michael D'Errico <[e-mail]>]

Marsh Ray wrote:
> Nikos Mavrogiannopoulos wrote:
>> the application layer
>> cannot distinguish between the two sessions (one before renegotiation,
>> one after). The problem was for me that you could receive any amount of
>> application data even after a rehandshake was requested, thus I had to
>> cache them and present to the application after rehandshake was finished.
> 
> Yes, yes!
> 
> The buffered stream IO model we all take for granted is insufficient to
> represent the semantics of a TLS connection in the presence of
> renegotiation!

My server works a bit differently; it does what I'll call "lazy
renegotiation."  If it receives a ClientHello for a renegotiation, it
calculates all of the response handshake messages and puts them into
the outbound queue for delivery to the client.  It will happily continue
sending application data to the client and also receiving and passing
application data back to the application while the pending TLS session
is in this uncompleted state.  I believe this is what the TLS spec
intended.

If the client continues with the handshake, those messages are processed
as they are received, and the pending TLS session moves closer to
completion.  It is possible for the client and/or server to end up with
two different active sessions -- one based on the renegotiation, and one
based on the original handshake.  This would happen if one side fails to
send a ChangeCipherSpec and Finished message.

So the question becomes: should this be a legal state to be in?  I could
add some logic to disallow the sending of application data over a newly-
installed renegotiated session until the peer has completed its side of
the handshake.  But it should probably be allowed to continue receiving
application data over the old session since it could have been in transit
prior to sending the Finished message.

I think a good addition to my API would be to have a callback that tells
the application when a renegotiation has completed, and to also pass back
any application data that was received under the old session, but not yet
read by the application.

There is another weird possibility that should probably be prohibited:
if for some reason a ChangeCipherSpec is received during a renegotiation,
but not followed immediately by a Finished message, the receipt of any
application data should cause a handshake failure.

Mike



> Even with an added callback for cert validation, ambiguities linger!
> 
> I think it highly probable that real vulnerabilities exist in
> applications due to this mismatch.
> 
> The draft-rescorla-tls-renegotiate extension should help quite a bit though.
> 
> - Marsh