This nonsensical argument again.
Eavesdropping on HTTP: inspect the request body and see wich package and version is requested . That's it.
Eavesdropping on HTTPS: 1) build up a database of package sizes for versions. 2) Reassemble HTTPS traffic to figure out what HTTPS requests are. 3) Account for randomized padding lengths and packages of similar sizes (what if a minor security fix results in the same package size? ) 4) perform a lookup of the package version in your sophisticated database.
It's not even the same ballpark of complexity. Sure, dedicated targeted semi sophisticated attackers can still eavesdrop your HTTPS connections, but HTTPS sure as heck protects against casual snoopers. Which do you really think is more relevant in the real world? And furthermore what kind of attacker achieves the level of sophistication for such a lookup mechanism, and doesn't have the sophistication to screw you over in some other way? There is zero understanding of economics or real-world attacker motivations in this argument.
It boggles my mind that there are people so stubborn - or think they're so clever - that they rather set up a dedicated website with a "well, actually" argument only based in pure technology. They do this instead of thinking critically about this and work towards giving people sane defaults.
• Browsers will reuse the same TCP connection when downloading multiple resources. Does apt not do this? This seems like it would make inferring package versions and names difficult.
• Is it impractical to standardize on a fixed block size that works for most packages, and just add noise as required to 'top up' the size of the payload to match the same size as all the others?
I found these articles interesting:
Also, is there an actual PoC for any of these size-related side channel attacks? I'd take it all a lot more seriously if there was one.
The last time I read whydoesaptnotusehttps.com the tone of the article seemed disappointingly in favour of the status quo. The intro to the article now seems much more open to change.
(this site isn't on the Wayback Machine, so I'm going on memory—not sure how significantly the article has actually changed)
They also aggressively pin those connections.
However because they’re serving over https a mitm can only DoS the update system: they can’t change the update or dependency lists, they can’t insert malicious content into those responses, they can’t add cookies to the requests and responses.
Privacy can also be fixed if you simply pull multiple resources over the same connection (which is also faster)
Just use https.
echo "Acquire::http::Proxy \"http://personal-cntlm-proxy:3128\";" > /etc/apt/apt.conf
apt-get install -y apt-transport-https
echo "deb [trusted=yes] https://someserver/somedir bionic main universe multiverse" > /etc/apt/sources.list
echo "deb [trusted=yes] https://someserver/somedir bionic-updates main universe multiverse" >> /etc/apt/sources.list
echo "deb [trusted=yes] https://someserver/somedir bionic-security main universe multiverse" >> /etc/apt/sources.list
echo "Acquire::https::Verify-Peer \"false\";" > /etc/apt/apt.conf.d/80ssl-exceptions
echo "Acquire::https::Verify-Host \"false\";" >> /etc/apt/apt.conf.d/80ssl-exceptions
apt-get -y install ca-certificates # and now the server is trusted finally
echo "deb https://someserver/somedir bionic main universe multiverse" > /etc/apt/sources.list
echo "deb https://someserver/somedir bionic-updates main universe multiverse" >> /etc/apt/sources.list
echo "deb https://someserver/somedir bionic-security main universe multiverse" >> /etc/apt/sources.list
probably not even anywhere near the prescribed way to do this, but everything in corporate america has a few extra dance steps.
WHAT'S THE F%@#ING POINT if you do not require proper certificate ?!?!
I've been saying for many years that the HTTPS everywhere is not a good idea and would end up in false sens of security. It's like green-washing; everybody pretend doing it except not really ....
Luckly, in the case of Apt it does not matter much but there are other cases of blind-https-all-the-thing-stupidly where it does.
There are so many competing, parallel efforts to solve problems, that generally everything is a bit mediocre in terms of what is available.
It requires a bit of a forced-optimist persona to remain creative and upbeat. On the other hand, when I go back to a small company, the sense of technical freedom should feel remarkable.