How come apt-get is not using https

how come apt-get is not using https

Attached: 1518046112446.jpg (705x527, 247K)

Other urls found in this thread:

istlsfastyet.com/
deb.debian.org
whydoesaptnotusehttps.com/
manpages.ubuntu.com/manpages/bionic/man1/apt-transport-https.1.html
security-tracker.debian.org/tracker/CVE-2014-0490
security-tracker.debian.org/tracker/CVE-2011-1829
security-tracker.debian.org/tracker/CVE-2012-3587
twitter.com/NSFWRedditImage

>goyim, w-why aren't you using our trustworthy s

>Jow Forumsyp is too underage/retarded to know about cryptographic signatures
like clockwork

>hurr durr, our server's CPU load
typical debian bullshit
istlsfastyet.com/

>you can only use apt-get using http
dilate tranny

It has a different trust moel/implementation which means it doesn't require https for integrity verification. You could make the argument for encryption but I think that's an acceptable risk.

You can. In stretch you had to install apt-transport-https but apt will do TLS natively now. But because Debian is retarded the default apt sources.list is still http. Change everything to deb.debian.org and it'll work. Remember that one of the lines is security.debian.org, that server won't do TLS, last I looked, change it to deb.debian.

well integrity verification isn't the only thing we want here, we'd also like to put obstacles in the way of attackers knowing we're installing Debian, or what packages we're installing. In any case it's good security hygiene. I'm certain there's a significant number of greybeards in the Debian world who remember when the internet was small and clubby and pretty much everyone knew each other because only universities, and a few government and tech-company sites, were connected at all. In that world you didn't really need encryption most of the time, just a gentleman's agreement not to peek. Those days are gone forever and they don't want to admit that. The network is hostile now, and no cleartext traffic should be hitting the wire.

it's not about data integrity, it's about data discretion... I don't want my ISP or the NSA to know which packages I'm installing / updating
>you can just sum up the whole traffic to that server and calculate the used packages from there
this is an impractical bullshit argument... just add http headers with dummy data of random length in it

>you can just sum up the whole traffic to that server and calculate the used packages from there
I never made that argument because I agree, it's a shitty argument. No matter what Tyrone thinks, size doesn't matter. Is encryption always preferred? Yes. I was just trying to answer OPs question. Don't light me on fire, here.

learn to google, user
whydoesaptnotusehttps.com/
manpages.ubuntu.com/manpages/bionic/man1/apt-transport-https.1.html

tl;dr doesn't fit everyone's usecase, major example is cloud providers and large companies use their own package cache, but you can opt in to https or to transports easily.

pgp sucks and apt's pgp methods have had a handful of trouble for a while:
security-tracker.debian.org/tracker/CVE-2014-0490
security-tracker.debian.org/tracker/CVE-2011-1829
security-tracker.debian.org/tracker/CVE-2012-3587

>dilate
have sex.

>I never made that argument
yeah I know, but others did in the past and I had to include it in my post

>apt-get is not using https
whydoesaptnotusehttps.com/

bend over

>CVEs
Fair enough.

Please don't do that, it's a strawman and you really should argue for or against particular arguments, not attack sister arguments that your peer hasn't even made yet.

>large companies use their own package cache
this is another BS argument... just set up set up proper load balancing or different server addresses on the clients

>>tl;dr doesn't fit everyone's usecase, major example is cloud providers and large companies use their own package cache, but you can opt in to https or to transports easily.
that's fine, but in that case TLS should be the default, with those know know they don't need it being able to opt-out. This protects random users setting up an individual system, and its trivial for a large site (presumably with a bunch of deployment automation, if not pre-made images) to apply the change to turn it off.

hack them
i'm sure they'll put the s

>I don't want my ISP or the NSA to know which packages I'm installing / updating
would be a near pointless thing to target; even if they cared https wouldnt matter much, apt uses mirrors by default
large companies could just siphon off the logs to $TLA, smaller orgs could have theirs hacked.

yeah, companies do custom images by default anyway, a better argument:

cryptography is a way to ensure failure by default until something is proven otherwise, in some cases where reliability is critical, this may not always be preferred.

rolling out encryption by default in general has its own caveats, clients may not have the right time, outdated roots, old libssl, etc.
this is even worse in the case of a distributed system as apt's mirrors
many companies, even in 2019, forget things as simple as renewing their certs, and lose money over it; expecting them to be reliable with providing https for what is basically charity from them is probably a bit much.

but in the end, this is probably just not a major concern to the debian team, it could all still work as an opt-in in the installer, but it took them several years of pestering just to provide apt-transport-https in the first place

>>many companies, even in 2019, forget things as simple as renewing their certs, and lose money over it; expecting them to be reliable with providing https for what is basically charity from them is probably a bit much.
Why would you pay for certs and then renew the manually, running the risk of forgetting to, when you could just automate all that for free in minutes with Lets Encrypt?

automation can break, rollouts can fuck up, restoring from snapshots/backups, appliance failures, etc.
I once listened to a conference call where a large company had a global outage due to a route propagation failure, wasn unable to rollback because the responsible router's TACACS broke due to the same route failure. They had to wait an nearly an hour for someone from the security team to wake up (it was ~midnight) to give the routing team the OOB serial console password, and took another half hour to diagnose and fix the issue.

tl;dr managing shit when you have little infra to worry about is easy, this applies especially for security.

1. newest apt in Debian 10 uses https by default
2. apt checks signatures to prevent mitm attacks so it's only beneficial for privacy.