[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Q: Use https for {deb,security}.debian.org by default



On Sat, 21 Aug 2021, Vincent Lefevre wrote:

On 2021-08-20 12:11:30 -0700, Russ Allbery wrote:
The most naive attempt to mess with the update channel (intercepting the
http connection and replacing a package with a malicious one) will fail
immediately with both http or https.  The primary difference in that case
with https is that the the network connection will fail (assuming no
compromise of the TLS certificate authority chain, which is possible of
course and which degrades to the http case), whereas with http you will
download the malicious package first and then apt will refuse to install
                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^
it when the hash doesn't match.  That difference mostly doesn't matter.

But what if one doesn't install packages with apt?

I use the sources.list also to download the source with "apt source".

And what about dget?


Surely anyone as 'off piste' as that will be perfectly capable of fixing
sources.list to do what they want.

As far as 'what is the default', I really don't care. I have my own
reasons for preferring HTTP for my own 'off piste' work but I'll change
the default if necessary.

My biggest fear in all of this discussion is that after make https the
default is done, the next call will be to 'stop supporting http to force
those noob users who haven't updated their sources.list to update'

There are just two use cases I can think of where https might be
important for a 'noob' user: 1, they've got a sources.list entry that
uses basic authentication (but I don't think this is relevant to any of
the entries under discussion) and 2. They're downloading tor or
something like that in a region where it's banned (but as others have
said, relying on https to hide that is naive at best)

So, I want to register my interest in continuing to support http for
debian sources.list for all of the tools even if it's not the default
and it's not recommended.


ObFrustration: It's pretty easy, conceptually, to intercept any HTTP
traffic on the host and 'proxy' it to https off the host. It's also easy
to do that 'at the edge' (whereever you design the edge) and that way
you have one place to configure everything you care about. Instead, I
have to deal with a ridiculously complicated setup to 'peek and splice'
https to try and restrict how much information leaks to facebook et al.
And I'm well aware that 'plans are afoot' to prevent me limiting what
information leaks. And this is just a home setup. I feel for the guys
who have to deal with this in a commercial environment.


Reply to: