Drew DeVault via plug on 21 Sep 2019 19:55:07 -0700


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] The lock down?! Uhh.. why?


On Sat Sep 21, 2019 at 10:51 PM Philip Rushik via plug wrote:
> On 9/21/19, Drew DeVault <sir@cmpwn.com> wrote:
> > Even with HTTP 1.1, I'm sure timing attacks are trivial for separating
> > out the individual requests.
> 
> I have my doubts about this. If the same HTTP/TLS connection is shared
> for multiple downloads, how could one determine which 2+ files were
> downloaded? Even if the plaintext size was easy to determine from a
> cyphertext stream (which couldn't be the case unless you knew how long
> all headers/cookies/useragent strings were, which would only be
> possible under very specific circumstances), not knowing the _number_
> of requests per connection basically makes this nearly impossible.
> 
> That being said, if you can prove me wrong, that would be awesome. I
> would _love_ to see an attack like this in action, sounds awesome.

Do you understand what a timing attack is? Let's say that you observe
the following ciphertext, shown over time:

xx xxxxxxxx xx xxxxxxxxxxxxxxxxxxxxx xx     xxxxxxxxxxxxxxxxxxx

Yes, the whole may consist of several packages. But time is a factor
here.

xx xxxxxxxx      xxxxxxxxxxxxxxxxxxxxx xx     xxxxxxxxxxxxxxxxxxx
^ handshake
   ^ package A (x bytes)
           ^ delay for extraction
                 ^ package B (y bytes)

and so on.

> Isn't HTTP 2 a big mess with basically no real benefits? I doubt its
> ever going to be adopted.

No, HTTP/2 has real benefits for some use-cases, but mirrors are not one
of them. However, HTTP/2 offers multiplexing, which would help mitigate
timing attacks by mixing the streams of concurrent downloads.

> Yeah, true. However, I imagine most would use just curl, and [lib]curl
> most definitely is capable of this, although depending on the exact
> situation, it might take some effort to enable this behavior (although
> a LOT less than it would take to implement it without libcurl,
> implementing HTTP 1.1 is surprisingly complex).

Even with libcurl it requires a lot of application-level restructuring
to hold onto a persistent connection. You can't just set the right curl
option and get it for free.
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug