5 ms·

The other big problem is that people can see what you're downloading. Might not be a big deal but consider: 1. You're in China and you download some VPN softwa

The other big problem is that people can see what you're downloading. Might not be a big deal but consider: 1. You're in China and you download some VPN software over APT. A seemingly innocuous call to package server is now a clear violation of Chinese law. 2. Even in the US, can leak all kinds of information about your work habits, what you're working on, etc. 3. If it's running on a server, it could leak what vulnerable software you have installed or what versions of various packages you're running to make exploiting known vulnerabilities easier

omarforgotpwd 8y ago
Oh, another thing I just thought of: It could leak what vulnerable software you have installed / what version you're running to make exploits easier.
jlarocco 8y ago
Even with HTTPS, it's easy enough to figure out which package is being downloaded based on the download size, as explained in TFA. Every time this comes up, it's always the same handful of incorrect arguments made in favor of HTTPS. The cargo-cult mentality that HTTPS == security really does more damage than it does good.
- zaptheimpaler 8y ago
  I mean deducing the package from download size is way harder than just seeing the name in the open.. security is rarely perfect and more like an arms race, making things more difficult is a big deal. This kind of "you can hack Y too" argument doesn't make any sense if its way harder to hack Y than X.
  - jlarocco 8y ago
    I would agree with you IF it were actually "way harder", but realistically it's no more difficult than checking the file name or the md5 checksum.
  - gtsteve 8y ago
    What if keepalive is used and multiple packages are downloaded? Surely that is at least plausible deniability.
- wallunit 8y ago
  Is that even true? In practice rather than downloading a single package you'd download/update a bunch of packages over the same connection, and an attacker would only see the accumulated size, right?
  - pvorb 8y ago
    I'm not sure how APT handles connections, but with a typical browser connections will be reused if requests are made shortly after another. That doesn't mean it's impossible to determine what packages you downloaded. But it will be more effort to do so.
  - jlarocco 8y ago
    You can see when you run "apt-get install ..." or "apt-get upgrade" that it opens multiple connections to download packages... And the Debian contributor who wrote TFA says it's possible, and I'm sure he knows a lot more about it than I do.
- dcbadacd 8y ago
  Less with HTTP2/TLSv1.3, endpoints are also hard to detect with ESNI.
  - AstralStorm 8y ago
    No they aren't. HTTPS fingerprinting is easy. It's been done by lcamtuf years ago and it's available as a layer 7 filter in Linux... TLS adds more information because it prevents proxies and has specific server implementations.
loeg 8y ago
This is addressed in the "privacy" section. Basically, your premise is wrong. TLS does not provide additionally privacy for this usecase. The short summary is: the size of transmitted data makes inferring what you've downloaded from a public file mirror trivial for a passive observer, even with TLS.
- hopler 8y ago
  Perhaps apt should pad its downloads
  - loeg 8y ago
    Padding doesn't solve the privacy problem without unacceptable tradeoffs (i.e., pad all packages to the same size).
    - sattoshi 8y ago
      Pad all packages to the nearest in a list of sizes?
      - loeg 8y ago
        How many bits of privacy are you willing to give up here? Debian only has about 48,000 packages. That's almost 16 bits, total, with perfect privacy — all packages enlarged to the same size. You can select a list of sizes trading off collisions (2 packages with same size => 1 bit of privacy; 4 => 2 bits, etc). But the most you ever get is (nearly) 16. The amount of padding you need to even get 2 bits of privacy (giving up almost 14) on the long tail of large packages is going to be "a lot" and it grows as you want more bits.
        shasheene 8y ago
        Some further pros and cons of padding is discussed elsewhere in the thread. Providing privacy for the packages that, including dependencies, are less than 100MB in size is something that's probably worth doing. The cost of padding an apt-get process to the nearest say, 100MB, is not necessarily infeasible as far as bandwidth goes. Instead of padding individual files, how about a means to arbitrarily download some number of bytes from an infinite stream? That would appear to be sufficient to prevent file size analysis (but probably not timing attacks). Exposing something like /dev/random via a symbolic link and allowing the apt-get client to close the stream after the total transfer reaches 100MB would appear to make it harder to infer packages based on the transferred bytes, without being very difficult to roll out.

omarforgotpwd 8y ago

Oh, another thing I just thought of: It could leak what vulnerable software you have installed / what version you're running to make exploits easier.

jlarocco 8y ago

Even with HTTPS, it's easy enough to figure out which package is being downloaded based on the download size, as explained in TFA. Every time this comes up, it's always the same handful of incorrect arguments made in favor of HTTPS. The cargo-cult mentality that HTTPS == security really does more damage than it does good.

zaptheimpaler 8y ago
I mean deducing the package from download size is way harder than just seeing the name in the open.. security is rarely perfect and more like an arms race, making things more difficult is a big deal. This kind of "you can hack Y too" argument doesn't make any sense if its way harder to hack Y than X.
- jlarocco 8y ago
  I would agree with you IF it were actually "way harder", but realistically it's no more difficult than checking the file name or the md5 checksum.
- gtsteve 8y ago
  What if keepalive is used and multiple packages are downloaded? Surely that is at least plausible deniability.
wallunit 8y ago
Is that even true? In practice rather than downloading a single package you'd download/update a bunch of packages over the same connection, and an attacker would only see the accumulated size, right?
- pvorb 8y ago
  I'm not sure how APT handles connections, but with a typical browser connections will be reused if requests are made shortly after another. That doesn't mean it's impossible to determine what packages you downloaded. But it will be more effort to do so.
- jlarocco 8y ago
  You can see when you run "apt-get install ..." or "apt-get upgrade" that it opens multiple connections to download packages... And the Debian contributor who wrote TFA says it's possible, and I'm sure he knows a lot more about it than I do.
dcbadacd 8y ago
Less with HTTP2/TLSv1.3, endpoints are also hard to detect with ESNI.
- AstralStorm 8y ago
  No they aren't. HTTPS fingerprinting is easy. It's been done by lcamtuf years ago and it's available as a layer 7 filter in Linux... TLS adds more information because it prevents proxies and has specific server implementations.

loeg 8y ago

This is addressed in the "privacy" section. Basically, your premise is wrong. TLS does not provide additionally privacy for this usecase. The short summary is: the size of transmitted data makes inferring what you've downloaded from a public file mirror trivial for a passive observer, even with TLS.

hopler 8y ago
Perhaps apt should pad its downloads
- loeg 8y ago
  Padding doesn't solve the privacy problem without unacceptable tradeoffs (i.e., pad all packages to the same size).
  - sattoshi 8y ago
    Pad all packages to the nearest in a list of sizes?
    - loeg 8y ago
      How many bits of privacy are you willing to give up here? Debian only has about 48,000 packages. That's almost 16 bits, total, with perfect privacy — all packages enlarged to the same size. You can select a list of sizes trading off collisions (2 packages with same size => 1 bit of privacy; 4 => 2 bits, etc). But the most you ever get is (nearly) 16. The amount of padding you need to even get 2 bits of privacy (giving up almost 14) on the long tail of large packages is going to be "a lot" and it grows as you want more bits.
      - shasheene 8y ago
        Some further pros and cons of padding is discussed elsewhere in the thread. Providing privacy for the packages that, including dependencies, are less than 100MB in size is something that's probably worth doing. The cost of padding an apt-get process to the nearest say, 100MB, is not necessarily infeasible as far as bandwidth goes. Instead of padding individual files, how about a means to arbitrarily download some number of bytes from an infinite stream? That would appear to be sufficient to prevent file size analysis (but probably not timing attacks). Exposing something like /dev/random via a symbolic link and allowing the apt-get client to close the stream after the total transfer reaches 100MB would appear to make it harder to infer packages based on the transferred bytes, without being very difficult to roll out.