12 ms·
It does not need HTTPS to be secure, but it would need HTTPS to add privacy, for which the protocol has none at the current time.
by arghwhat 8y ago
It does not need HTTPS to be secure, but it would need HTTPS to add privacy, for which the protocol has none at the current time.
- Arnt 8y agoYou're downloading form a third-party volunteer. What protocol can provide privacy given that condition?
- rhacker 8y agoInstead of JUST that third party knowing what (possibly vulnerable) packages you have, you are now letting everyone know what possibly vulnerable packages you have.
- altfredd 8y ago> you are now letting everyone know what possibly vulnerable packages you have. 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.
- DoctorOetker 8y ago"everyone" in this context obviously means everyone on the path, and any attackers that have compromised nodes along the path. See the Belgacom hack by 5 eyes...
- monocasa 8y agoAnd I those attackers can still tell everything based on the target IP and the payload sizes.
- DoctorOetker 8y agothere is no proof that this is true in general, so it is worth trying to find 1) an inefficient way in order to 2) postulate an efficient way... for example, overlay onion routing, size blurring by appending random length random bits,... with oblivious transfer even the APT-server does not know what you downloaded (but that would require a large amount of information..., nevertheless oblivious transfer might still be a useful tool when used as a primitive, perhaps just to send a list of bootstrap addresses for p2p hosting of the signed files etc...)
- arghwhat 8y agoThere is a huge difference between the third-party knowing what you're doing, and everyone in between knowing what you're doing. The HTTPS everywhere movements are attempting to make privacy the default rather than the exception, but are of course done knowing that the server will always know whats up. The point is to make it so that only the two parties concerned, the server and the client, comprehend the communication rather than the entire world
- Arnt 8y agoOkay, suppose I want to know what packages you're installing and updating. I have two routes: 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?
- arghwhat 8y agoYou'd have to take control over my mirror. Making a new mirror will not get you any traffic unless people actively choose to use it. Therefore, your option 1. is to control a part of the public route, and option 2. is to control the mirror of my choice. However, any argument against using encryption for privacy for APT can equally be applied to any other traffic. Do you trust your public internet route enough to let your traffic run authenticated, but unencrypted? Chats, news, bank statements, software updates? Even if content cannot be modified, it can still be blocked or made public. There are quite a few nosy governments that would like to know or block certain types of content, software packages included.
- AstralStorm 8y agoYou will instantly spot blocking because apt reports connection failure and hash failure and replay attack on update list is ineffective. As for privacy, eh? It is visible you're connecting to a debian mirror and what size of update list you're getting. Barring that, indexing packages by size is trivial. You want true privacy, you'd have to use Tor or such.
- Carpetsmoker 8y agoGenuine question: what are you doing with APT that requires privacy?
- arghwhat 8y agoNothing requires privacy. However, the HTTPS movement is about making privacy the default, not the exception.
- black-tea 8y agoThe HTTPS movement is about ensuring that only Google gets your data. It's not about privacy.
- crankylinuxuser 8y agoI don't quite follow. Please explain why Google gets the data.
- dangerface 8y agoIn the past cryptographic export was illegal in the us and many other countries, it can still get you put on a list. In some countries messaging apps like signal and telegram are illegal. There is no telling what seemingly benign software will be made illegal in the future for political reasons. Privacy is always a requirement because of these reasons.
- disiplus 8y agoyes but privacy is a whole another thing that is maybe not worth it. with mirrors and so on getting https to properly work is not trivial. sure it would be nice.
- arghwhat 8y agoHTTPS is really quite trivial, especially with the advent of letsencrypt. This is especially true for simple package protocols like APT, where a repository is simply a dumb HTTP server coupled with a bunch of shell scripts that update the content. Assuming that we consider SSH-ing into a server a negligible effort, then adding HTTPS to a APT repository or mirror is also a negligible effort. As for whether privacy is worth it: Absolutely, especially in this day and age. There is very rarely a cost too high when it comes to privacy, and in this instance, it comes for free.
- AstralStorm 8y agoThe problem is, HTTPS is not designed for privacy in any meaningful term. 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.
- disiplus 8y agoit's not trivial if we are talking about Linux boxes serving as servers let's encrypt has a good chance to not work out of the box, and especially with older boxes. and then there i are other things like needing a http server for obtaining the cert rotating it, distributing it. and you loose the ability to use a proxy, and so on. with https you are still not protected with them knowi g where you get only what you did there. 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.
- brazzy 8y agoAs explained on the website, HTTPS would not add meaningful privacy at all, because without significant other changes the architecture, what you're doing is still downloading files from a very limited set. The size of the files in most cases is unique so that an onlloker can tell what you downloaded, encrypted or not.
- DCKing 8y agoI find this argument not very convincing. Suppose an attacker wants to track people downloading stuff over APT. This is what they would need to do: In case of HTTP - Step 1: Read the HTTP request payload. Step 2: There is no step 2. In case of HTTPS - Step 1: Build an index of all possible packages and their sizes. Step 2: Reassemble HTTPS response traffic into individual HTTP responses. Step 3: Look up the response length to the corresponding package. Step 4: In case of identical file sizes, make some sort of model to find out which packet it looks to be based on other packages downloaded (?). Yes, it's still possible to track people's packages all the same. But you have to have a have way more determined and prepared attacker - it cannot be as easily be done through casual eavesdropping. It's a false equivocation to say it would not add meaningful privacy, as your attacker model changes from casual eavesdroppers to more determined attackers. You might not care for that particular distinction, and I agree people should have the choice to use HTTP or FTP for APT when selecting mirrors. Unencrypted APT is plenty secure, but encrypted APT is really a little better. In my opinion, there should not be so much resistance for HTTPS in default configurations (e.g. the Debian project could easily require this for their official mirrors around the world). Let's Encrypt makes this so easy, there's no argument anymore in my opinion.
- Operyl 8y agoAny self signed certificate? Then the attacker who is already capable of intercepting packets can just serve whatever and proxy your request. Your argument to the main argument falls short just the same..
- DCKing 8y agoAgreed, went a bit overboard there. Removed the part about self-signed certificates.
- deleted 8y ago[deleted]
- taf2 8y agoCouldn’t this be used to identify possible hosts that are running exploited software. So you watch a target and keep track of their installed packages. You also monitor for zero day exploits. The instance you have identified a zero day you also have a list of high probability targets to test it out on or exploit. Privacy is more then just I know you have blue eyes or brown eyes