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

Groups > linux.debian.devel > #101278 > unrolled thread

Bug#992692: general: Use https for {deb,security}.debian.org by default

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

Contents

  Bug#992692: general: Use https for {deb,security}.debian.org by default Hideki Yamane <henrich@debian.org> - 2021-08-22 15:10 +0200
    Processed: Re: Bug#992692: general: Use https for {deb,security}.debian.org  by default "Debian Bug Tracking System" <owner@bugs.debian.org> - 2021-09-01 11:50 +0200
    Bug#992692: general: Use https for {deb,security}.debian.org by default Helmut Grohne <helmut@subdivi.de> - 2021-09-01 11:50 +0200
      Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-01 12:00 +0200
        Bug#992692: general: Use https for {deb,security}.debian.org by default Russ Allbery <rra@debian.org> - 2021-09-01 17:00 +0200
          Bug#992692: general: Use https for {deb,security}.debian.org by default Hideki Yamane <henrich@iijmio-mail.jp> - 2021-09-02 04:00 +0200
            Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Roberto C. Sánchez <roberto@debian.org> - 2021-09-02 18:30 +0200
              Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Jeremy Stanley <fungi@yuggoth.org> - 2021-09-02 19:00 +0200
            Bug#992692: general: Use https for {deb,security}.debian.org by default Jeremy Stanley <fungi@yuggoth.org> - 2021-09-02 19:00 +0200
            Bug#992692: general: Use https for {deb,security}.debian.org by default Simon Richter <sjr@debian.org> - 2021-09-02 21:40 +0200
              Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-02 23:10 +0200
                Bug#992692: general: Use https for {deb,security}.debian.org by default Paul Wise <pabs@debian.org> - 2021-09-03 04:50 +0200
                  Bug#992692: general: Use https for {deb,security}.debian.org by default David Kalnischkies <david@kalnischkies.de> - 2021-09-05 12:40 +0200
                Bug#992692: general: Use https for {deb,security}.debian.org by default Simon Richter <sjr@debian.org> - 2021-09-03 13:20 +0200
                  Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-03 13:40 +0200
                  Bug#992692: general: Use https for {deb,security}.debian.org by default Philipp Kern <pkern@debian.org> - 2021-09-03 13:40 +0200
              Bug#992692: general: Use https for {deb,security}.debian.org by default Hideki Yamane <henrich@iijmio-mail.jp> - 2021-09-04 22:20 +0200
                Bug#992692: general: Use https for {deb,security}.debian.org by default Simon Richter <sjr@debian.org> - 2021-09-09 20:10 +0200
                  Bug#992692: general: Use https for {deb,security}.debian.org by default Paul Wise <pabs@debian.org> - 2021-09-10 02:00 +0200
                    Bug#992692: general: Use https for {deb,security}.debian.org by default Simon Richter <sjr@debian.org> - 2021-09-10 17:10 +0200
            Bug#992692: general: Use https for {deb,security}.debian.org by default Helmut Grohne <helmut@subdivi.de> - 2021-09-08 13:20 +0200
              Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-08 13:40 +0200
                Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Helmut Grohne <helmut@subdivi.de> - 2021-09-08 14:00 +0200
                  Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-08 14:10 +0200
                    Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Helmut Grohne <helmut@subdivi.de> - 2021-09-08 15:50 +0200
                      Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-08 16:00 +0200
                        Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Michael Stone <mstone@debian.org> - 2021-09-09 01:30 +0200
                          Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2021-09-09 01:40 +0200
                          Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Eduard Bloch <edi@gmx.de> - 2021-09-10 11:30 +0200
                          Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Timo Röhling <roehling@debian.org> - 2021-09-10 12:10 +0200
                            Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Michael Stone <mstone@debian.org> - 2021-09-10 14:00 +0200
                  Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Tim Woodall <debiandevel@woodall.me.uk> - 2021-09-08 14:20 +0200
                    Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-08 14:30 +0200
              Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Michael Stone <mstone@debian.org> - 2021-09-09 01:30 +0200
                Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Timo Röhling <roehling@debian.org> - 2021-09-09 08:40 +0200
                  Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Michael Stone <mstone@debian.org> - 2021-09-09 14:40 +0200
                    Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Timo Röhling <roehling@debian.org> - 2021-09-09 15:00 +0200
                      Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Michael Stone <mstone@debian.org> - 2021-09-09 15:10 +0200
                        Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Timo Röhling <roehling@debian.org> - 2021-09-09 15:30 +0200
                Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Michael Stone <mstone@debian.org> - 2021-09-09 15:00 +0200
                  Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default David Kalnischkies <david@kalnischkies.de> - 2021-09-10 16:40 +0200
                    Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Michael Stone <mstone@debian.org> - 2021-09-10 17:10 +0200
                      Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default David Kalnischkies <david@kalnischkies.de> - 2021-09-10 20:10 +0200
                        Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Michael Stone <mstone@debian.org> - 2021-09-10 21:20 +0200
                        Re: Bug#992692: general: Use https for {deb,security}.debian.org by default Paul Wise <pabs@debian.org> - 2021-09-12 05:20 +0200
                          Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Holger Levsen <holger@layer-acht.org> - 2021-09-13 00:00 +0200
                          Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default David Kalnischkies <david@kalnischkies.de> - 2021-09-13 15:10 +0200
                Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Helmut Grohne <helmut@subdivi.de> - 2021-09-10 09:40 +0200
                  Bug#992692: general: Use https for {deb,security}.debian.org by default Ansgar <ansgar@43-1.org> - 2021-09-10 10:20 +0200
                  Re: Bug#992692: general: Use https for {deb,security}.debian.org by  default Michael Stone <mstone@debian.org> - 2021-09-10 14:10 +0200
                  Bug#994409: task-laptop: please recommend automatic apt proxying Phil Morrell <debian@emorrp1.name> - 2021-09-15 19:20 +0200
                    Re: task-laptop: please recommend automatic apt proxying Russ Allbery <rra@debian.org> - 2021-09-15 19:40 +0200
                      Re: task-laptop: please recommend automatic apt proxying Russ Allbery <rra@debian.org> - 2021-09-15 19:40 +0200
    Bug#992692: next steps Hans-Christoph Steiner <hans@eds.org> - 2021-12-09 12:30 +0100
    Bug#992692: more steps towards this goal Hans-Christoph Steiner <hans@eds.org> - 2022-03-30 10:00 +0200
    Bug#992692: moar Hans-Christoph Steiner <hans@eds.org> - 2022-03-30 12:30 +0200
    Bug#992692: link Geert Stappers <stappers@stappers.nl> - 2022-03-30 12:50 +0200

Page 1 of 3  [1] 2 3  Next page →

#101278 — Bug#992692: general: Use https for {deb,security}.debian.org by default

Package: general
Severity: wishlist

Dear developers,

 As we discussed on -devel(*), it seems that we can enable https for
 {deb,security}.debian.org by default. With this bug report, I'll
 collect related things and fix it.

 - Update mirror list (how?)
 - Update security mirror setting in d-i (how?)
 - https://www.debian.org/mirror/list.en.html points http""://deb.debian.org,
   it should be https.
 - deb.debian.org says "deb http://", it should be "deb https://"
 - In release notes, it should be https://security.debian.org, at least
   See https://www.debian.org/releases/stable/amd64/release-notes/ch-information.html#security-archive


*) https://lists.debian.org/debian-devel/2021/08/msg00269.html

[toc] | [next] | [standalone]

#101476 — Processed: Re: Bug#992692: general: Use https for {deb,security}.debian.org by default

Processing control commands:

> tags -1 + moreinfo
Bug #992692 [general] general: Use https for {deb,security}.debian.org by default
Added tag(s) moreinfo.

-- 
992692: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992692
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

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

#101477

Control: tags -1 + moreinfo

On Sun, Aug 22, 2021 at 09:56:57PM +0900, Hideki Yamane wrote:
>  As we discussed on -devel(*), it seems that we can enable https for
>  {deb,security}.debian.org by default. With this bug report, I'll
>  collect related things and fix it.

I believe that the discussion has later identified that doing so would
break squid-deb-proxy-client and auto-apt-proxy. Given that the security
benefits are not strong (beyond embracing good habits), I think the
reasonable thing to do is keep preferring http.

Caching packages and transport level encryption are fundamentally
incompatible. Possibly it would make more sense to offer users a choice
between performance and privacy on installation?

Helmut

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

#101478

On Wed, 2021-09-01 at 11:15 +0200, Helmut Grohne wrote:
> I believe that the discussion has later identified that doing so
> would
> break squid-deb-proxy-client and auto-apt-proxy. Given that the
> security
> benefits are not strong (beyond embracing good habits), I think the
> reasonable thing to do is keep preferring http.

That is an opt-in choice which likely only a small number of users use.
People wanting to use a caching proxy can just switch to http as part
of this choice; it doesn't seem a good reason to not use https by
default for all other users.

> Caching packages and transport level encryption are fundamentally
> incompatible.

No. You can explicitly configure apt to use a local caching mirror or
use a trusted TLS certificate for the mirror the proxy impersonates.


Ansgar

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

#101484

Ansgar <ansgar@43-1.org> writes:
> On Wed, 2021-09-01 at 11:15 +0200, Helmut Grohne wrote:

>> I believe that the discussion has later identified that doing so would
>> break squid-deb-proxy-client and auto-apt-proxy. Given that the
>> security benefits are not strong (beyond embracing good habits), I
>> think the reasonable thing to do is keep preferring http.

> That is an opt-in choice which likely only a small number of users use.
> People wanting to use a caching proxy can just switch to http as part of
> this choice; it doesn't seem a good reason to not use https by default
> for all other users.

Completely agreed.

>> Caching packages and transport level encryption are fundamentally
>> incompatible.

> No. You can explicitly configure apt to use a local caching mirror or
> use a trusted TLS certificate for the mirror the proxy impersonates.

Yes.  For example, the approach used by apt-cacher-ng works fine.
Explicitly opting in to a local cache seems desirable.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

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

#101488

Hi,

On Wed, 01 Sep 2021 07:46:07 -0700
Russ Allbery <rra@debian.org> wrote:
> >> I believe that the discussion has later identified that doing so would
> >> break squid-deb-proxy-client and auto-apt-proxy. Given that the
> >> security benefits are not strong (beyond embracing good habits), I
> >> think the reasonable thing to do is keep preferring http.
> 
> > That is an opt-in choice which likely only a small number of users use.
> > People wanting to use a caching proxy can just switch to http as part of
> > this choice; it doesn't seem a good reason to not use https by default
> > for all other users.
> 
> Completely agreed.

 Providing "default secure setting" is good message to users.


 Some users want proxy but they can configure their settings.
 So just change "default setting for {deb,security}.debian.org"
 is not so harmful, IMO. 

 - Users can choose other mirror than https://deb.debian.org
 - Caching .debs from security.debian.org is not so huge, I guess
   (maybe except linux-image).


-- 
Hideki Yamane <henrich@iijmio-mail.jp>

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

#101494 — Re: Bug#992692: general: Use https for {deb,security}.debian.org by default

On Thu, Sep 02, 2021 at 04:08:37PM +0000, Jeremy Stanley wrote:
> On 2021-09-02 10:22:15 +0900 (+0900), Hideki Yamane wrote:
> [...]
> >  Providing "default secure setting" is good message to users.
> [...]
> 
> As previously covered, I'd suggest steering clear of referring to
> this as adding "default security." That implies APT wasn't already
> effectively secure over plain HTTP, and may give a false impression
> that HTTPS is addressing gaps in the existing apt-secure design.
> 
> This change is more about recognizing HTTPS as the primary transport
> protocol for the modern Web, not sending mixed signals regarding the
> general security risks posed by plain HTTP when used for unrelated
> purposes, and no longer needing to repeatedly explain to users that
> Debian has gone to great lengths to implement package distribution
> security which doesn't really depend at all on transport layer
> encryption.

In this context, it might make sense to describe using HTTPS as the
transport for APT operations is providing "default confidentiality".

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

#101495 — Re: Bug#992692: general: Use https for {deb,security}.debian.org by default

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

On 2021-09-02 12:27:34 -0400 (-0400), Roberto C. Sánchez wrote:
[...]
> In this context, it might make sense to describe using HTTPS as
> the transport for APT operations is providing "default
> confidentiality".

Which, as similarly discussed, it really doesn't do either (because
of deterministic blob sizes for publicly served files, current SNI
implementations leaking hostnames, general state of the CA and CDN
industries...), so suggesting that may also give users a false
impression. If they really do need confidentiality of their package
installation, they're probably better off doing updates over Tor or
a some VPN which does batching/interleaving of bulk transfers with
some cover traffic, or keeping a private local package mirror.

But to a great extent the degree of confidentiality they can expect
really depends on who they're trying to hide their traffic from. If
their concern is that a company headquartered in the USA might be
tracking the packages they're downloading from deb.debian.org, then
that's already a possibility even with HTTPS: the site is currently
fronted by the Fastly CDN service which terminates TLS encryption
for those HTTPS requests in order to be able to cache them globally.
Of course, without a CDN, mirror site operators can track what
packages you're downloading from them over HTTPS as well.

More generally, what I'm saying is don't try to paint this change as
actually implementing any significant amount of new security or
privacy for Debian users, that would be disingenuous. Just say the
default is switching to HTTPS because that's what users, by and
large, expect today.
-- 
Jeremy Stanley

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

#101496

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

On 2021-09-02 10:22:15 +0900 (+0900), Hideki Yamane wrote:
[...]
>  Providing "default secure setting" is good message to users.
[...]

As previously covered, I'd suggest steering clear of referring to
this as adding "default security." That implies APT wasn't already
effectively secure over plain HTTP, and may give a false impression
that HTTPS is addressing gaps in the existing apt-secure design.

This change is more about recognizing HTTPS as the primary transport
protocol for the modern Web, not sending mixed signals regarding the
general security risks posed by plain HTTP when used for unrelated
purposes, and no longer needing to repeatedly explain to users that
Debian has gone to great lengths to implement package distribution
security which doesn't really depend at all on transport layer
encryption.
-- 
Jeremy Stanley

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

#101497

Hi,

On 02.09.21 03:22, Hideki Yamane wrote:

>   Providing "default secure setting" is good message to users.

The TLS layer is not part of the security model, so we'd be teaching 
users to look for the wrong thing, kind of like the "encrypted with SSL" 
badges on web pages in the 90ies.

We have our own PKI that is decoupled from the X.509 certificate 
infrastructure, and neither ascribes any trust in them nor depends on 
the availability of an external service.

As it is now, I can install a Debian system where no X.509 certificate 
authorities are trusted.

  - If I deselect all CAs in the configuration dialog of the 
ca-certificates package, what mechanism will allow apt to work?
  - Do we want to pin the certificate provider for Debian mirrors, in 
the knowledge that we want to be bound to this provider for several 
years, do we want any "root" CA to be able to provide a trust anchor?
  - Is there a revocation mechanism by which we can mark "root" CAs as 
untrustworthy?
  - What does the UI look like if OSCP verification fails?
  - How do mirror operators get a signed certificate?

I think we're adding a lot of complexity and external dependencies to 
the system here, which adds a lot of burden to mirror operators that 
aren't large CDNs. That may be acceptable for an entity like Ubuntu, who 
aren't dependent on donations, but we would be tied to the goodwill of 
CDN operators here, so:

  - do we wish to communicate that the existing mirrors outside 
deb.debian.org are somehow less "secure"?
  - do we have a contingency plan if deb.debian.org hosting on Fastly is 
no longer feasible?

    Simon

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

#101498

On Thu, 2021-09-02 at 21:26 +0200, Simon Richter wrote:
> As it is now, I can install a Debian system where no X.509
> certificate authorities are trusted.

That doesn't change with the proposal?

>   - If I deselect all CAs in the configuration dialog of the 
> ca-certificates package, what mechanism will allow apt to work?

If people intentionally detrust them, they have to deal with the
fallout. People can also detrust Debian's OpenPGP signing keys; it's
not much different.

Accessing www.debian.org will also not work on such systems (and unlike
deb.d.o that does not even offer non-https). It's not Debian's problem.

>   - Do we want to pin the certificate provider for Debian mirrors, in
> the knowledge that we want to be bound to this provider for several 
> years, do we want any "root" CA to be able to provide a trust anchor?

Probably not?

>   - Is there a revocation mechanism by which we can mark "root" CAs
> as 
> untrustworthy?

If we don't have one, shouldn't we worry more about that given the
widespread use of TLS?

Do we have a revocation mechanism by which we can mark OpenPGP signing
keys as untrustworthy (say for apt)?

>   - What does the UI look like if OSCP verification fails?
>   - How do mirror operators get a signed certificate?

Not all mirror operators have a TLS certificate. I don't think that was
proposed to be changed (see subject of the mail).

> I think we're adding a lot of complexity and external dependencies to
> the system here, which adds a lot of burden to mirror operators that 
> aren't large CDNs.

See above.

>   - do we have a contingency plan if deb.debian.org hosting on Fastly
> is no longer feasible?

Is replacing deb.d.o by a non-CDN feasible? If no, what does use of
https change?

As far as I know there is also at least https://cdn-aws.deb.debian.org/
if you don't like Fastly.

Ansgar

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

#101509

On Thu, Sep 2, 2021 at 9:06 PM Ansgar wrote:

> Accessing www.debian.org will also not work on such systems (and unlike
> deb.d.o that does not even offer non-https). It's not Debian's problem.

The Tor onion services offer alternatives to the https PKI:

https://onion.debian.org/

> Is replacing deb.d.o by a non-CDN feasible?

security.d.o mirrors were getting overwhelmed after Linux kernel
updates, which is why that switched to the Fastly CDN, so probably
not. Also, the entire point of the deb.d.o domain is that it be backed
by a CDN.

httpredir.d.o was an alternative CDN-like thing that was based on HTTP
redirects to the mirror network. It had lots of problems, but now that
we have a mirror checker and zzz-dists, perhaps it could work better.
The mirror:// method in apt has probably improved since then too.
Maybe http redirects to local mirrors could be feasible again, but it
would take a lot of work.

https://mirror-master.debian.org/status/mirror-hierarchy.html

> As far as I know there is also at least https://cdn-aws.deb.debian.org/
> if you don't like Fastly.

And there are other CDNs that could potentially be used.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

#101551

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

On Fri, Sep 03, 2021 at 02:42:29AM +0000, Paul Wise wrote:
> httpredir.d.o was an alternative CDN-like thing that was based on HTTP
> redirects to the mirror network. It had lots of problems, but now that
> we have a mirror checker and zzz-dists, perhaps it could work better.
> The mirror:// method in apt has probably improved since then too.

If you wanted to bring back a httpredir-like¹ you are better of to
combine both approaches as in: Have apt request a list of mirrors to use
via mirror(+https) and have the server generate that list based on the
requester as that gives you the "regional" mirrors as did httpredir while
solving the major grip it had by having a list of mirrors to use, rather
than one potentially non-working slightly outdated partial mirror (and
the httpredir service is contacted by each client once rather than for
each individual file to then be redirected elsewhere).

Obviously, that approach is only workable if you are actually using
libapt tools. Most debootstrap implementations couldn't really use that
which might or might not be a problem for a given use case. Such
a service would also have a hard time to 'redirect' you to a local
mirror in your network (compared to an 'official' region one).


So that isn't really what seems to be the main worry here:
https prevents MitM attacks including the friendly MitM ones like the
local network at home/at DebConf telling my laptop that there is an
on-site mirror or not telling at all and just proxy transparently the
entire network.

The later seems done for in a https-world, but the former might be
somewhat salvageable: We will have to get the Release² file(s) from the
repo defined in the sources, but the index files and debs after that are
a fairer game to get from elsewhere as they are either identical with
what the defined source would have provided or a hard error.
That still violates the privacy guarantees https has (assuming it does),
so that would still need to be opt-in/out, but that is a one time choice
per machine and could be similar in style to auto-apt-proxy.

Anyway, implementation wise apt could tell $MAGIC which repo it is
interested in (by Origin & Label) and would in return get a list of
mirrors as apt-transport-mirror would. apt would then add the original
source as least priority fallback and proceed with that list for this
source.
I say $MAGIC as I don't want apt to hard code the specifics of how to
get the list, similar to how it is agnostic to how a proxy is currently
picked up, as I could envision different implementations depending on
use cases.

That is different to just using apt-transport-mirror directly in the
sources in so far as the provider of the list remains untrusted (beside
that nobody is constantly editing their sources to adapt to the local
network the machine currently resides in).


Relatively quickly thought up, probably full of holes and not implemented
at all in apt so far, but if someone thinks that might work feel free to
report as a feature request against apt and I will see what I can do
from the apt side. It at least seems slightly more workable than hoping
to prevent https – which might have just as dubious a chance to succeed
as https has to factually improve security in terms of apt. 😜


> Maybe http redirects to local mirrors could be feasible again, but it
> would take a lot of work.

fwiw: apt does not allow https to http redirects (some https repos
ran into this in the past like those hosted on sourceforge until they
fixed their https 'everywhere' configuration). In this regard apt is
stricter than a normal webbrowser (a mirror list acquired via https can
redirect to http mirrors though, but see the man pages for details).


Best regards

David Kalnischkies


¹ which deb.d.o sort of is just that it is nowadays done via SRV instead
  of an explicit HTTP redirect – and that only one mirror is in the list
  rather than multiple httpredir had picked one to redirect to.

² The main security benefit of https for apt is that you can't fiddle
  with the Release file, mostly in terms of sending an older one (in
  the limits of Valid-Until if used). It is also minor in size compared
  to the indexes and especially the debs, so caching them is not much of
  a concern (if a cacher was even doing it, it probably shouldn't).

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

#101515

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

Hi,

On 02.09.21 23:02, Ansgar wrote:

>> As it is now, I can install a Debian system where no X.509
>> certificate authorities are trusted.

> That doesn't change with the proposal?

>>    - If I deselect all CAs in the configuration dialog of the
>> ca-certificates package, what mechanism will allow apt to work?

> If people intentionally detrust them, they have to deal with the
> fallout.

So this introduces a policy that users need to mark X.509 CAs as trusted?

> People can also detrust Debian's OpenPGP signing keys; it's
> not much different.

The Debian signing keys have separate trust setup, and are trusted for 
nothing but APT updates.

If we wanted the same for X.509, we'd need /etc/apt/ca-certificates or 
something such, and apt to configure the list of accepted CAs explicitly 
in the TLS layer rather than using the default settings.

> Accessing www.debian.org will also not work on such systems (and unlike
> deb.d.o that does not even offer non-https). It's not Debian's problem.

There are a lot of systems out there that have no need to access 
www.debian.org, but do need to access deb.debian.org.

>>    - Do we want to pin the certificate provider for Debian mirrors, in
>> the knowledge that we want to be bound to this provider for several
>> years, do we want any "root" CA to be able to provide a trust anchor?

> Probably not?

So what do we want then? A list of root CAs that users have to mark as 
trusted, possibly with an "are you sure?" dialog in ca-certificates?

This isn't a simple change of default, because this simple change pulls 
in a lot of dependencies. That users can override the default means 
adding another work step for users, either a manual step that needs to 
be performed after a manual installation, or an automated step that 
needs to be integrated into users' deployment processes.

>>    - Is there a revocation mechanism by which we can mark "root" CAs
>> as
>> untrustworthy?

> If we don't have one, shouldn't we worry more about that given the
> widespread use of TLS?

We have a big hammer, shipping a new ca-certificates package. If we want 
something that only affects apt, but not other packages, that mechanism 
doesn't exist yet.

> Do we have a revocation mechanism by which we can mark OpenPGP signing
> keys as untrustworthy (say for apt)?

Yes, by shipping an update.

>>    - do we have a contingency plan if deb.debian.org hosting on Fastly
>> is no longer feasible?

> As far as I know there is also at least https://cdn-aws.deb.debian.org/
> if you don't like Fastly.

It's not about what I like, but on what external services we want to depend.

    Simon

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

#101516

On Fri, 2021-09-03 at 13:11 +0200, Simon Richter wrote:
> > >    - If I deselect all CAs in the configuration dialog of the
> > > ca-certificates package, what mechanism will allow apt to work?
> 
> > If people intentionally detrust them, they have to deal with the
> > fallout.
> 
> So this introduces a policy that users need to mark X.509 CAs as
> trusted?

No.

> > People can also detrust Debian's OpenPGP signing keys; it's
> > not much different.
> 
> The Debian signing keys have separate trust setup, and are trusted
> for nothing but APT updates.
> 
> If we wanted the same for X.509, we'd need /etc/apt/ca-certificates
> or 
> something such, and apt to configure the list of accepted CAs
> explicitly 
> in the TLS layer rather than using the default settings.

People who only want to trust specific CAs for APT can do that. APT has
a CaPath setting.

> > Accessing www.debian.org will also not work on such systems (and
> > unlike
> > deb.d.o that does not even offer non-https). It's not Debian's
> > problem.
> 
> There are a lot of systems out there that have no need to access 
> www.debian.org, but do need to access deb.debian.org.

And nothing stops them from doing so.

> > >    - Do we want to pin the certificate provider for Debian
> > > mirrors, in
> > > the knowledge that we want to be bound to this provider for
> > > several
> > > years, do we want any "root" CA to be able to provide a trust
> > > anchor?
> 
> > Probably not?
> 
> So what do we want then? A list of root CAs that users have to mark
> as  trusted, possibly with an "are you sure?" dialog in ca-
> certificates?

We already have that.

> This isn't a simple change of default, because this simple change
> pulls in a lot of dependencies.

ca-certificates should already be installed by default (it is Priority:
standard and recommended by apt).

> That users can override the default means adding another work step
> for users, either a manual step that needs to be performed after a
> manual installation, or an automated step that needs to be integrated
> into users' deployment processes.

I don't see the problem? Currently we add another work step for users
that want to use https.

> > If we don't have one, shouldn't we worry more about that given the
> > widespread use of TLS?
> 
> We have a big hammer, shipping a new ca-certificates package. If we
> want something that only affects apt, but not other packages, that
> mechanism doesn't exist yet.

If a CA is untrustworthy, I don't think we would only want to detrust
it for apt's https method. So I see no problem.

> 
> It's not about what I like, but on what external services we want to
> depend.

So your concern is about Debian providing the deb.debian.org service at
all? That seems unrelated to the https or not question.

Ansgar

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

#101517

Hi,

On 03.09.21 13:11, Simon Richter wrote:
[Revocation mechanism]
>> If we don't have one, shouldn't we worry more about that given the
>> widespread use of TLS?
> We have a big hammer, shipping a new ca-certificates package. If we want 
> something that only affects apt, but not other packages, that mechanism 
> doesn't exist yet.

I think that's an interesting point, not just for revocation. There are 
forces pushing for more agility, switching out roots of trust more 
frequently. So for very old releases, you usually had the signing key of 
the next release on disk, so you could move to the next release. In this 
case you sort of risk not having the TLS authority on disk to make that 
happen. And of course we need to track what the authorities are doing 
that our frontends are using (e.g. [1] around how to deal with old 
Android devices).

But then I'm not sure how much we need to care about ancient releases 
that are out of security support. We would need to commit to regularly 
update the certificate bundle, though.

To your other point: I don't think managing trust into individual CAs 
will scale. We cannot really anticipate which CAs we are going to use in 
the future.

Kind regards
Philipp Kern

[1] https://letsencrypt.org/2020/12/21/extending-android-compatibility.html

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

#101540

On Thu, 2 Sep 2021 21:26:11 +0200
Simon Richter <sjr@debian.org> wrote:
> The TLS layer is not part of the security model, so we'd be teaching 
> users to look for the wrong thing, kind of like the "encrypted with SSL" 
> badges on web pages in the 90ies.

 Is there any strong reason to use HTTP than HTTPS now?
 Should we teach all our users (including non-tech) about "Secure APT"
 mechanism?


 And I said about only deb.debian.org and security.debian.org, and
 just "default" - it means it does provide http access too.



-- 
Regards,

 Hideki Yamane     henrich @ debian.org/iijmio-mail.jp

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

#101625

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

Hi,

On 04.09.21 22:12, Hideki Yamane wrote:

>> The TLS layer is not part of the security model, so we'd be teaching
>> users to look for the wrong thing, kind of like the "encrypted with SSL"
>> badges on web pages in the 90ies.

>   Is there any strong reason to use HTTP than HTTPS now?

The strongest reason (IMO) in favor of unencrypted transmission is that 
it doesn't introduce a policy decision. The package "ca-certificates" 
must be installed and a checkmark set for the "mozilla/ISRG_Root_X1.crt" 
certificate, otherwise updates will break.

If we want to have HTTPS as default, we need additional logic to make 
sure certificates are installed and cannot be deinstalled (so Essential 
or a strong dependency chain from an Essential package) and that the 
certificate cannot be deactivated, or apt needs its own repository of 
trusted certificates.

With the current Docker images:

$ docker run --rm -it debian:bullseye
root@32529bf86cd3:/# sed -i -e s/http/https/ /etc/apt/sources.list
root@32529bf86cd3:/# apt update
Err:1 https://deb.debian.org/debian bullseye InRelease
   Certificate verification failed: The certificate is NOT trusted. The 
certificate issuer is unknown.  Could not handshake: Error in the 
certificate verification. [IP: 199.232.138.132 443]
Err:2 https://security.debian.org/debian-security bullseye-security 
InRelease
   Certificate verification failed: The certificate is NOT trusted. The 
certificate issuer is unknown.  Could not handshake: Error in the 
certificate verification. [IP: 151.101.66.132 443]
Err:3 https://deb.debian.org/debian bullseye-updates InRelease
   Certificate verification failed: The certificate is NOT trusted. The 
certificate issuer is unknown.  Could not handshake: Error in the 
certificate verification. [IP: 199.232.138.132 443]

So changing the default is not sufficient here, we'd need a lot of 
additional work and testing to ensure this works for everyone, not just 
the desktop users.

Another important argument is that it creates a dependency on 
third-party commercial CDNs, and their *continued* sponsorship.

Debian is very conservative when spending money and generally shies away 
from recurring expenses because we do not want to find us in a situation 
where we are dependent on an external entity making a timely donation in 
order to keep operations running, so I wonder why we are that accepting 
of it in one of our core services, and I certainly don't think we should 
be adding additional roadblocks should we ever need to find an alternative.

We have a (crude) load-balancing framework in infrastructure we control 
that can point requests towards a set of untrusted mirrors, and while 
it's nice that we don't *need* to use this fallback plan, it is 
reassuring it is there.

>   Should we teach all our users (including non-tech) about "Secure APT"
>   mechanism?

If they ask why we're not using HTTPS, yes: it helps clear up the 
misconception that anything with an "s" in it is secure and can be trusted.

Anyone who configures an additional source needs to know how the 
authentication mechanism works anyway, so we're not gaining anything 
there either.

    Simon

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

#101626

On Thu, Sep 9, 2021 at 6:03 PM Simon Richter wrote:

> Another important argument is that it creates a dependency on
> third-party commercial CDNs, and their *continued* sponsorship.

This dependency on external providers is unavoidable, Debian
definitely cannot afford to run our own CDN at the scale needed to
support our existing userbase. For example the security mirrors
struggled with Linux kernel security updates, so security.d.o switched
to a commercial CDN. Also, we are dependent on continued sponsorship
for all of our infrastructure, paying for all of our hosting is likely
not feasible.

https://wiki.debian.org/ExternalEntities

> Debian is very conservative when spending money and generally shies away
> from recurring expenses because we do not want to find us in a situation
> where we are dependent on an external entity making a timely donation in
> order to keep operations running, so I wonder why we are that accepting
> of it in one of our core services, and I certainly don't think we should
> be adding additional roadblocks should we ever need to find an alternative.

DSA setup the CDN provider solution to give the Debian userbase a
better experience than having to choose a mirror and a better
experience than httpredir.d.o's redirect method. We have multiple CDN
providers to mitigate the dependency, and other providers who we
aren't yet using that are offering service. So, as much as I dislike
CDNs as a concept, I recognise that we currently need them and think
that we are able to handle loss of a CDN provider or two.

> We have a (crude) load-balancing framework in infrastructure we control
> that can point requests towards a set of untrusted mirrors, and while
> it's nice that we don't *need* to use this fallback plan, it is
> reassuring it is there.

httpredir.d.o no longer exists, it points at deb.d.o, so it would have
to be rebuilt if we were to need to switch away from CDNs.

Personally I'd like to see a larger variety of Debian delivery
mechanisms; copy Debian/snapshot to archive.org, create a multi-distro
FLOSS CDN, bring back httpredir, DebTorrent and apt-p2p, add an i2p
mirror, use IPFS and content oriented networking etc. Michael Stone's
apt://debian idea seems like a good way to move in that direction
while adding protocol agility.

> If they ask why we're not using HTTPS, yes: it helps clear up the
> misconception that anything with an "s" in it is secure and can be trusted.

The volume of questions about missing https means that it is more
efficient to just use https than to have to reply to new questions
about it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

#101641

Hi,

On 10.09.21 01:46, Paul Wise wrote:

>> Another important argument is that it creates a dependency on
>> third-party commercial CDNs, and their *continued* sponsorship.

> This dependency on external providers is unavoidable, Debian
> definitely cannot afford to run our own CDN at the scale needed to
> support our existing userbase. For example the security mirrors
> struggled with Linux kernel security updates, so security.d.o switched
> to a commercial CDN. Also, we are dependent on continued sponsorship
> for all of our infrastructure, paying for all of our hosting is likely
> not feasible.

Yes -- and mirrors have traditionally been provided by third parties. 
What is new about the CDNs is that there are rather few of those, and 
this centralization aspect is what worries me.

> Personally I'd like to see a larger variety of Debian delivery
> mechanisms; copy Debian/snapshot to archive.org, create a multi-distro
> FLOSS CDN, bring back httpredir, DebTorrent and apt-p2p, add an i2p
> mirror, use IPFS and content oriented networking etc. Michael Stone's
> apt://debian idea seems like a good way to move in that direction
> while adding protocol agility.

Yes, absolutely -- and we especially want to have a better solution for 
containers, because my expectation is that a large fraction of our 
traffic is just people not bothering to set up caching.

    Simon

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web