Why does APT not use HTTPS? (whydoesaptnotusehttps.com)

If they allocate it for the whole connection, then all they get is a total, which still gives the attacker some information (there's a limited combination of packages that sum up to that number).

That said, pipelining over https is surely possible to, and reduces the risk.

That said, if you're installing security updates automatically, as you should, anyone will know anyway, as there are only about 3-5 possible combinations of updates you'll be downloading on a particular day in one session.

Not impossible, just marginally harder (if timing attacks can be though of as "hard").

Keeping your specific packages of choice in secret does not buy you anything anyway. The attacker with access to your traffic will always knows, when you perform system updates, which is more important than names of specific packages.

Anyway, I assume there are very few (if any?) scenarios with no way to overcome such bug in broken proxy (yes, after that exhausting investigation, but still) and there are obvious potential benefits in scenario when such middlebox does its work well.

With TLS (as I understand it) those potential benefits as well as potential bugs are just tossed away together (I'd not use therm 'bypassed' here) and every single download is forced to be made along full wire length, what could be pretty nasty in some locations. Eric Meyer recently wrote interesting article [0] on this topic. (I understand it is all quite obvious stuff, but well expressed IMO.)

[0] https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... [0][HN] https://news.ycombinator.com/item?id=17707187

I'm seriously tempted to start flagging links that point to "bad"/"outrage" bugtracker decisions like this, wide public distribution seems to make things quite a bit worse.

Oh and we haven't even addressed that their "secure signing" doesn't also protect first installs that could be insecurely downloaded.

[1] https://fai-project.org/

Debian could get the certificates, but getting the certificates was never the issue -- some CA would be happy to issue certificates for little or no cost to help Debian and gain mindshare. Coordination between 3rd party, volunteer mirror owners and the Debian organization is the issue.

What kind of CPU and traffic patterns are you using to hit 10 gbps of TLS protected traffic?

Now multiply that by the 1000 or more projects that each mirror syncs content from, all with something different because nothing standard exists.

LetsEncrypt is great, I love it, I have 10's of certs for personal stuff from them. I think they've completely changed the CA landscape, hopefully forever.

However I'll say it again, LetsEncrypt does not solve this problem. That's OK. LetsEncrypt doesn't have to solve every problem with TLS!

I still don't see how that would be a problem Debian should consider in their considertions around SSL. After all, if your server's upstream is blocks access to Let's Encrypt servers, why are you trying to operate an official Debian mirror there? What's the point of having a Debian mirror connected to such a shitty upstream?

Erm, what?

The number of people, who can listen to (much less — modify) your traffic is very small. It is basically your ISP (who is supposed to offers you services in good faith, not spy on you) and a number of engineers, who maintain Internet backbone. That's far from "everyone". Some SSL evangelists make it sound like everyone's traffic is permanently broadcasted to everyone else in the world, but it is not.

As for "vulnerable packages", the most certain sign, that someone does not install security updates, is lack of traffic between them and update servers. But that's orthogonal to use of encryption.

1. I gain access to a router near you.

2. I rent a sizable server at the hetzner/ovh/… location that's closest to you and volunteer to run a mirror for the OS you're using.

Both are somewhat uncertain (your traffic might flow via a different route, you might be load-balanced to a different mirror) but the uncertainty seems comparable. Option 2 seems so much easier that I have a real problem seeing the point of even attempting option 1 if all I want is the information option 2 would give. Perhaps someone can explain?

1) TLS session negotiation leaks all sorts of useful data about both systems, not to mention TCP and IP stack on which it sits. This data is grabbed in 5 minutes with an existing firewall filter. Combined with IP, it shows the exact machine and web browser (incl. Apt version) downloading the file in many cases.

2) It does nothing to prevent time, host and transfer size fingerprinting.

3) Let's Encrypt helps with deployment but you get rotating automated server certificates. It is reasonably easy to obtain a fake Let's Encrypt certificate so without pinning it is worthless for authentication, pinning a rotating certificate is hard too.

Debian does not have resources to handle impostor mirrors.

it would be great to have the ability to have https but for APT in its current form and for what it is used the cost benefit for adding https is not that compelling to me.

You might want to think about existing surveillance systems. Analysis of telephone traffic is often done purely on the CDR (the caller, callee, and length of call, in simple terms) without the equivalent of deep packet inspection to read the HTTP request, which would be analysis of the actual audio data themselves. The HTTPS case would likewise need just the total octets transferred over the TCP connection for fingerprinting.

There's a lot of glib handwaving in this discussion about identical sizes, not based upon actual measurements of the Debian archive. I quickly looked at the package cache in one of my Debian machines:

    jdebp% ls -l|awk 'x[$5]++'
    -rw-r--r-- 1 root root      3314 Feb 16  2018 nosh-run-freedesktop-system-bus_1.37_amd64.deb
    -rw-r--r-- 1 root root     35190 Dec 14  2016 redo_1.3_amd64.deb
    -rw-r--r-- 1 root root   1114546 Feb 25  2018 udev_232-25+deb9u2_amd64.deb
    jdebp %

So the remaining question is how much HTTP pipelining ameliorates this, which no-one here has yet actually analysed.

1) You're building a botnet (or, these days, are crypto mining). In that case you're not targeting a specific machine, you just want many of them.

2) You want to exfiltrate information from a host, or sabotage it. In that case you're targeting a specific machine.

I'd argue that in both cases, the proposed attack vector of inferring installed software versions through apt downloads is inferior, or at least more involved. In case 1) you're better off scanning for known vulnerabilities or make use of shodan and the likes. In case 2) you're probably going to probe the server anyways. It might take a little more time than if you just had a complete list of installed packages and their version (given you were somehow able to eavesdrop on the host in the first place), but you'll most likely determine at least what OS is running and what technology stack their internet-facing services are running on after some nmapping.

Or, looking at it from the other perspective, I wouldn't really feel much safer if apt were using https. I'm not against it, but I don't think it's a priority, especially if it needs a lot of coordination between different people, which always turns out to be very time consuming. Just being fast with updating packages seems a better investment of that time.

B: if the packages are concatenated to each other and a random length noise string, we can substantially frustrate nation state / ISP level attackers to the point of forcing them to get this information from the endpoints themselves: Either end user, or the APT server must already have been compromised.

1) End user not yet compromised: in order to capture these, they must attack the APT server.

2) End user already compromised: on each update of all compromised users, information is sent to C&C, so this would produce lots of opportunity for attentive users to discover the implant.

When focussing on the APT, which would give the cleanest record of attack surfaces, the community can put man power on designing minimalist APT servers, and inspecting published deviations in communications can lead to uncovering 0days.

EDIT: changed disagree to agree, as I (incorrectly) thought you were arguing it would not make attacks more expensive, woops!

This sounds less like some sort of massively impossible barrier to overcome and more like a Project Euler problem, and one not all that far into the sequence, either.

One of the things you have to overcome if you want to think like a security person is that, yes, there are attackers that will put some effort into attacking you if you are a target of any consequence, certainly effort far exceeding what you just described. I've watched some people at the company I work for have to overcome that handicap myself. Yes, there are attackers that are not just script kiddies and actually, like, have skills and such.

Attackers won't jump through infinite hoops, but getting a foothold on a network somewhere where they'd like more access, seeing that they can watch a new system in your network getting provisioned, and cross-checking that against a list of known vulnerabilities by looking at package sizes would be boringly mundane for them, not something wildly exotic.

The thing to note here is that the only reason this seems easy is that there is tooling readily available for such a task. If you didn't have such tooling, you'd find it more difficult to implement then your HTTPS case even _with_ tooling.

The same principle applies to your HTTPS case. Your argument disappears as soon as there is tooling. That tooling only needs to be written once. Perhaps it already has been done and exists in the circles where people want to surveil apt users. One possible reason such tooling isn't widely available is that apt doesn't use HTTPS by default, and one outcome may be that if apt switched to HTTPS the tooling would appear.

I have half a mind to write the tooling and publish it just to eliminate this argument. It really isn't very difficult.

The argument that https obfuscates which packages you download is not a good one, and may cause users to unnecessarily worry about the implications (and conversely, that they end up "more safe" if that was not the case). If that type of privacy is desirable you should probably use something like Tor.

He didn't mean these file sizes specifically. it would still apply just the same with different file sizes

i.e. create cutoffs every 50 or 100kbyte

Transferring apt packages over tor is unlikely to ever become the default, so it's worth trying to improve the non-tor default.

There are still timeout issues with the buffering, but it is a lot weaker defense.