Re: Encrypting record headers: practical for TLS 1.3 after all?
2015-11-28 12:05:24 GMT
On 2015-11-28 12:30, Kriss Andsten wrote: > On 27 Nov 2015, at 17:21, Henrick Hellström <henrick <at> 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.(Continue reading)