Re: Blocking high-risk non-secure downloads

On Fri, Apr 12, 2019 at 07:51:54PM -0700, Emily Stark wrote:
> > See Gentoo's mirrors page as an example:
> > https://www.gentoo.org/downloads/mirrors/
> >
> > Many of the mirrors have not yet deployed HTTPS, despite requests to do
> > so, or have deployed it in a way that was broken (self-signed certs,
> > misconfigured vhosts).
> >
> 
> Thanks for sharing this example! Do you have any more details about why the
> mirrors cannot support proper HTTPS?
The GeoDNS example, distfiles.gentoo.org, I provided below already, I'm
willing to replace that with a redirection bouncer as well as clearly
documenting where the mirror URLs are for users that wish to visit them
directly. 

That just leaves mirror operators that haven't deployed working HTTPS
(either haven't tried, or deployed something broken). I don't have any
solid details why, but I'm going to send out a query on the
gentoo-mirrors mailing list asking about it for you. 

> Even after seeing this example, I still feel a little iffy about requiring
> SRI when we could be requiring HTTPS. The mirrors are going to have to
> support HTTPS at some point; if not now, when? Unless we want to accept
> that they will always be HTTP, now seems like as good a time as any to
> require them to support HTTPS.
I'm saying as a tradeoff, require high-risk downloads to have SRI and/or
HTTPS, with a future requirement of HTTPS. In the ideal world there
would be both SRI & HTTPS, to help defend against hacked mirrors serving
bad content on a good URL.

However, it turns out to be moot:

Somebody else off-list pointing out that I would be relying on something
that was in the initial SRI draft, but removed in the final spec :-(.
https://www.w3.org/TR/2014/WD-SRI-20140318/#downloads-1
<a href="..." integrity="...">...</a>

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136