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.
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
