On 2015-11-28 17:41, Roland Zink wrote:
Most times, the latter row of requests could easily be encoded in a
single TLS fragment. This means that the server will become aware of
all of the requests at the same time, and might encode all of the HTTP
responses before beginning to encode the TLS fragments.
Even if it could be encoded in a single TLS fragment a simple minded
browser may encode it one by one. Also there are many more use cases
where such optimization may not work. Can you provide data what browsers
are actually doing for HTTP/1.1 and HTTP2?
AFAIK, HTTP 1.1 browsers typically don't send a new request over an open
connection, before it has received the response to the previous request.
If that is the case, it is trivial to get the message lengths from the
traffic, with or without encrypted TLS record headers. IOW you gain
nothing by encrypting the length fields.
Carefully implemented, such a solution would not necessarily require
significantly more resources to handle pipe-lining, compared to an
alternative solution that would serve, encode and send the responses
on-the-fly, and as a consequence quickly fill up the outgoing TCP/IP
queue.
I think it is more complicated so it will use more resources. You have
to weight what is more important, the additional "security" or the
"overhead". Anyway I thought the decision was to hide the record length.
You will have to make sure the peer is sending out a continuous stream
of encrypted messages, anyway, or else you will not gain much by
encrypting the TLS record headers. Relying on TLS fragments piling up at
the TCP/IP level, rather than at the application level or TLS level, is
not a reliable way to make traffic analysis harder. Even if the
responses to a specific pair of requests pile up 999 times of 1000,
there will still be a signal from the 1 in 1000 event that will be
detectable by traffic analysis.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
