Quantcast

Re: HTTPS metadata in Mirrors.masterlist?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Colin Watson
On Tue, Feb 11, 2014 at 01:04:29PM +0000, Colin Watson wrote:

> I'm working on adding HTTPS support to d-i.  Now, I know that we already
> have integrity by way of the GPG signature chain, but this isn't for
> that; this is in response to feedback Canonical has had from some Ubuntu
> customers (typically of the large and corporate variety) that they want
> to do all of their apt traffic over HTTPS to avoid people snooping on
> which packages various machines are installing.  We already have some
> minimal support for this by way of Joey's change in debootstrap 1.0.56:
>
>   * When deboostrapping Debian, and the debian-archive-keyring is not
>     available, switch the default mirror to a https url. This way at
>     least the CA level of security is available even for users who
>     have no way to check gpg keys in the WoT. The https mirror is
>     currently https://mirrors.kernel.org/debian.
>
> Now, the next thing on my list to work on is choose-mirror: you should
> be able to pass mirror/protocol=https and have it offer you HTTPS
> mirrors if it knows about any, and otherwise just ask you to enter
> mirror information manually.  I suspect that in reality most users of
> this feature would have an internal mirror, but it would be good to
> offer public mirrors where we know about them too.
>
> Would it be possible, then, to add "Archive-https: /debian/" to the
> "Site: mirrors.kernel.org" stanza in Mirrors.masterlist, and perhaps
> start maintaining Archive-https fields for other mirrors willing to
> participate?  That would at least get a minimal list started for this
> mode.
>
> (And yes, I know that this is only of any actual use if we do
> certificate checks.  Right now the way I have things hooked up is that
> you can add certificates to the d-i initramfs, either by rebuilding with
> SSL_CERTS set in build/config/local or by concatenating another
> initramfs-format archive of c_rehash-ed certificates unpacking to
> /usr/lib/ssl/certs; or else debian-installer/allow_unauthenticated=false
> will imply no certificate checking.  You have to supply GNU wget anyway,
> since busybox wget doesn't speak HTTPS.  If more people than I suspect
> want to use this then we might want to consider something with
> ca-certificates, but I felt that was overkill for now and it certainly
> involved more thinking about policy than I wanted to do.)

I managed to typo [hidden email] as
[hidden email], bafflingly.  Following up with full
quoting so that both lists have it ...

Thanks,

--
Colin Watson                                       [[hidden email]]


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20140211134553.GA20550@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Mattias Wadenstein
On Tue, 11 Feb 2014, Colin Watson wrote:

> On Tue, Feb 11, 2014 at 01:04:29PM +0000, Colin Watson wrote:
>> I'm working on adding HTTPS support to d-i.  Now, I know that we already
>> have integrity by way of the GPG signature chain, but this isn't for
>> that; this is in response to feedback Canonical has had from some Ubuntu
>> customers (typically of the large and corporate variety) that they want
>> to do all of their apt traffic over HTTPS to avoid people snooping on
>> which packages various machines are installing.

Let me suggest that if they want to keep it a secret from people able to
snoop on their network traffic, they might want to consider the much
stronger protection of running their own mirror. Given the finite space of
package sizes and deps, clever traffic analysis should be able to figure
out which packages go over an HTTPS stream too, even if it'll be a bit
harder than the plaintext stream.

That said, I don't mind more giving the users what they want, but I also
see no way in which our mirror could provide usable HTTPS, so the mirror
selection would likely be much smaller.

/Mattias Wadenstein


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/alpine.DEB.2.02.1402111459200.8689@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Colin Watson
On Tue, Feb 11, 2014 at 03:05:44PM +0100, Mattias Wadenstein wrote:

> On Tue, 11 Feb 2014, Colin Watson wrote:
> >On Tue, Feb 11, 2014 at 01:04:29PM +0000, Colin Watson wrote:
> >>I'm working on adding HTTPS support to d-i.  Now, I know that we already
> >>have integrity by way of the GPG signature chain, but this isn't for
> >>that; this is in response to feedback Canonical has had from some Ubuntu
> >>customers (typically of the large and corporate variety) that they want
> >>to do all of their apt traffic over HTTPS to avoid people snooping on
> >>which packages various machines are installing.
>
> Let me suggest that if they want to keep it a secret from people
> able to snoop on their network traffic, they might want to consider
> the much stronger protection of running their own mirror.

I'm not sure how much detail I'm allowed to go into, but in the specific
cases at hand, I believe they *are* running their own internal mirror,
but they want to make some efforts to conceal information from their own
employees who might be able to snoop on the network.  At least this is
as far as I've been able to tell, and I can see how it'd make sense for
sufficiently large organisations.

Having metadata about the public mirror network is mostly a nicety so
that we don't just drop people straight into manual mirror selection; it
seems like something we might as well track if mirror operators are
willing, though.

> That said, I don't mind more giving the users what they want, but I
> also see no way in which our mirror could provide usable HTTPS, so
> the mirror selection would likely be much smaller.

Right, I expected as much.

Thanks,

--
Colin Watson                                       [[hidden email]]


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20140211143107.GO6397@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Donald Norwood
On 02/11/2014 09:31 AM, Colin Watson wrote:

> On Tue, Feb 11, 2014 at 03:05:44PM +0100, Mattias Wadenstein wrote:
>> On Tue, 11 Feb 2014, Colin Watson wrote:
>>> On Tue, Feb 11, 2014 at 01:04:29PM +0000, Colin Watson wrote:
>>>> I'm working on adding HTTPS support to d-i.  Now, I know that we already
>>>> have integrity by way of the GPG signature chain, but this isn't for
>>>> that; this is in response to feedback Canonical has had from some Ubuntu
>>>> customers (typically of the large and corporate variety) that they want
>>>> to do all of their apt traffic over HTTPS to avoid people snooping on
>>>> which packages various machines are installing.
>> Let me suggest that if they want to keep it a secret from people
>> able to snoop on their network traffic, they might want to consider
>> the much stronger protection of running their own mirror.
> I'm not sure how much detail I'm allowed to go into, but in the specific
> cases at hand, I believe they *are* running their own internal mirror,
> but they want to make some efforts to conceal information from their own
> employees who might be able to snoop on the network.  At least this is
> as far as I've been able to tell, and I can see how it'd make sense for
> sufficiently large organisations.
>
> Having metadata about the public mirror network is mostly a nicety so
> that we don't just drop people straight into manual mirror selection; it
> seems like something we might as well track if mirror operators are
> willing, though.

This topic has come up in mirrors a few times from users and the general
conscientious was stated rather well by Mattias. As it stands, and to my
knowledge, there are a handful of servers set up to support https.

The question really becomes what is the point? If the network traffic
itself can be snooped then why not a smaller mirror set on the specific
machines if they are still wary of using even localized mirror? Or a CD/DVD?

A caveat to those approaches is that the machines in question are still
connected to the network and those machines are still running or
querying services from the packages they installed.

Adding https support doesn't really solve the issue. From your later
post this seems more of a network security issue for those admins to
resolve.

Best Regards,

Donald Norwood


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/52FA360A.5090004@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Mattias Wadenstein
In reply to this post by Colin Watson
On Tue, 11 Feb 2014, Colin Watson wrote:

> On Tue, Feb 11, 2014 at 03:05:44PM +0100, Mattias Wadenstein wrote:
>> On Tue, 11 Feb 2014, Colin Watson wrote:
>>> On Tue, Feb 11, 2014 at 01:04:29PM +0000, Colin Watson wrote:
>>>> I'm working on adding HTTPS support to d-i.  Now, I know that we already
>>>> have integrity by way of the GPG signature chain, but this isn't for
>>>> that; this is in response to feedback Canonical has had from some Ubuntu
>>>> customers (typically of the large and corporate variety) that they want
>>>> to do all of their apt traffic over HTTPS to avoid people snooping on
>>>> which packages various machines are installing.
>>
>> Let me suggest that if they want to keep it a secret from people
>> able to snoop on their network traffic, they might want to consider
>> the much stronger protection of running their own mirror.
>
> I'm not sure how much detail I'm allowed to go into, but in the specific
> cases at hand, I believe they *are* running their own internal mirror,
> but they want to make some efforts to conceal information from their own
> employees who might be able to snoop on the network.  At least this is
> as far as I've been able to tell, and I can see how it'd make sense for
> sufficiently large organisations.

Ah, finally a half-reasonable case for https. I agree that this is
sufficient for software support in apt, d-i, etc.

I just hope it doesn't turn into more of the misguided "if only mirrors
served packages over https, NSA wouldn't be able to see that I have
iceweasel installed!" version of false assumption of security.

/Mattias Wadenstein


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/alpine.DEB.2.02.1402111610060.8689@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Colin Watson
In reply to this post by Donald Norwood
On Tue, Feb 11, 2014 at 09:39:06AM -0500, Donald Norwood wrote:

> This topic has come up in mirrors a few times from users and the
> general conscientious was stated rather well by Mattias. As it
> stands, and to my knowledge, there are a handful of servers set up
> to support https.
>
> The question really becomes what is the point? If the network
> traffic itself can be snooped then why not a smaller mirror set on
> the specific machines if they are still wary of using even localized
> mirror? Or a CD/DVD?
>
> A caveat to those approaches is that the machines in question are
> still connected to the network and those machines are still running
> or querying services from the packages they installed.
>
> Adding https support doesn't really solve the issue. From your later
> post this seems more of a network security issue for those admins to
> resolve.

All I have left to say is that the admins in question are my customers,
I've already exhausted all the avenues of protest you suggest, and they
still tell me this is something they need.  Based on the work I've done
so far I don't think this is a particularly onerous thing to support in
d-i at least as an option, I'm prepared to do the work, and all I'm
asking for here is a bit of metadata in the mirror masterlist.  If the
latter can't be provided because we don't think Debian mirrors will
accept the load or whatever, that's fine, I can always make it
manual-only or whatever, but at this point it is easier for me to
support HTTPS than to argue about it. :-)

Cheers,

--
Colin Watson                                       [[hidden email]]


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20140211155628.GA24903@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Matus UHLAR - fantomas
>On Tue, Feb 11, 2014 at 09:39:06AM -0500, Donald Norwood wrote:
>> This topic has come up in mirrors a few times from users and the
>> general conscientious was stated rather well by Mattias. As it
>> stands, and to my knowledge, there are a handful of servers set up
>> to support https.
>>
>> The question really becomes what is the point? If the network
>> traffic itself can be snooped then why not a smaller mirror set on
>> the specific machines if they are still wary of using even localized
>> mirror? Or a CD/DVD?
>>
>> A caveat to those approaches is that the machines in question are
>> still connected to the network and those machines are still running
>> or querying services from the packages they installed.
>>
>> Adding https support doesn't really solve the issue. From your later
>> post this seems more of a network security issue for those admins to
>> resolve.

On 11.02.14 15:56, Colin Watson wrote:
>All I have left to say is that the admins in question are my customers,

so, the company is not your customer, but its admins are?

>I've already exhausted all the avenues of protest you suggest, and they
>still tell me this is something they need.  Based on the work I've done
>so far I don't think this is a particularly onerous thing to support in
>d-i at least as an option, I'm prepared to do the work, and all I'm
>asking for here is a bit of metadata in the mirror masterlist.  If the
>latter can't be provided because we don't think Debian mirrors will
>accept the load or whatever, that's fine, I can always make it
>manual-only or whatever, but at this point it is easier for me to
>support HTTPS than to argue about it. :-)

You can of course configure HTTPS on your server. MAybe you could configure
HTTPS proxy for them. Finally, if they are your customers, it's up to you to
provide the servicem isn't it?

Note that HTTPS clients verify the servers' certificate and multiple debian
mirrors with different hostnames can not have the same certificate, nor it's
sane to maintain different certificates for each hostname on each mirror ...

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20140211162226.GB25165@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Kurt Roeckx
In reply to this post by Colin Watson
On Tue, Feb 11, 2014 at 01:45:53PM +0000, Colin Watson wrote:

> >
> > (And yes, I know that this is only of any actual use if we do
> > certificate checks.  Right now the way I have things hooked up is that
> > you can add certificates to the d-i initramfs, either by rebuilding with
> > SSL_CERTS set in build/config/local or by concatenating another
> > initramfs-format archive of c_rehash-ed certificates unpacking to
> > /usr/lib/ssl/certs; or else debian-installer/allow_unauthenticated=false
> > will imply no certificate checking.  You have to supply GNU wget anyway,
> > since busybox wget doesn't speak HTTPS.  If more people than I suspect
> > want to use this then we might want to consider something with
> > ca-certificates, but I felt that was overkill for now and it certainly
> > involved more thinking about policy than I wanted to do.)

So the first question I have about this if we can get
ftp.TLD.debian.org certificates for this, and what happens when
that host is down and DNS gets pointed to a different host?

I have to guess that we should only do that on the hostname that
is not ftp.TLD.debian.org, while I think it now only shows that
name?


Kurt


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20140211174022.GB7438@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Colin Watson
In reply to this post by Matus UHLAR - fantomas
On Tue, Feb 11, 2014 at 05:22:26PM +0100, Matus UHLAR - fantomas wrote:
> On 11.02.14 15:56, Colin Watson wrote:
> >All I have left to say is that the admins in question are my customers,
>
> so, the company is not your customer, but its admins are?

Oh, whatever.  I'm not interested in this kind of word game.

> >I've already exhausted all the avenues of protest you suggest, and they
> >still tell me this is something they need.  Based on the work I've done
> >so far I don't think this is a particularly onerous thing to support in
> >d-i at least as an option, I'm prepared to do the work, and all I'm
> >asking for here is a bit of metadata in the mirror masterlist.  If the
> >latter can't be provided because we don't think Debian mirrors will
> >accept the load or whatever, that's fine, I can always make it
> >manual-only or whatever, but at this point it is easier for me to
> >support HTTPS than to argue about it. :-)
>
> You can of course configure HTTPS on your server.

It's their server, not mine.

> MAybe you could configure HTTPS proxy for them. Finally, if they are
> your customers, it's up to you to provide the servicem isn't it?

Which is what I'm doing by doing this work in d-i!  Of course I could
just do it in Ubuntu but it seems better to have the code in Debian too;
it can always be mostly disabled by default so that only people who want
to turn it on need to care.

> Note that HTTPS clients verify the servers' certificate and multiple debian
> mirrors with different hostnames can not have the same certificate, nor it's
> sane to maintain different certificates for each hostname on each mirror ...

Well aware of that, thanks.

--
Colin Watson                                       [[hidden email]]


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20140211175911.GA28077@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Colin Watson
In reply to this post by Kurt Roeckx
On Tue, Feb 11, 2014 at 06:40:22PM +0100, Kurt Roeckx wrote:
> So the first question I have about this if we can get
> ftp.TLD.debian.org certificates for this, and what happens when
> that host is down and DNS gets pointed to a different host?
>
> I have to guess that we should only do that on the hostname that
> is not ftp.TLD.debian.org, while I think it now only shows that
> name?

Yeah.  It's not clear that this makes sense for role name hosting across
trust domains ...

--
Colin Watson                                       [[hidden email]]


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20140211180003.GB28077@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Gaudenz Steinlin
In reply to this post by Colin Watson
Colin Watson <[hidden email]> writes:

> On Tue, Feb 11, 2014 at 05:22:26PM +0100, Matus UHLAR - fantomas wrote:
>> On 11.02.14 15:56, Colin Watson wrote:
>> >All I have left to say is that the admins in question are my customers,
>>
>> so, the company is not your customer, but its admins are?
>
> Oh, whatever.  I'm not interested in this kind of word game.
>
>> >I've already exhausted all the avenues of protest you suggest, and they
>> >still tell me this is something they need.  Based on the work I've done
>> >so far I don't think this is a particularly onerous thing to support in
>> >d-i at least as an option, I'm prepared to do the work, and all I'm
>> >asking for here is a bit of metadata in the mirror masterlist.  If the
>> >latter can't be provided because we don't think Debian mirrors will
>> >accept the load or whatever, that's fine, I can always make it
>> >manual-only or whatever, but at this point it is easier for me to
>> >support HTTPS than to argue about it. :-)
>>
>> You can of course configure HTTPS on your server.
>
> It's their server, not mine.
>
>> MAybe you could configure HTTPS proxy for them. Finally, if they are
>> your customers, it's up to you to provide the servicem isn't it?
>
> Which is what I'm doing by doing this work in d-i!  Of course I could
> just do it in Ubuntu but it seems better to have the code in Debian too;
> it can always be mostly disabled by default so that only people who want
> to turn it on need to care.

I want to thank you for that. I'm happy, that this is not just
implemented in Ubuntu, but also in Debian. I also think that this is a
worthwile feature and that it should be enabled for those mirrors that
want to support it and that it should be as easy as possible to turn on.

While it's true that this does not give absolute protection, no single
measure does. And using HTTPS makes it significantly more difficult to
find out wich packages are downloaded. So it's a step in the right
direction.

Gaudenz

>
>> Note that HTTPS clients verify the servers' certificate and multiple debian
>> mirrors with different hostnames can not have the same certificate, nor it's
>> sane to maintain different certificates for each hostname on each mirror ...
>
> Well aware of that, thanks.
>
> --
> Colin Watson                                       [[hidden email]]
>
>
> --
> To UNSUBSCRIBE, email to [hidden email]
> with a subject of "unsubscribe". Trouble? Contact [hidden email]
> Archive: http://lists.debian.org/20140211175911.GA28077@...
>
>

--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87fvnp5t82.fsf@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Joerg Jaspert
In reply to this post by Colin Watson
On 13484 March 1977, Colin Watson wrote:

>> Would it be possible, then, to add "Archive-https: /debian/" to the
>> "Site: mirrors.kernel.org" stanza in Mirrors.masterlist, and perhaps
>> start maintaining Archive-https fields for other mirrors willing to
>> participate?  That would at least get a minimal list started for this
>> mode.

The list should be the smallest problem, one more field doesn't matter
too much.

The biggest problem I see is with what Kurt posted:

> So the first question I have about this if we can get
> ftp.TLD.debian.org certificates for this, and what happens when
> that host is down and DNS gets pointed to a different host?

> I have to guess that we should only do that on the hostname that
> is not ftp.TLD.debian.org, while I think it now only shows that
> name?

I see no real problem in getting certificates for those domains - way
more interesting is the handling of them. ftp.*.d.o gets pointed around
to other mirrors when the usual "owner" of it is down for whatever
reason. Depending on the country it may also end up on mirrors really
far away (better that than no ftp.whatever.d.o). So some mirror
somewhere may not just need one of those certs, but multiple[1]. And a
single cert/key must be on loads of mirrors. And then comes handling of
renewals too.

So only using it on the mirrors actual hostname would be sensible.

Which would mean extra entries in the mirror list, should the mirror be
able to run ftp.*.d.o, as (currently) the Archive-* entries are only
path values, not full urls, so they apply to all Site: and Alias: tags.
(Plus much more mirror config for their apache/nginx/whatever, but thats
true for https anyways)


[1] Unless we really can do a wildcard of ftp.*.debian.org, which I dont
    know, but which would allow mirror admins to use it for
    ftp.anything.debian.org too. Huh.

--
bye, Joerg
'To Start Press Any Key'. Where's the ANY key?


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/8738jkogc5.fsf@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Henrique de Moraes Holschuh
On Sat, 15 Feb 2014, Joerg Jaspert wrote:

> The biggest problem I see is with what Kurt posted:
>
> > So the first question I have about this if we can get
> > ftp.TLD.debian.org certificates for this, and what happens when
> > that host is down and DNS gets pointed to a different host?
>
> > I have to guess that we should only do that on the hostname that
> > is not ftp.TLD.debian.org, while I think it now only shows that
> > name?
>
> I see no real problem in getting certificates for those domains - way
> more interesting is the handling of them. ftp.*.d.o gets pointed around
> to other mirrors when the usual "owner" of it is down for whatever
> reason. Depending on the country it may also end up on mirrors really
> far away (better that than no ftp.whatever.d.o). So some mirror
> somewhere may not just need one of those certs, but multiple[1]. And a
> single cert/key must be on loads of mirrors. And then comes handling of
> renewals too.
>
> So only using it on the mirrors actual hostname would be sensible.

Well, the user requested that we add https support to the tools (so that
individual mirrors and private mirrors can go https if they want), not to
the mirror network itself.

Also, IMHO if one is going to add SSL/TLS support to the tools, it needs to
be done properly.  I.e. certificate path validation is a must (e.g.
validating the chain to a manually trusted certificate, or to a trusted CA
root), and DANE support would be nice (which is kinda hard, as DANE done
properly requires a validating DNSSEC resolver).  Non-validated SSL/TLS
connections are trivial to MITM and usually it is just a waste of resources.
So, enabling it on the mirror network is, as you wrote, also a PKI problem
due to our use of dynamic aliases.

However, IMHO we don't need to support SSL/TLS pervasively on the mirror
network.  It gives us very little as far as security and privacy are
concerned, for a real and non-trivial cost on resources and PKI operational
concerns.  Traffic analyisis makes it trivial to disclose what packages are
being downloaded and we already do MUCH stronger package content validation.
In this specific case, SSL/TLS support is only useful on limited situations
(and I assume the user that requested https support needs it for one of
those limited situations -- e.g. his adversary is incapable of proper
traffic analysis, or he just needs to avoid content inspection).

So, for the mirror network, IMHO it would be enough to deploy TLS
certificates for select mirrors using only the specific mirror host names,
leaving the aliases such as ftp.*.d.o out of it.  Let's not waste resources
and create operational problems where not required: the people who really
need https can use specific mirror host names instead of aliases (or will be
using private mirrors anyway).

> [1] Unless we really can do a wildcard of ftp.*.debian.org, which I dont
>     know, but which would allow mirror admins to use it for
>     ftp.anything.debian.org too. Huh.

This is likely to be far more trouble than it is worth, IMHO.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20140215142422.GA5400@...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Luca Capello
In reply to this post by Colin Watson
Hi there!

> (And yes, I know that this is only of any actual use if we do
> certificate checks.  Right now the way I have things hooked up is that
> you can add certificates to the d-i initramfs, either by rebuilding with
> SSL_CERTS set in build/config/local or by concatenating another
> initramfs-format archive of c_rehash-ed certificates unpacking to
> /usr/lib/ssl/certs;
  ^^^^^^^^^^^^^^^^^^
Maybe a naive question, but given that /usr/lib/ssl/certs is a symlink
to /etc/ssl/certs, is there any reason why the latter should not be
preferred?

Thx, bye,
Gismo / Luca

signature.asc (834 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Cyril Brulebois-4
Luca Capello <[hidden email]> (2014-02-15):

> Hi there!
>
> > (And yes, I know that this is only of any actual use if we do
> > certificate checks.  Right now the way I have things hooked up is that
> > you can add certificates to the d-i initramfs, either by rebuilding with
> > SSL_CERTS set in build/config/local or by concatenating another
> > initramfs-format archive of c_rehash-ed certificates unpacking to
> > /usr/lib/ssl/certs;
>   ^^^^^^^^^^^^^^^^^^
> Maybe a naive question, but given that /usr/lib/ssl/certs is a symlink
> to /etc/ssl/certs, is there any reason why the latter should not be
> preferred?
http://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=commit;h=36f68fa7311124d669044f3e2ecb146aeed73e2b

Mraw,
KiBi.

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Axel Beckert-8
In reply to this post by Joerg Jaspert
Hi,

sorry for digging up that old thread from 2014, but it's exactly what
I wanted to bring up, just with today's needs and possibilities:

* CVE-2016-1252 in APT showed that HTTPS might still bring additional
  security. After that issue, the amount of people asking for
  HTTPS-secured Debian mirrors noticeably raised, see e.g. the edits
  and comments from 2016 to answers to the 2013 question
  https://unix.stackexchange.com/questions/90227/why-there-is-no-https-transport-for-debian-apt-tool/

* With Let's Encrypt it's much easier for mirror admins to get SSL
  certificates for ftp.$COUNTRY.debian.org and their local mirror
  hostname without having to fall back to using SNI or not providing
  SSL or at least not proper SSL certificates on all hostnames. (The
  latter still seems rather common, see below.)

Joerg Jaspert wrote:
> On 13484 March 1977, Colin Watson wrote:
> >> Would it be possible, then, to add "Archive-https: /debian/" to the
> >> "Site: mirrors.kernel.org" stanza in Mirrors.masterlist, and perhaps
> >> start maintaining Archive-https fields for other mirrors willing to
> >> participate?  That would at least get a minimal list started for this
> >> mode.
>
> The list should be the smallest problem, one more field doesn't matter
> too much.

Especially with Let's Encrypt, getting proper SSL certificates for all
DNS entries pointing to a mirror shouldn't be such a big issue
anymore. See e.g. https://ftp.ch.debian.org/ aka
https://debian.ethz.ch/ which have a single SSL certificate for hosts
under different second-level domains.

> The biggest problem I see is with what Kurt posted:
>
> > So the first question I have about this if we can get
> > ftp.TLD.debian.org certificates for this, and what happens when
> > that host is down and DNS gets pointed to a different host?
>
> > I have to guess that we should only do that on the hostname that
> > is not ftp.TLD.debian.org, while I think it now only shows that
> > name?
>
> I see no real problem in getting certificates for those domains - way
> more interesting is the handling of them. ftp.*.d.o gets pointed around
> to other mirrors when the usual "owner" of it is down for whatever
> reason. Depending on the country it may also end up on mirrors really
> far away (better that than no ftp.whatever.d.o). So some mirror
> somewhere may not just need one of those certs, but multiple[1]. And a
> single cert/key must be on loads of mirrors. And then comes handling of
> renewals too.
This is probably still an issue despite getting an updated certificate
via Let's Encrypt can be done much quicker than in the past.
Nevertheless there still will be a short downtime without valid
certificate when switching DNS entries.

A wildcard certificate for selected (e.g. DSA-maintained) mirrors
which then would be used as backup host for any primary mirror,
which already provides HTTPS access, would probably suffice.

Example: When ftp.ch.debian.org goes down for longer maintenance we
usually redirected that CNAME to one of the hosts around
kassia.debian.org (ftp.nl.debian.org or similar) where also one of the
European syncproxies is located.

So I can imagine the following setup to mitigate this:

* We track which mirrors (also) provide HTTPS in Mirrors.masterlist.

* If a primary mirror which doesn't provide HTTPS goes down, we
  redirect it to the same mirror as we did in the past.

* If one with HTTPS in central Europe goes down, we redirect it to
  that mirror on kassia.debian.org given that it will have a wildcard
  SSL certificate for ftp*.*.debian.org or similar. (We should look at
  ftp*.*.debian.org instead of just ftp.*.debian.org if possible
  because of mirrors like ftp2.de.debian.org.)

And since quite some mirrors already provide access via HTTPS, IMHO we
should start tracking them independent of having a proper solution to
temporary CNAME changes or not -- because they're in use already if
you want it or not.

So far I'm at least aware of the following working HTTPS mirrors
(picked out a few I read about in previous mailing list threads or
found out by quickly checking in a web browser):

* https://ftp.ch.debian.org/debian/ aka https://debian.ethz.ch/debian/
  (same mirror but two entries in the Mirrors.masterlist)
* https://ftp.de.debian.org/debian/
* https://ftp.cz.debian.org/debian/
* https://ftp.se.debian.org/debian/ (ftp.no.debian.org seems to point
  to the same host, but is not yet accessible via HTTPS due to not
  being listed in the certificate)
* https://mirrors.kernel.org/debian/
* https://mirror.sinavps.ch/debian/
* https://pkg.adfinis-sygroup.ch/debian/
* https://ftp.halifax.rwth-aachen.de/debian/ (not yet accessible as
  https://ftp2.de.debian.org/debian/ due to certificate only being
  valid for ftp.halifax.rwth-aachen.de)
* https://mirrors.wikimedia.org/debian/ (not yet accessible as
  https://ftp.us.debian.org/debian/ due to certificate only being
  valid for mirrors.wikimedia.org)
* https://mirror.as35701.net/debian/ (not yet accessible as
  https://ftp.be.debian.org/debian/ due to certificate only being
  valid for mirror.as35701.net)

A short scan over all mirrors in the Mirror.masterlist showed that
more than one third (176, around 38%) of them have at least port 443
open:

  → GET https://anonscm.debian.org/viewvc/webwml/webwml/english/mirror/Mirrors.masterlist\?view\=co \
    | egrep '^Site:' \
    | awk '{print $2}' \
    | sort \
    | while read m ; do nmap -p443 $m; done \
    > https-mirrors.txt
  → ( echo -n 'scale=2;'`egrep -c '^443/tcp open  https' https-mirrors.txt`/; \
      egrep -c '^443/tcp.*https' https-mirrors.txt ) | bc
  .38
  → egrep -c '^443/tcp.*https' https-mirrors.txt
  455
  → egrep -c '^443/tcp open  https' https-mirrors.txt
  176

(Didn't check more certificates or subjectAltNames than those listed
above yet, though. Full list of hosts I found having port 443 open can
be found at the end of this mail.)

After having HTTPS-enabled mirrors listed in the Mirrors.masterlist,
the next step would be to make httpredir.debian.org HTTPS-aware.
Currently https://httpredir.debian.org/ shows me the following error
message:

  httpredir.debian.org uses an invalid security certificate.
  The certificate is only valid for www.debian.org

(Yes, I'm aware that httpredir.debian.org points to quite some
servers.)

Luckily the software behind httpredir.debian.org seems to be already
HTTPS-aware in some way. At least with Kali's HTTP redirector (which I
assume uses the same software), I get different mirror lists depending
on if I access the service by HTTP or HTTPS:

  → GET -SUsed http://http.kali.org/kali/dists/kali-rolling/Release | egrep '^L'
  Location: http://archive-3.kali.org/kali/dists/kali-rolling/Release
  Link: <http://http.kali.org/kali/dists/kali-rolling/Release.meta4>; rel=describedby; type="application/metalink4+xml"
  Link: <http://archive-3.kali.org/kali/dists/kali-rolling/Release>; rel=duplicate; pri=1; geo=de
  Link: <http://ftp.halifax.rwth-aachen.de/kali/dists/kali-rolling/Release>; rel=duplicate; pri=2; geo=de
  Link: <http://ftp.belnet.be/kali/kali/dists/kali-rolling/Release>; rel=duplicate; pri=3; geo=be
  Link: <http://archive-4.kali.org/kali/dists/kali-rolling/Release>; rel=duplicate; pri=4; geo=fr
  Link: <http://ftp.free.fr/pub/kali/dists/kali-rolling/Release>; rel=duplicate; pri=5; geo=fr
  Last-Modified: Thu, 06 Apr 2017 12:16:51 GMT
  → GET -SUsed https://http.kali.org/kali/dists/kali-rolling/Release | egrep '^L'
  Location: https://ftp.halifax.rwth-aachen.de/kali/dists/kali-rolling/Release
  Link: <http://http.kali.org/kali/dists/kali-rolling/Release.meta4>; rel=describedby; type="application/metalink4+xml"
  Link: <https://ftp.halifax.rwth-aachen.de/kali/dists/kali-rolling/Release>; rel=duplicate; pri=1; geo=de
  Link: <https://archive-3.kali.org/kali/dists/kali-rolling/Release>; rel=duplicate; pri=2; geo=de
  Link: <https://archive-4.kali.org/kali/dists/kali-rolling/Release>; rel=duplicate; pri=3; geo=fr
  Link: <https://ftp2.nluug.nl/os/Linux/distr/kali/dists/kali-rolling/Release>; rel=duplicate; pri=4; geo=nl
  Link: <https://ftp1.nluug.nl/os/Linux/distr/kali/dists/kali-rolling/Release>; rel=duplicate; pri=5; geo=nl

(And IIRC the Kali installer also offered me to choose if I want HTTP,
FTP or HTTPS mirrors, at least with debconf priority set to "low". No
more sure about Debian's installer on my last Stretch installation.)

Full list of mirrors I found having port 443 open (using the data from
above mentioned script):

→ fgrep -B5 '443/tcp open  https' https-mirrors.txt \
    | fgrep 'Nmap scan report for' \
    | cut -c22-        
archive.kernel.org (198.145.20.143)
archive-klecker.debian.org (130.89.148.13)
artfiles.org (80.252.110.38)
buaya.klas.or.id (202.154.57.18)
cdimage.debian.org (194.71.11.165)
cosmos.cites.illinois.edu (192.17.174.4)
deb.debian.org (140.211.166.202)
debian.anexia.at (37.252.235.254)
debian.bononia.it (91.121.193.42)
debian.c3sl.ufpr.br (200.236.31.3)
debian.charite.de (141.42.206.17)
debian.cs.binghamton.edu (128.226.116.128)
debian.dynamica.it (81.208.25.146)
debian.ethz.ch (129.132.53.171)
debian.inf.tu-dresden.de (141.76.2.4)
debian.iskon.hr (213.191.133.160)
debian.koyanet.lv (85.254.217.235)
debian.lth.se (130.235.34.30)
debian.ludost.net (79.98.105.18)
debian.mirror.ate.info (46.29.125.16)
debian.mirror.lhisp.com (185.36.180.99)
debian.mirrors.crysys.hu (152.66.249.132)
debian.netcologne.de (194.8.197.22)
debian.osuosl.org (140.211.166.134)
debian.redimadrid.es (193.145.15.16)
debian.redparra.com (37.134.4.158)
debian.revolsys.fr (94.23.208.222)
debian.simnet.is (194.105.226.20)
debian.superhosting.cz (95.168.211.41)
debian.tu-bs.de (134.169.192.30)
debian.ues.edu.sv (168.232.49.158)
debian.usu.edu (129.123.104.15)
debian.uvigo.es (193.146.32.74)
debian.volia.net (82.144.192.7)
debian.xtdv.net (118.69.65.177)
dennou-k.gfd-dennou.org (130.54.59.159)
dennou-q.gfd-dennou.org (133.5.166.3)
freedom.dicea.unifi.it (150.217.9.3)
free.hands.com (78.129.164.123)
ftp2.cn.debian.org (101.6.6.178)
ftp2.de.debian.org (137.226.34.46)
ftp.acc.umu.se (194.71.11.165)
ftp.antik.sk (88.212.10.12)
ftp.arnes.si (193.2.1.88)
ftp.be.debian.org (195.234.45.114)
ftp.belnet.be (193.190.67.98)
ftp.bg.debian.org (62.44.96.11)
ftp.br.debian.org (200.236.31.3)
ftp.caliu.cat (147.83.91.172)
ftp.cc.uoc.gr (147.52.159.12)
ftp.ch.debian.org (129.132.53.171)
ftp-chi.osuosl.org (64.50.236.52)
ftp.cn.debian.org (202.38.95.110)
ftp.crifo.org (163.172.198.88)
ftp.cz.debian.org (195.113.161.73)
ftp.debianclub.org (203.150.226.27)
ftp.debian.cz (195.113.161.73)
ftp.debian.nl (194.109.21.67)
ftp.de.debian.org (141.76.2.4)
ftp.dk.debian.org (130.225.254.116)
ftp.fau.de (131.188.12.211)
ftp.gwdg.de (134.76.12.6)
ftp.halifax.rwth-aachen.de (137.226.34.46)
ftp.icm.edu.pl (193.219.28.2)
ftp.iitm.ac.in (203.199.213.69)
ftp.is.debian.org (194.105.226.20)
ftp.jaist.ac.jp (150.65.7.130)
ftp.jp.debian.org (133.5.166.3)
ftp.lanet.kr (112.169.81.204)
ftp-master.debian.org (138.16.160.17)
ftp.metu.edu.tr (144.122.144.177)
ftp.mpi-sb.mpg.de (139.19.205.14)
ftp.nluug.nl (145.220.21.40)
ftp.no.debian.org (194.71.11.165)
ftp-nyc.osuosl.org (64.50.233.100)
ftp-osl.osuosl.org (140.211.166.134)
ftp.rnl.tecnico.ulisboa.pt (193.136.164.6)
ftp.se.debian.org (194.71.11.165)
ftp.sg.debian.org (210.23.25.77)
ftp.sh.cvut.cz (147.32.127.196)
ftp-stud.hs-esslingen.de (129.143.116.10)
ftp.tu-graz.ac.at (129.27.3.13)
ftp.udc.es (193.144.61.75)
ftp.uk.debian.org (78.129.164.123)
ftp.uni-mainz.de (134.93.178.166)
ftp.uni-sofia.bg (62.44.96.11)
ftp.u-strasbg.fr (130.79.200.5)
ftp.zcu.cz (147.228.57.10)
hanzubon.jp (61.115.118.67)
kambing.ui.edu (152.118.24.30)
merlin.fit.vutbr.cz (147.229.176.19)
mirror.0x.sg (210.23.25.77)
mirror.aarnet.edu.au (202.158.214.106)
mirror.amaze.com.au (122.252.2.42)
mirror.applebred.net (103.246.16.176)
mirror.as35701.net (195.234.45.114)
mirror.bytemark.co.uk (212.110.161.69)
mirror.cedia.org.ec (201.159.221.67)
mirror.checkdomain.de (46.4.50.2)
mirror.corbina.net (195.14.50.21)
mirror.crazynetwork.it (93.63.162.59)
mirror.csclub.uwaterloo.ca (129.97.134.71)
mirror.cse.iitk.ac.in (202.3.77.108)
mirror.cse.unsw.edu.au (129.94.242.25)
mirror.daniel-jost.net (88.198.52.102)
mirror.de.leaseweb.net (37.58.58.140)
mirror.dkm.cz (86.49.49.49)
mirror.hmc.edu (134.173.34.196)
mirror.i3d.net (213.163.76.200)
mirror.kku.ac.th (202.28.209.254)
mirror.liquidtelecom.com (197.155.77.1)
mirror.litnet.lt (193.219.61.87)
mirror.math.princeton.edu (128.112.18.21)
mirror.nexcess.net (208.69.120.55)
mirror.nforce.com (85.159.239.121)
mirror.nl.leaseweb.net (5.79.108.33)
mirror.one.com (46.30.211.12)
mirror.plusserver.com (85.25.85.13)
mirror.pmf.kg.ac.rs (147.91.204.28)
mirror.poliwangi.ac.id (36.67.40.211)
mirror.positive-internet.com (80.87.134.17)
mirror.pregi.net (202.90.159.172)
mirror.rit.edu (129.21.171.72)
mirrors.acm.jhu.edu (128.220.70.55)
mirrors.bloomu.edu (148.137.11.75)
mirrors.cat.pdx.edu (131.252.208.20)
mirrors.dcarsat.com.ar (186.33.231.17)
mirrors.dotsrc.org (130.225.254.116)
mirrorservice.org (212.219.56.184)
mirrors.evowise.com (89.45.92.5)
mirror.sinavps.ch (185.73.240.181)
mirrors.ircam.fr (129.102.1.37)
mirror.sjc02.svwh.net (72.5.72.15)
mirrors.kernel.org (198.145.20.143)
mirrors.linux.iu.edu (156.56.247.193)
mirrors.lug.mtu.edu (141.219.84.115)
mirrors.namecheap.com (209.188.21.32)
mirrors.netix.net (87.121.121.2)
mirrors.ocf.berkeley.edu (169.229.226.30)
mirrors.pdx.kernel.org (198.145.20.143)
mirrors.sfo.kernel.org (149.20.37.36)
mirrors.syringanetworks.net (66.232.64.7)
mirror.steadfast.net (208.100.4.53)
mirrors.tuna.tsinghua.edu.cn (101.6.6.178)
mirrors.ucr.ac.cr (163.178.174.25)
mirror.sucs.swan.ac.uk (137.44.10.8)
mirrors-usa.go-parts.com (69.46.22.133)
mirrors.ustc.edu.cn (202.38.95.110)
mirrors.wikimedia.org (208.80.154.15)
mirrors.xjtu.edu.cn (202.117.3.45)
mirrors.xmission.com (198.60.22.13)
mirrors.xservers.ro (89.38.249.150)
mirror.t-home.mk (195.26.153.65)
mirror.ueb.edu.ec (190.15.128.196)
mirror.units.it (140.105.48.55)
mirror.usertrust.info (24.26.241.22)
mirror.us.leaseweb.net (108.59.10.97)
mirror.uta.edu.ec (200.93.227.165)
mirror.vorboss.net (5.10.144.130)
mirror.yandex.ru (213.180.204.183)
oyu-net.jp (61.206.119.174)
packages.hs-regensburg.de (194.95.104.50)
pkg.adfinis-sygroup.ch (95.128.34.165)
pubmirror.plutex.de (109.69.67.245)
rsync.osuosl.org (140.211.166.134)
security-master.debian.org (82.195.75.93)
sft.if.usp.br (143.107.129.14)
shadow.ind.ntou.edu.tw (140.121.80.200)
suro.ubaya.ac.id (203.114.224.252)
syncproxy2.eu.debian.org (130.89.148.10)
syncproxy2.wna.debian.org (149.20.4.16)
syncproxy3.eu.debian.org (5.153.231.9)
syncproxy3.wna.debian.org (209.87.16.40)
syncproxy.au.debian.org (150.203.164.60)
syncproxy.cna.debian.org (128.101.240.216)
the.earth.li (46.43.34.31)

                Regards, Axel
--
 ,''`.  |  Axel Beckert <[hidden email]>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Axel Beckert-8
Hi,

Axel Beckert wrote:
> After having HTTPS-enabled mirrors listed in the Mirrors.masterlist,
> the next step would be to make httpredir.debian.org HTTPS-aware.
> Currently https://httpredir.debian.org/ shows me the following error
> message:
>
>   httpredir.debian.org uses an invalid security certificate.
>   The certificate is only valid for www.debian.org

Due to starting reading the debian-mirrors list from a different
e-mail address recently, I missed the anouncement of
httpredir.debian.org having died and being redirected to
deb.debian.org -- which actually is available via HTTPS.

So ignore that part of my mail which was about
https://httpredir.debian.org/.

                Regards, Axel
--
 ,''`.  |  Axel Beckert <[hidden email]>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Kurt Roeckx
In reply to this post by Axel Beckert-8
On Thu, Apr 06, 2017 at 11:20:36PM +0200, Axel Beckert wrote:
> * https://mirror.as35701.net/debian/ (not yet accessible as
>   https://ftp.be.debian.org/debian/ due to certificate only being
>   valid for mirror.as35701.net)

It's easy enough to also add ftp.be.debian.org to the certificate,
but I didn't do it because I don't feel like I have permission to
do so.


Kurt

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Mattias Wadenstein
In reply to this post by Axel Beckert-8
On Thu, 6 Apr 2017, Axel Beckert wrote:

> * https://ftp.se.debian.org/debian/ (ftp.no.debian.org seems to point
>  to the same host, but is not yet accessible via HTTPS due to not
>  being listed in the certificate)

Hm, OK. We'll add ftp.no.d.o to our list of hostnames for LE.

We've been a bit slow in announcing https support due to not being done
with hardware updates to get CPUs that don't max out when filling the
network link, but that replacement procedure is almost done.

/Mattias wadenstein

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTPS metadata in Mirrors.masterlist?

Wouter Verhelst
In reply to this post by Kurt Roeckx
On Fri, Apr 07, 2017 at 12:25:04AM +0200, Kurt Roeckx wrote:
> On Thu, Apr 06, 2017 at 11:20:36PM +0200, Axel Beckert wrote:
> > * https://mirror.as35701.net/debian/ (not yet accessible as
> >   https://ftp.be.debian.org/debian/ due to certificate only being
> >   valid for mirror.as35701.net)
>
> It's easy enough to also add ftp.be.debian.org to the certificate,
> but I didn't do it because I don't feel like I have permission to
> do so.

Why would that be the case? You run a service under ftp.be.d.o, and you
can verify that it is indeed you.

Perhaps this should be clarified on a mirror-admin level?

--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

12
Loading...