Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5141 > unrolled thread

HTTPS needs to be implemented for updating

Back to article view | Back to linux.debian.security

Contents

  HTTPS needs to be implemented for updating gwmfms06@unseen.is - 2016-12-17 21:30 +0100
    Re: HTTPS needs to be implemented for updating Christoph Moench-Tegeder <cmt@burggraben.net> - 2016-12-18 12:10 +0100
      Re: HTTPS needs to be implemented for updating datanoise <datanoise@bitjungle.info> - 2016-12-18 13:10 +0100
        Re: HTTPS needs to be implemented for updating Casper Thomsen <ct@clearhaus.com> - 2016-12-19 09:20 +0100
          Re: HTTPS needs to be implemented for updating Christoph Biedl <debian.axhn@manchmal.in-ulm.de> - 2016-12-20 23:20 +0100
            Re: HTTPS needs to be implemented for updating Joerg Jaspert <joerg@debian.org> - 2016-12-21 09:40 +0100
              Re: HTTPS needs to be implemented for updating Marc Haber <mh+debian-security@zugschlus.de> - 2016-12-21 10:00 +0100
                Re: HTTPS needs to be implemented for updating Christoph Biedl <debian.axhn@manchmal.in-ulm.de> - 2016-12-21 10:10 +0100
      Re: HTTPS needs to be implemented for updating Peter Lawler <relwalretep@gmail.com> - 2016-12-18 22:30 +0100
        Re: HTTPS needs to be implemented for updating Hans-Christoph Steiner <hans@at.or.at> - 2016-12-19 12:00 +0100
          Re: HTTPS needs to be implemented for updating Hans-Christoph Steiner <hans@at.or.at> - 2016-12-20 10:50 +0100
            Re: HTTPS needs to be implemented for updating Sven Hartge <sven@svenhartge.de> - 2016-12-20 18:20 +0100
            Re: HTTPS needs to be implemented for updating Martin Zobel-Helas <zobel@debian.org> - 2017-03-03 11:30 +0100

#5141 — HTTPS needs to be implemented for updating

I know Micah Lee has been making the case for HTTPS connections for some time. Why can't Debian make this happen? This bug makes clear that relying on validating signatures is not foolproof 100% of the time and that additional layers of protection should be in place to try to mitigate weaknesses (even temporary ones).  

What with Let's Encrypt now active, there is no excuse to not move everything to HTTPS for updating.

https://www.debian.org/security/2016/dsa-3733

[toc] | [next] | [standalone]

#5143

## gwmfms06@unseen.is (gwmfms06@unseen.is):

> What with Let's Encrypt now active, there is no excuse to not move
> everything to HTTPS for updating.

1. Bandwidth. It's fairly easy to proxy/cache HTTP, but HTTPS prevents
   that (unless you break HTTPS). This not only affects the server
   side (I have no idea about the amount of "traffic saved" for Debian),
   but also sites running multiple machines with Debian installed.
   Setting up a mirror is more work than just running a squid.
2. That brings us to: Mirrors. There's quite a bunch of them, and
   I'm quite sure that some of them (even primary mirrors) are not
   "Debian Project hardware". That way it's not just "throw a switch
   and everything is SSL", and it even creates some interesting
   questions like third parties (those non-Debian mirror admins)
   having access to debian.org SSL keys.

First point is an inconvenience, second point requires a lot of work
to resolve.

Regards,
Christoph

-- 
Spare Space

[toc] | [prev] | [next] | [standalone]

#5144

Christoph Moench-Tegeder :
> ## gwmfms06@unseen.is (gwmfms06@unseen.is):
>
>> What with Let's Encrypt now active, there is no excuse to not move
>> everything to HTTPS for updating.
> 1. Bandwidth. It's fairly easy to proxy/cache HTTP, but HTTPS prevents
>     that (unless you break HTTPS). This not only affects the server
>     side (I have no idea about the amount of "traffic saved" for Debian),
>     but also sites running multiple machines with Debian installed.
>     Setting up a mirror is more work than just running a squid.
> 2. That brings us to: Mirrors. There's quite a bunch of them, and
>     I'm quite sure that some of them (even primary mirrors) are not
>     "Debian Project hardware". That way it's not just "throw a switch
>     and everything is SSL", and it even creates some interesting
>     questions like third parties (those non-Debian mirror admins)
>     having access to debian.org SSL keys.
>
> First point is an inconvenience, second point requires a lot of work
> to resolve.

There could be https mirrors as well as non-https mirrors.

Each individual / company could decide to use a non-https mirror if they 
so prefer.

(Some https mirrors are already available, for example mirrors.kernel.org)

Cheers

[toc] | [prev] | [next] | [standalone]

#5146

On Sun, Dec 18, 2016 at 12:35 PM, datanoise <datanoise@bitjungle.info> wrote:
> There could be https mirrors as well as non-https mirrors.

There is https://cloudfront.debian.net which you could decide to trust.

It doesn't *need* to be a "Debian SSL cert"; since you trust the
mirror anyway is some regard, you could as well "just" also trust the
mirror's certificate (and handling thereof).

Kindly,
-- 
Casper Thomsen

[toc] | [prev] | [next] | [standalone]

#5152

[Multipart message — attachments visible in raw view] — view raw

Casper Thomsen wrote...

> On Sun, Dec 18, 2016 at 12:35 PM, datanoise <datanoise@bitjungle.info> wrote:
> > There could be https mirrors as well as non-https mirrors.
> 
> There is https://cloudfront.debian.net which you could decide to trust.
> 
> It doesn't *need* to be a "Debian SSL cert"; since you trust the
> mirror anyway is some regard, you could as well "just" also trust the
> mirror's certificate (and handling thereof).

Well, this creates trust for the path until (but excluding) that
particular mirror only. Can I trust the mirror? And even if, there's no
guarantee the mirror got the data through a trusted path.

    Christoph

[toc] | [prev] | [next] | [standalone]

#5153

On 14527 March 1977, Christoph Biedl wrote:
> Well, this creates trust for the path until (but excluding) that
> particular mirror only. Can I trust the mirror? And even if, there's no
> guarantee the mirror got the data through a trusted path.

And why the heck would you ever trust any mirror? If you have to, you
lost already and do it wrong.

https gains you NOTHING at all. It's perfectly fine to use ANY mirror,
however untrustworthy that one may be. Because their (operators) conduct
does not matter at all. The Debian archive and its tools are setup so
that you do not need to trust them and that you notice if they do want
to f*ck with you.

As long as you
 - verified the cd image you installed from against the checksum file
   provided by the debian cd team, signed by their key,
 - do not disable signature checking in apt,
 - do not add random gpg keys to your trust store,

you are fine.

Now, if you want to manually download a .deb and dpkg -i it - then you
have to manually do the same steps apt & co do: Get the corresponding
packages and (In)Release files, verify its signature validates against
the archive key, then verify the checksum of the Packages and then the
.deb file. If you don't follow this, you lost, but you asked for it.

And before someone comes with hiding information from a sniffer: https
does not help you there, use tor to not have people know which packages
you just downloaded. https does not hide this from a sniffer.

-- 
bye, Joerg

[toc] | [prev] | [next] | [standalone]

#5154

On Wed, Dec 21, 2016 at 09:31:23AM +0100, Joerg Jaspert wrote:
> Now, if you want to manually download a .deb and dpkg -i it - then you
> have to manually do the same steps apt & co do: Get the corresponding
> packages and (In)Release files, verify its signature validates against
> the archive key, then verify the checksum of the Packages and then the
> .deb file. If you don't follow this, you lost, but you asked for it.

Do we have a tool that does this kind of verification of a locally
present .deb automatically?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

[toc] | [prev] | [next] | [standalone]

#5155

[Multipart message — attachments visible in raw view] — view raw

Marc Haber wrote...

> On Wed, Dec 21, 2016 at 09:31:23AM +0100, Joerg Jaspert wrote:
> > Now, if you want to manually download a .deb and dpkg -i it - then you
> > have to manually do the same steps apt & co do: Get the corresponding
> > packages and (In)Release files, verify its signature validates against
> > the archive key, then verify the checksum of the Packages and then the
> > .deb file. If you don't follow this, you lost, but you asked for it.
> 
> Do we have a tool that does this kind of verification of a locally
> present .deb automatically?

If it's about a package in the configured sources.list, you can just
apt-get download it. Else I'd set up a virtual environment for the
selected dist and arch, then apt-get download as above. There are
several tools for that, chdist (src:devscripts) worked fine for me.

    Christoph

[toc] | [prev] | [next] | [standalone]

#5145

On 18/12/16 22:03, Christoph Moench-Tegeder wrote:
> second point requires a lot of work
> to resolve.
>
> Regards,
> Christoph
>

Monday morning yet-to-be-caffienated thoughts...

I'm going to ignore the 'inconvenience' because I think in this case 
that's a specious argument.

I acknowledge there's a bucketload of work to implement this. Just gets 
me to thinking, staging a switch over may be better. eg, a new apt 
config for https as either 'required' 'desired' and 'off'. This reduces 
the initial workload. Start with the default 'off', then at some future 
release move to 'desired' then 'required'.

Further, I suggest perhaps an automated survey of the major mirrors to 
find which ones already support https may be in order. Perhaps the 
resultant data could be used by the apt-transport-https package for now, 
as well as deciding when the above mentioned switch over might occur.

As I say, decaffienated Monday morning thoughts.

[toc] | [prev] | [next] | [standalone]

#5147

Peter Lawler:
> 
> 
> On 18/12/16 22:03, Christoph Moench-Tegeder wrote:
>> second point requires a lot of work
>> to resolve.
>>
>> Regards,
>> Christoph
>>
> 
> Monday morning yet-to-be-caffienated thoughts...
> 
> I'm going to ignore the 'inconvenience' because I think in this case
> that's a specious argument.
> 
> I acknowledge there's a bucketload of work to implement this. Just gets
> me to thinking, staging a switch over may be better. eg, a new apt
> config for https as either 'required' 'desired' and 'off'. This reduces
> the initial workload. Start with the default 'off', then at some future
> release move to 'desired' then 'required'.
> 
> Further, I suggest perhaps an automated survey of the major mirrors to
> find which ones already support https may be in order. Perhaps the
> resultant data could be used by the apt-transport-https package for now,
> as well as deciding when the above mentioned switch over might occur.
> 
> As I say, decaffienated Monday morning thoughts.
> 

Here's a script I wrote to do just that, find all Debian mirrors that
support HTTPS:

https://gist.github.com/eighthave/7285154

.hc

[toc] | [prev] | [next] | [standalone]

#5150

Hans-Christoph Steiner:
> 
> 
> Peter Lawler:
>>
>>
>> On 18/12/16 22:03, Christoph Moench-Tegeder wrote:
>>> second point requires a lot of work
>>> to resolve.
>>>
>>> Regards,
>>> Christoph
>>>
>>
>> Monday morning yet-to-be-caffienated thoughts...
>>
>> I'm going to ignore the 'inconvenience' because I think in this case
>> that's a specious argument.
>>
>> I acknowledge there's a bucketload of work to implement this. Just gets
>> me to thinking, staging a switch over may be better. eg, a new apt
>> config for https as either 'required' 'desired' and 'off'. This reduces
>> the initial workload. Start with the default 'off', then at some future
>> release move to 'desired' then 'required'.
>>
>> Further, I suggest perhaps an automated survey of the major mirrors to
>> find which ones already support https may be in order. Perhaps the
>> resultant data could be used by the apt-transport-https package for now,
>> as well as deciding when the above mentioned switch over might occur.
>>
>> As I say, decaffienated Monday morning thoughts.
>>
> 
> Here's a script I wrote to do just that, find all Debian mirrors that
> support HTTPS:
> 
> https://gist.github.com/eighthave/7285154
> 
> .hc

Also, it would be really awesome if there was:

https://httpsredir.debian.org/debian

Which automatically redirected to mirrors that support HTTPS.  I filed
an issue here:
https://github.com/rgeissert/http-redirector/issues/78

.hc

[toc] | [prev] | [next] | [standalone]

#5151

[Multipart message — attachments visible in raw view] — view raw

On 20.12.2016 10:45, Hans-Christoph Steiner wrote:

> Also, it would be really awesome if there was:
> 
> https://httpsredir.debian.org/debian
> 
> Which automatically redirected to mirrors that support HTTPS.  I filed
> an issue here:
> https://github.com/rgeissert/http-redirector/issues/78

There is https://deb.debian.org/debian which automatically redirects you
to one of two mirror networks using HTTPS.

Grüße,
Sven.

[toc] | [prev] | [next] | [standalone]

#5192

Hi, 

On Tue Dec 20, 2016 at 10:45:23 +0100, Hans-Christoph Steiner wrote:
> Also, it would be really awesome if there was:
> 
> https://httpsredir.debian.org/debian
> 
> Which automatically redirected to mirrors that support HTTPS.  I filed
> an issue here:
> https://github.com/rgeissert/http-redirector/issues/78


httpredir is a dead horse.
-- 
 Martin Zobel-Helas <zobel@spi-inc.org>
 Software in the Public Interest, Inc. | Member of the Board of Directors
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web