HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

Robin H. Johnson-2
Hi!

Upstream Chrome is discussing a potential change that we try to block
users following a HTTPS->HTTP for high-risk files, including tarballs.
https://lists.w3.org/Archives/Public/public-webappsec/2019Apr/0004.html

Further below is some quick analysis I did on the state of HTTP for the mirrors
that are presently listed only as HTTP.

In the era of LetsEncrypt, how many mirror administrators have a little time to
add HTTPS to their mirrors, along with a cronjob to auto-refresh the
certificates?

The state of HTTP/HTTPS on Gentoo mirrors:
  59 mirrors total
  =====
   1 HTTPS-only
  27 HTTP+HTTPS
  31 HTTP-only

Of the HTTP-only mirrors, only 1 is on a non-standard port.

Of the HTTP-only mirrors, I went to test if of them had working HTTPS
that wasn't documented in distfiles.xml, and if not, what responses
there were (I think I got an off-by-one try to summarize the errors).

  2 200 OK
 24 No connection: Connection refused, Connection timed out, No route to host
  3 Horrible SSL certs
  2 SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match the expected, but everything else was otherwise good.
  1 HTTP on port 443 (SSL_ERROR_RX_RECORD_TOO_LONG)
====
 32 errors

Horrible SSL certs, error breakdown; some mirrors had MORE than one error in their cert:
3 - SEC_ERROR_UNKNOWN_ISSUER/The certificate issuer is unknown [1]
2 - The certificate chain uses insecure algorithm (RSA-SHA1)
3 - SEC_ERROR_EXPIRED_CERTIFICATE/The certificate chain uses expired certificate [2]
3 - SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match the expected.
1 - SEC_ERROR_UNRECOGNIZED_OID [3]

[1] SEC_ERROR_UNKNOWN_ISSUER:
- self-signed
- defunct CA
- missing intermediate

[2] SEC_ERROR_EXPIRED_CERTIFICATE:
Past-expiry ranges 1 month to 4 years ago!

[3] SEC_ERROR_UNRECOGNIZED_OID:
OpenSSL & GnuTLS handled this cert, but NSS failed on it.

--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : [hidden email]
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

Erwin Bronkhorst - Studenten Net Twente

Hello,

 

> Of the HTTP-only mirrors, I went to test if of them had working HTTPS
> that wasn't documented in distfiles.xml, and if not, what responses
> there were

 

I am a maintainer of the Gentoo mirror at ftp.snt.utwente.nl. In the distfiles.xml [1] we are listed as HTTP only, but I am happy to tell you that HTTPS works as well and we are fully supporting it. It this reply enough to get this fixed in the distfiles.xml, or do I have to mention/fix it somewhere else?

 

Greetings,

 

Erwin Bronkhorst

SNT FTPCom

 

[1] https://api.gentoo.org/mirrors/distfiles.xml

 

Van: Robin H. Johnson <[hidden email]>
Verzonden: zaterdag 13 april 2019 08:28
Aan: [hidden email]
Onderwerp: [gentoo-mirrors] HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

 

Hi!

Upstream Chrome is discussing a potential change that we try to block
users following a HTTPS->HTTP for high-risk files, including tarballs.
https://lists.w3.org/Archives/Public/public-webappsec/2019Apr/0004.html

Further below is some quick analysis I did on the state of HTTP for the mirrors
that are presently listed only as HTTP.

In the era of LetsEncrypt, how many mirror administrators have a little time to
add HTTPS to their mirrors, along with a cronjob to auto-refresh the
certificates?

The state of HTTP/HTTPS on Gentoo mirrors:
  59 mirrors total
  =====
   1 HTTPS-only
  27 HTTP+HTTPS
  31 HTTP-only

Of the HTTP-only mirrors, only 1 is on a non-standard port.

Of the HTTP-only mirrors, I went to test if of them had working HTTPS
that wasn't documented in distfiles.xml, and if not, what responses
there were (I think I got an off-by-one try to summarize the errors).

  2 200 OK
 24 No connection: Connection refused, Connection timed out, No route to host
  3 Horrible SSL certs
  2 SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match the expected, but everything else was otherwise good.

  1 HTTP on port 443 (SSL_ERROR_RX_RECORD_TOO_LONG)
====
 32 errors

Horrible SSL certs, error breakdown; some mirrors had MORE than one error in their cert:
3 - SEC_ERROR_UNKNOWN_ISSUER/The certificate issuer is unknown [1]
2 - The certificate chain uses insecure algorithm (RSA-SHA1)
3 - SEC_ERROR_EXPIRED_CERTIFICATE/The certificate chain uses expired certificate [2]
3 - SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match the expected.
1 - SEC_ERROR_UNRECOGNIZED_OID [3]

[1] SEC_ERROR_UNKNOWN_ISSUER:
- self-signed
- defunct CA
- missing intermediate

[2] SEC_ERROR_EXPIRED_CERTIFICATE:
Past-expiry ranges 1 month to 4 years ago!

[3] SEC_ERROR_UNRECOGNIZED_OID:
OpenSSL & GnuTLS handled this cert, but NSS failed on it.

--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : [hidden email]
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

Reply | Threaded
Open this post in threaded view
|

Re: HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

Fredrik Eriksson
In reply to this post by Robin H. Johnson-2
Hi,

I'm the maintainer of mirror.mdfnet.se. The future of this mirror is not
entirely clear (it may have to be removed in a few weeks/months), but
for now I've added a letsencrypt certificate, opened it up for https and
will make sure to maintain it for as long as the mirror is available.

/Feffe


On 2019-04-13 08:28, Robin H. Johnson wrote:

> Hi!
>
> Upstream Chrome is discussing a potential change that we try to block
> users following a HTTPS->HTTP for high-risk files, including tarballs.
> https://lists.w3.org/Archives/Public/public-webappsec/2019Apr/0004.html
>
> Further below is some quick analysis I did on the state of HTTP for the mirrors
> that are presently listed only as HTTP.
>
> In the era of LetsEncrypt, how many mirror administrators have a little time to
> add HTTPS to their mirrors, along with a cronjob to auto-refresh the
> certificates?
>
> The state of HTTP/HTTPS on Gentoo mirrors:
>   59 mirrors total
>   =====
>    1 HTTPS-only
>   27 HTTP+HTTPS
>   31 HTTP-only
>
> Of the HTTP-only mirrors, only 1 is on a non-standard port.
>
> Of the HTTP-only mirrors, I went to test if of them had working HTTPS
> that wasn't documented in distfiles.xml, and if not, what responses
> there were (I think I got an off-by-one try to summarize the errors).
>
>   2 200 OK
>  24 No connection: Connection refused, Connection timed out, No route to host
>   3 Horrible SSL certs
>   2 SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match the expected, but everything else was otherwise good.
>   1 HTTP on port 443 (SSL_ERROR_RX_RECORD_TOO_LONG)
> ====
>  32 errors
>
> Horrible SSL certs, error breakdown; some mirrors had MORE than one error in their cert:
> 3 - SEC_ERROR_UNKNOWN_ISSUER/The certificate issuer is unknown [1]
> 2 - The certificate chain uses insecure algorithm (RSA-SHA1)
> 3 - SEC_ERROR_EXPIRED_CERTIFICATE/The certificate chain uses expired certificate [2]
> 3 - SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match the expected.
> 1 - SEC_ERROR_UNRECOGNIZED_OID [3]
>
> [1] SEC_ERROR_UNKNOWN_ISSUER:
> - self-signed
> - defunct CA
> - missing intermediate
>
> [2] SEC_ERROR_EXPIRED_CERTIFICATE:
> Past-expiry ranges 1 month to 4 years ago!
>
> [3] SEC_ERROR_UNRECOGNIZED_OID:
> OpenSSL & GnuTLS handled this cert, but NSS failed on it.
>

Reply | Threaded
Open this post in threaded view
|

Re: HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

SoEasyTo Mirrors Manager
Hi,

Being the maintainer of mirrors.soeasyto.com, which is currently
HTTP-only, having already the setup in place for LetsEncrypt on my
server, I'm about to set it up for my mirror.

Anyway, does it have to be HTTPS only ? ie., do I also have to set it up
to redirect HTTP requests over HTTPS (it's possible) ?

And same question as another maintainer before, do I have to create a
ticket on b.g.o. in order to notify of that change ?

Thanks in advance,

Regards,

Xavier - SoEasyTo Mirrors Manager

Le 2019-04-14 10:10, Fredrik Eriksson a écrit :

> Hi,
>
> I'm the maintainer of mirror.mdfnet.se. The future of this mirror is
> not
> entirely clear (it may have to be removed in a few weeks/months), but
> for now I've added a letsencrypt certificate, opened it up for https
> and
> will make sure to maintain it for as long as the mirror is available.
>
> /Feffe
>
> On 2019-04-13 08:28, Robin H. Johnson wrote:
>
>> Hi!
>>
>> Upstream Chrome is discussing a potential change that we try to block
>> users following a HTTPS->HTTP for high-risk files, including tarballs.
>> https://lists.w3.org/Archives/Public/public-webappsec/2019Apr/0004.html
>>
>> Further below is some quick analysis I did on the state of HTTP for
>> the mirrors
>> that are presently listed only as HTTP.
>>
>> In the era of LetsEncrypt, how many mirror administrators have a
>> little time to
>> add HTTPS to their mirrors, along with a cronjob to auto-refresh the
>> certificates?
>>
>> The state of HTTP/HTTPS on Gentoo mirrors:
>> 59 mirrors total
>> =====
>> 1 HTTPS-only
>> 27 HTTP+HTTPS
>> 31 HTTP-only
>>
>> Of the HTTP-only mirrors, only 1 is on a non-standard port.
>>
>> Of the HTTP-only mirrors, I went to test if of them had working HTTPS
>> that wasn't documented in distfiles.xml, and if not, what responses
>> there were (I think I got an off-by-one try to summarize the errors).
>>
>> 2 200 OK
>> 24 No connection: Connection refused, Connection timed out, No route
>> to host
>> 3 Horrible SSL certs
>> 2 SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not match
>> the expected, but everything else was otherwise good.
>> 1 HTTP on port 443 (SSL_ERROR_RX_RECORD_TOO_LONG)
>> ====
>> 32 errors
>>
>> Horrible SSL certs, error breakdown; some mirrors had MORE than one
>> error in their cert:
>> 3 - SEC_ERROR_UNKNOWN_ISSUER/The certificate issuer is unknown [1]
>> 2 - The certificate chain uses insecure algorithm (RSA-SHA1)
>> 3 - SEC_ERROR_EXPIRED_CERTIFICATE/The certificate chain uses expired
>> certificate [2]
>> 3 - SSL_ERROR_BAD_CERT_DOMAIN/The name in the certificate does not
>> match the expected.
>> 1 - SEC_ERROR_UNRECOGNIZED_OID [3]
>>
>> [1] SEC_ERROR_UNKNOWN_ISSUER:
>> - self-signed
>> - defunct CA
>> - missing intermediate
>>
>> [2] SEC_ERROR_EXPIRED_CERTIFICATE:
>> Past-expiry ranges 1 month to 4 years ago!
>>
>> [3] SEC_ERROR_UNRECOGNIZED_OID:
>> OpenSSL & GnuTLS handled this cert, but NSS failed on it.

Reply | Threaded
Open this post in threaded view
|

Re: HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

Robin H. Johnson-2
In reply to this post by Erwin Bronkhorst - Studenten Net Twente
On Sat, Apr 13, 2019 at 10:54:36AM +0200, Erwin Bronkhorst - Studenten Net Twente wrote:
> > Of the HTTP-only mirrors, I went to test if of them had working HTTPS
> > that wasn't documented in distfiles.xml, and if not, what responses
> > there were
> I am a maintainer of the Gentoo mirror at ftp.snt.utwente.nl
> <ftp://ftp.snt.utwente.nl> . In the distfiles.xml [1] we are listed as HTTP
> only, but I am happy to tell you that HTTPS works as well and we are fully
> supporting it. It this reply enough to get this fixed in the distfiles.xml,
> or do I have to mention/fix it somewhere else?
Yes, UTwente was one of the two mirrors that I detected with it.

I'll consider this formal assent to add it to distfiles.xml, thank you!

--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : [hidden email]
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

Robin H. Johnson-2
In reply to this post by Fredrik Eriksson
On Sun, Apr 14, 2019 at 10:10:38AM +0200, Fredrik Eriksson wrote:
> Hi,
>
> I'm the maintainer of mirror.mdfnet.se. The future of this mirror is not
> entirely clear (it may have to be removed in a few weeks/months), but
> for now I've added a letsencrypt certificate, opened it up for https and
> will make sure to maintain it for as long as the mirror is available.
Thank you, I will add a HTTPS URL.

--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : [hidden email]
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

Robin H. Johnson-2
In reply to this post by SoEasyTo Mirrors Manager
On Sun, Apr 14, 2019 at 12:27:51PM +0200, SoEasyTo Mirrors Manager wrote:
> Hi,
>
> Being the maintainer of mirrors.soeasyto.com, which is currently
> HTTP-only, having already the setup in place for LetsEncrypt on my
> server, I'm about to set it up for my mirror.
Thank you.

> Anyway, does it have to be HTTPS only ? ie., do I also have to set it up
> to redirect HTTP requests over HTTPS (it's possible) ?
Ideally, but not required (better security to do so).

> And same question as another maintainer before, do I have to create a
> ticket on b.g.o. in order to notify of that change ?
I'll update it, thanks.

--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : [hidden email]
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

Carlos Carvalho-3
In reply to this post by Robin H. Johnson-2
I've added https to gentoo.c3sl.ufpr.br.

Robin H. Johnson ([hidden email]) wrote on Wed, Apr 17, 2019 at 06:38:34PM -03:
> On Sat, Apr 13, 2019 at 10:54:36AM +0200, Erwin Bronkhorst - Studenten Net Twente wrote:
> > > It this reply enough to get this fixed in the distfiles.xml,
> > or do I have to mention/fix it somewhere else?
...
>
> I'll consider this formal assent to add it to distfiles.xml, thank you!

So please add us.

What about ftp crap? Can I get rid of ftp suppport in the gentoo mirror?? I've
already removed it for most repositories...

Reply | Threaded
Open this post in threaded view
|

Re: HTTPS deployments for mirrors: Potential Chrome changes; stats on the existing mirrors

Robin H. Johnson-2
On Fri, Apr 26, 2019 at 05:48:09PM -0300, Carlos Carvalho wrote:

> I've added https to gentoo.c3sl.ufpr.br.
>
> Robin H. Johnson ([hidden email]) wrote on Wed, Apr 17, 2019 at 06:38:34PM -03:
> > On Sat, Apr 13, 2019 at 10:54:36AM +0200, Erwin Bronkhorst - Studenten Net Twente wrote:
> > > > It this reply enough to get this fixed in the distfiles.xml,
> > > or do I have to mention/fix it somewhere else?
> ...
> >
> > I'll consider this formal assent to add it to distfiles.xml, thank you!
>
> So please add us.
>
> What about ftp crap? Can I get rid of ftp suppport in the gentoo mirror?? I've
> already removed it for most repositories...
The docs have said 'HTTP or FTP' for a long time. I removed FTP from the
recommendations for new mirrors now.

--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : [hidden email]
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

signature.asc (1K) Download Attachment