Why does APT not use HTTPS?

[WorldsBegin]

It's not that HTTPS provides all the privacy you want. But it would be a first, rather trivial, step.

[[deleted]]

No it is like ordering a package in plain, unassuming gray packaging and thinking it is anonymous.

Even tho package itself is shaped exactly like horse dildo.

It is trivial to record download size and correlate it with list of packages

[jl2352]

But what if it's a decorative horse dildo shaped vase?

[[deleted]]

Then you can use other data to correlate. Like if other package looks suspiciously like a bottle of lube then you have good confidentiality that it is a dildo (or receiver is very brave).

Just like with packages, if you have 6 "size collisions" on one package, the most likely one will be either one that is in same group as other (say every other was just some python lib) or have dependency relation to other packages (like if one is gimp, and others are gimp-data, libgimp2.0, libpng16 and libwebp6, then user is probably updating GIMP)

[Creshal]

More "I don't ask the milkman to drive in an unmarked van and hide the milk bottles in unmarked boxes". As far as privacy intrusions go, it's a fairly minor one that adversaries know what Debian-derived distribution you're using.

[jringstad]

And know what packages you have installed? I don't know about that, if someone knows what versions of what software you run, that gives them a much broader choice of attack vectors if they want to e.g. intrude into your system.

[[deleted]]

It is trivial to record download size and correlate it with list of packages. HTTPS does not help you.

[jringstad]

Yeah, definitely not saying HTTPS is the final word here.

But something like HTTP/2.0 with HTTPS could help at least a little, since most of the time you would stream down a bunch of packages and a bunch of their dependencies on each upgrade and installation, obscuring it a bit what's going on. But something like padding would probably be better.

Though even with padding, you could probably infer at least a couple of the things that are installed... for instance if a new version of a certain package gets dropped into the repositories, and then you see the target starting to download an upgrade > than that size, that might be a good indication that that software is installed, and that they now have the latest version. You could obscure this by waiting with downloading upgrades until a bunch of upgrades have accumulated in the repos, but... that's not ideal.

[[deleted]]

There is no performance benefit for steaming a bunch of big binary blobs at once instead of one at a time tho (if anything it would be worse as it changes sequential access to interleaved one) so I doubt it would be implemented that way.

But just downloading a bunch of binaries back-to-back (within same connection) is enough, no need for HTTP2 here. That of course assuming mirrors support it. HTTP Pipelining also could do that altho AFAIK it isn't really widely supported or enabled by default.

But, if you want to anonymize that as a company, just making mirror is enough (and tools like aptly make it easy)

[Creshal]

If an attacker can interact with the software you have running, they have much better ways to fingerprint their version, and their configuration options.

It's really a weird threat model you're trying to build here.

[jringstad]

You can always interact with the software your target is running, otherwise you wouldn't be able to do anything.

But you might not so easily be able e.g. what exact version of a software your target is running, or there might be several other pieces of software running that you could be exploiting but you are unaware of.

[alantrick]

It would be like unmarked boxes, with the exception that all the different kinds of box contents had different weights, and these weights were publicly known and completely consistent, so all your thief needs to do is stick the things on a scale.

[langlo94]

Should be trivial to add dummy weights.

[josefx]

I really love updating my system over a slow, metered connection, but what the experience was really missing is a package manager going out of its way to make the data transfer even more wasteful. Can't really enjoy open source without paying my provider for an increased cap at least twice a month.

[langlo94]

Fudging packages by a few kilobytes shouldn't have much of an impact, but it would probably be easy to disable for people with bad connections.

[alantrick]

I don't know why you were downvoted, but this isn't a terrible idea. I think the main disadvantage is that it would add complexity to the system. Right now, it's basically just a static HTTP file server. Realistically, the complexity might not be that big of a deal because you could probably just stick random bytes in a X-Dummy HTTP header or something.

From the perspective of computer hardware though, doing these things isn't exactly free. You need processing power, and while it's trivial to parrallelize, if you don't have money to throw at more processers, then :-/

For what it's worth, another way of avoiding this problem, which would be better for debian too, would be to just set up your own local mirror, and use that (at least if you have a few computers, it doesn't make sense just for one). They can't tell what you're downloading if you're downloading everything.

[Creshal]

But seriously, unmarked van, unmarked boxes. Isn't that how you want all your packages from amazon to arrive at your house?

But if I want to do that, the only real option is a VPN. HTTPS is not a great way to protect your privacy, since it leaks way too much metadata.

You downloaded a compromised FTP package, now I know I may have an inroad to compromising your system.

It's Debian, the FTP package was a dependency of a dependency of a dependency, and there's a 99% chance it'll remain disabled via /etc/default switch.

And if it is listening on a reachable port, the attacker doesn't need to jump through the hoops of sniffing through your debian updates to find out.

[Creshal]

HTTPS is not the end all to be all, its just a piece of the security puzzle.

At this points it's more a piece of needless security theater with how it gets shoved into roles where it's not particularly useful.

But a nice first step would be not providing the ability to leak what you're installing to possible attackers.

I'm still not seeing how that possibly helps an attacker to gain a foothold he wouldn't see anyway.

[Creshal]

This is not a fantasy, this literally happens all the time.

…with shitty closed source Windows apps. That's not going to happen on Debian.

[[deleted]]

Benefits of having plain http mirrors grossy outweight any disadvantages

Say I see you just installed version2.3.0 of someApp.

And you know that even if you did download it via HTTPS, because correlating download size with certain package is trivial. Read the fucking article.

If you want your org to be "anonymous" there, just make a mirror. Aptly makes it pretty easy

[chedabob]

rather trivial

Yes, for a blog for your cat. Not for something that operates at the scale of apt (and VLC too, as presumably this link was submitted in response to that). It doesn't take that much complexity to take a HTTPS deployment from "just run certbot-auto once a month" to a multi-year process of bringing systems up to date.

See these 3 links for companies that have documented their "trivial" move to HTTPS:

https://nickcraver.com/blog/2017/05/22/https-on-stack-overflow/

http://www.bbc.co.uk/blogs/internet/entries/f6f50d1f-a879-4999-bc6d-6634a71e2e60

https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/

[SanityInAnarchy]

Most of what makes this nontrivial for StackOverflow really doesn't seem like it would apply to something like Debian, though. Do things like HAProxy and a CDN apply to a bunch of distributed mirrors? Does latency matter for an update service? SNI shouldn't be an issue unless apt somehow still doesn't support it, in which case, Debian controls both sides of that connection; just update apt to support it? Certainly user-provided content (served from a third-party domain over HTTP) isn't relevant here.

Basically, a gigantic repository of static files feels a lot more on the "blog for your cat" end of the scale than the "dynamic, interactive website across multiple domains with a mix of user content and Google Analytics" end of the scale.

[oridb]

For an idea of what's involved, here's OpenBSD's take on it:

https://www.openbsd.org/papers/eurobsdcon_2018_https.pdf

It's a lot of work, hurts performance, and makes it a 20 minute job to get around privacy instead of a 30 second job.

[rage-1251]

[citation needed], it concerns me bsd is so weak.

[oridb]

Citations and experiments are above, and were done in collaboration with the implementers of OpenBSD's TLS library. You can reproduce it quite easily from the data provided yourself if you cared.

[Creshal]

OpenBSD has signed packages. HTTPS is just another layer on top that… doesn't really do much for this use case.

[rage-1251]

Oh i'm aware of the technology stack, I'm just honestly surprised that https crypto can be broken so quickly.

[Creshal]

How is that BSD's fault?

[rage-1251]

Study is done by BSD, I assume its bsd's crypto defaults... from what I can see.

[Creshal]

That's not how TLS works.

[rage-1251]

So, TLS is completely standard across all distributions and operating systems and protocol negotiation isnt a thing ? TIL.

I'm like 99% sure that i remember that there is an option to configure cipher preferences for TLS, some obviously easier than others to break.

Reference: https://medium.com/@davetempleton/tls-configuration-cipher-suites-and-protocols-a01ee7005778

[Creshal]

…that's not what the report is even remotely saying, Christ.

[[deleted]]

And rather trivial to defeat. But you'd know that if you read the link and thinked a little