Re: [TLS] TLS or HTTP issue?

[Martin Rex <[e-mail]>]

Bruno Harbulot wrote:
> 
> > 
> > So for me the issue is on HTTP's usage of the TLS protocol
> > renegotiation. After a TLS renegotiation for authentication the previous
> > command cache should have been cleared and reissued after negotiation.
> 
> I think you have a point, I'm not sure if it's HTTP as such that is to 
> blame, rather the assumptions made by the frameworks implementing it.

The ramification are amplificated by the HTTP 1.1 Connection:keep-alive
that allows pipelining of requests and results in asynchronous
processing of requests and replys.

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.


I wasn't remotely aware of the applicability for real world
scenarios beyond the command execution I suggested in my
description, when I wrote about an MITM attack scenario that
had briefly crossed my mind the night before, and for which
I had not found any indications in rfc5246 (scanning it for
about 20 minutes) that would stop it, before sending off the mail.

I had not realized that one could similarly proxy an initial TLS
handshake with a client into a renegotiate of the server and
things like the request-completion for the basic-auth based
or cookie-based authentications.

Marshs published research on the issue expanded my thinking about
susceptible scenarios significantly.  Excellent work, Marsh!
-- and thank you for all the research!

For the cookie-auth or basic-auth based scenarios depicted by
Marsh, the asynchronous processing of pipelined requests creates
interesting new opportunities.


"Clearing the command cache" might require a significant change
in some application protocol stacks.  In order to efficientl
process requests, and nowadays Connection: keep-alive pipelined
requests, there are often intermediate layers for the request
parsing that will combine and re-slice what comes out of
SSL, so that the application may efficiently process the
requests--including URL argument parsing, parsing the MIME-header,
parsing certain header fields (Host:,Cookie:,authorization)
and potentially code page translations/transformations.


When analyzing performance problems reported by a customer
3 years ago I noticed that their Apache reverse proxy 
(using SSL-reencryption into our backend software) was
tearing up the forwarded requests into pieces, forwarding
each line of the MIME-header of the request and the
empty newline into seperate SSL-records -- slowing down
the processing of the request significantly.


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


-Martin