Re: [TLS] TLS or HTTP issue?

[Nikos Mavrogiannopoulos <[e-mail]>]

Martin Rex wrote:

> For re-negotiations, the following requirement from
> rfc5246 6.2.1. Fragmentation  (last paragraph):
> 
>    Note: Data of different TLS record layer content types MAY be
>    interleaved.  Application data is generally of lower precedence for
>    transmission than other content types.  However, records MUST be
>    delivered to the network in the same order as they are protected by
>    the record layer.  Recipients MUST receive and process interleaved
>    application layer traffic during handshakes subsequent to the first
>    one on a connection.
> 
> Provides and interesting additional challenge, and documents that
> at least some of the original protocol designers didn't sufficiently
> reflect on the implications.
> 
> Similarly rfc-5246, 7.4.1.1. Hello Request
> 
>       Since handshake messages are intended to have transmission
>       precedence over application data, it is expected that the
>       negotiation will begin before no more than a few records are
>       received from the client.  If the server sends a HelloRequest but
>       does not receive a ClientHello in response, it may close the
>       connection with a fatal alert.
> 
> I think it is underspecified what "interleaved application data
> and handshake messages" and "handshake message have transmission
> precedence over application data" is supposed to mean, and
> what kind of signalling would be necessary between the
> TLS protocol stack and the application caller in order
> to convey the underspecified semantics unambiguously.

Actually as far as I remember this was the most tricky part of TLS (any
version) to implement in a sensible transparent way. Moreover the way I
have implemented it, although not so transparent, 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.

[...]

> From the original design, and in the two quoted paragraphs above,
> it appears that SSL and its successor TLS was intended to be
> _very_ transparent, and the spec contains guidance for
> security-relevant signaling to the application only for
> the initial TLS handshake on a connection (full initial handshake,
> and session resume), but _NOT_ for the session renegotiation.
> 
> Therefore, I think, we do have a real shortcoming of the
> SSL/TLS protocol, and we really should scramble to fix it.
> 
> That includes improving on the guidance for the signaling
> and semantics of a TLS session renegotiate of the TLS
> protocol stack to the application -- in a fashion so that
> it can be folded back into rfc5246bis.

I agree this part of TLS needs to become more clear in semantics and
more strict in specification. For example what has to be done by a
client if a handshake request was received. Currently some client may
ignore it. How long is the server going to wait to understand that it
was ignored and no reply is expected?


regards,
Nikos