Am 28.11.2015 um 13:05 schrieb Henrick Hellström:
On 2015-11-28 12:30, Kriss Andsten wrote:
On 27 Nov 2015, at 17:21, Henrick Hellström <henr...@streamsec.se>
wrote:
How, exactly, would this be significantly harder? The adversary will
still be able to tell when, and how much, TCP/IP data is sent
between the peers. If there happens to be a revealing TLS record
boundary in the middle of a TCP/IP packet, it would seem to me there
is an implementation problem rather than a problem with the abstract
protocol.
This is actually quite common. Even when it does align with packet
boundaries, it is providing known information rather than inferred
information ("here's a length X blob, then a length Y blob" vs
"Here's a bunch of packets whose lengths minus TLS headers amount to
to X+Y").
Maybe I have missed something, but this seems awfully implementation
dependent to me. Let's take a more specific example:
Suppose a web server is serving a request for a web page, which
typically means that the client firstly sends a single HTTP request
for the HTML page, and then multiple requests for the css, images, etc
in a row.
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?
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.
Regards,
Roland
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
