[gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)

[gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

Hi,

Historically, the majority of our 'thirdpartymirrors' use HTTP or FTP. 
I've been putting some effort into switching to HTTPS whenever possible
(i.e. when the server's running HTTPS and has a valid certificate). 
However, the way things work people still have a pretty good chance of
hitting HTTP or FTP mirror instead.

Hence, I'd like to propose that whenever thirdpartymirrors contain HTTPS
mirrors for the group in question, we remove all HTTP and FTP
alternatives.  This way, if mirror:// is actually utilized, people won't
unnecessarily use unsecured connections.

I believe this falls in line with the generic policy of preferring HTTPS
over HTTP/FTP URIs.

Why is it useful?  In my opinion, the most important point is that it
stops third parties from sniffing what the Gentoo hosts are fetching
and using this information against them.

WDYT?

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)

[Piotr Karbowski]

[-- Attachment #1.1: Type: text/plain, Size: 626 bytes --]

Hi,

On 29/09/2019 11.56, Michał Górny wrote:
> WDYT?

You mean using HTTPS-only mirrors in 3rdparty mirrors? I am on board
with that.

Ideally, we would switch all of Gentoo resources to HTTPS too. I had a
short discussion about it in #-infra where I was looking for distfiles
and stage3 snapshots mirror roundrobin that is https enabled, this of
course require a huge changes and it unlikely come anytime soon, but for
what's it worth, I think no official Gentoo resource should default to
non encrypted HTTP, and the only http enabled traffic should be a 301
HTTP redirect to https address.

-- Piotr.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 505 bytes --]

Hi,

while I invested some time in the past updating thirdpartymirrors to add
HTTPS where possible too, I see no point in dropping non-HTTPS mirrors:

Just make sure that HTTPS mirrors are listed first.

From security point of view, we don't get anything from HTTPS because we
maintain and validate checksums for distfiles and thirdpartymirrors file
is only used for distfiles.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

On Sun, 2019-09-29 at 16:54 +0200, Thomas Deutschmann wrote:
> Hi,
> 
> while I invested some time in the past updating thirdpartymirrors to add
> HTTPS where possible too, I see no point in dropping non-HTTPS mirrors:
> 
> Just make sure that HTTPS mirrors are listed first.

This sounds like you're wrongly assuming that the package managers are
going to consult mirrors in order.  This isn't true.

> From security point of view, we don't get anything from HTTPS because we
> maintain and validate checksums for distfiles and thirdpartymirrors file
> is only used for distfiles.
> 

I'm really glad you've ignored the entire point I made in my original
post.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

>>>>> On Sun, 29 Sep 2019, Michał Górny wrote:

> Why is it useful?  In my opinion, the most important point is that it
> stops third parties from sniffing what the Gentoo hosts are fetching
> and using this information against them.

It won't hide the fact that a connection was established. Also, the
transferred data are public, and we verify them on the client side by
a checksum. So the advantage of https is very limited here.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

On Mon, 2019-09-30 at 07:04 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 29 Sep 2019, Michał Górny wrote:
> > Why is it useful?  In my opinion, the most important point is that it
> > stops third parties from sniffing what the Gentoo hosts are fetching
> > and using this information against them.
> 
> It won't hide the fact that a connection was established. Also, the
> transferred data are public, and we verify them on the client side by
> a checksum. So the advantage of https is very limited here.
> 

Many 'FTP' hosts belong to different tiers.  There's a major difference
between knowing that a user is fetching *something* from big mirror of
everything, and knowing the exact precise thing being fetched.  It may
mean knowing that the user is fetching vulnerable package (for whatever
reason).

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:

> Many 'FTP' hosts belong to different tiers.  There's a major difference
> between knowing that a user is fetching *something* from big mirror of
> everything, and knowing the exact precise thing being fetched.  It may
> mean knowing that the user is fetching vulnerable package (for whatever
> reason).

As Portage uses one connection per file, which exact file was downloaded can
still be inferred from the amount of transferred data (to a degree).

I agree that it is a step forward though, however small it is.


Best regards,
Chí-Thanh Christopher Nguyễn