Hacker News Reader

Hacker News

Comment by serbuvlad | Hacker News Reader

Full thread

serbuvlad

It's always been strange to me and I've been saying forever that I don't get why package repos don't use HTTPS.

View on HN

Easier to put caching proxies on the path?

Who actually does that this day and age?

I do. Helps massively when seeding virtual machines using auto-install scripts.

Same. It's faster and feels respectful to not keeping hitting freely provided repos for the same packages over and over. Someone has to be paying for the bandwidth.

Thinking about it, that's not a good argument for http being the default. If you're seeding VMs, you're already in control of the config. Using a dedicated repository proxy (apt-cacher-ng? sonatype nexus? pulp? something?) might even perform better than a generic caching proxy.

Yes, I use acng. I still consider it a caching proxy, even if it's an application-specific one.

Developers

So a minuscule part of the install base that can absolutely alter system configuration to use a local mirror.

Not something that should be the default, exposing everyone to the dangers.

It's not the default, but you can install apt-transport-https and then just change the update URLs to https assuming your mirror supports that.

you can just change the urls to https, apt-transport-https isn't needed anymore, it's builtin to apt now.

I would speculate that it's inertia due to decisions made a decade or two ago, before we decided that everything should run via HTTPS.

theoretical model means that the transfer method doesn't matter.

Of course, that breaks if implementation checks the signatures in wrong moment

There have already been quite a few vulnerabilities in the implementation that would have been avoided if the transport itself was simply protected in line with the industry standard practice of using TLS by default.

The ones I looked at could be summed up to "well the redirects are misbehaving again"

Assuming transport is compromised and you can only trust package signatures IS A GOOD THING. Extra security layer on top of it is nice of course but arguably if it was all https we would've never found this bug and then in case of CA compromise attacker would have plenty of bugs to use to fool apt.

The problem is that they failed ordering of validation; it should be "download from source" (of any type, remember that http(s) isn't only way) -> put into temporary dir -> validate, regardless of source used.

There are also edge cases where HTTPS does hurt you, on system without reliable time (and there is quite a few SBCs that don't have RTC) you would just not be able to download the packages at all because all certs are in future.

Not exactly sure how would a system be able to connect to Internet to download package updates but be unable to source a correct time reference from NTP?

But yes, it should probably be a Debian installer question: use HTTPS sources or not. Debian is the universal operating system but most users running a desktop or server setup should choose YES. The setups where you really want plain HTTP sources are an edge case and users setting up such systems probably already know about their special requirements, so HTTPS sources should really be presented as the default / "if in doubt" option.

I get it to a point because it can be a chicken and egg situation sometimes, but there has got to be a better way.

you can inspect the traffic even without ssl inspection

Reply on news.ycombinator.com