GNU bug report logs - #56468
www.gnu.org doesn't change http: to https:

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56468 in the body.
You can then email your comments to 56468 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jerry Peek <jpeek <at> jpeek.com>
To: bug-diffutils <at> gnu.org
Subject: www.gnu.org doesn't change http: to https:
Date: Sat, 9 Jul 2022 10:03:45 -0700

[Message part 1 (text/plain, inline)]

Hi --

I just clicked on an old link to 
http://www.gnu.org/software/diffutils/manual/. Then the web browser 
showed the address http://www.gnu.org/software/diffutils/manual/ and 
marked it "insecure". So I tried 
https://www.gnu.org/software/diffutils/manual/ (with an s) and the 
browser showed that address.

I'm writing to suggest that you might add a redirect from 
http://www.gnu.org/software/diffutils/manual/ to 
https://www.gnu.org/software/diffutils/manual/ so that no one will get 
the "insecure" page.

Thanks --
Jerry Peek

PS: This might be true for other pages at www.gnu.org. I haven't checked.

[Message part 2 (text/html, inline)]

Message #10 received at 56468-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jerry Peek <jpeek <at> jpeek.com>
Cc: webmasters <at> gnu.org, 56468-done <at> debbugs.gnu.org
Subject: Re: [bug-diffutils] bug#56468: www.gnu.org doesn't change http: to
 https:
Date: Sat, 9 Jul 2022 14:03:58 -0500

On 7/9/22 12:03, Jerry Peek wrote:
> I just clicked on an old link to 
> http://www.gnu.org/software/diffutils/manual/. Then the web browser 
> showed the address http://www.gnu.org/software/diffutils/manual/ and 
> marked it "insecure". So I tried 
> https://www.gnu.org/software/diffutils/manual/ (with an s) and the 
> browser showed that address.
>
> I'm writing to suggest that you might add a redirect from 
> http://www.gnu.org/software/diffutils/manual/ to 
> https://www.gnu.org/software/diffutils/manual/ so that no one will get 
> the "insecure" page. 


Thanks for reporting this <https://bugs.gnu.org/56468>. The problem 
seems to be that when contacted via the HTTP protocol, www.gnu.org 
responds like the following, even though this doesn't make sense:

$ curl --head http://www.gnu.org
HTTP/1.1 200 OK
Date: Sat, 09 Jul 2022 18:55:16 GMT
Server: Apache/2.4.29
Content-Location: home.html
Vary: negotiate,accept-language,Accept-Encoding
TCN: choice
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Frame-Options: sameorigin
X-Content-Type-Options: nosniff
Access-Control-Allow-Origin: (null)
Accept-Ranges: bytes
Cache-Control: max-age=0
Expires: Sat, 09 Jul 2022 18:55:16 GMT
Content-Type: text/html
Content-Language: en

The problem with this response is that HTTP clients are supposed to 
ignore the Strict-Transport-Security: header. That header makes sense 
only in an HTTPS response. www.gnu.org should respond like this:

$ curl --head http://www.github.com
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Location: https://www.github.com/

I'm forwarding this to webmasters <at> gnu.org, who are people who can fix 
this, and am closing this diffutils bug report <https://bugs.gnu.org/56468>.

Message #13 received at 56468-done <at> debbugs.gnu.org (full text, mbox):

From: "Andrew Engelbrecht via RT" <sysadmin <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 56468-done <at> debbugs.gnu.org
Subject: [gnu.org #1853606] Re: [bug-diffutils] bug#56468: www.gnu.org doesn't
 change http: to https:
Date: Thu, 28 Jul 2022 15:08:46 -0400

On Sat Jul 09 15:04:09 2022, eggert <at> CS.UCLA.EDU wrote:
> On 7/9/22 12:03, Jerry Peek wrote:
> > I just clicked on an old link to 
> > http://www.gnu.org/software/diffutils/manual/. Then the web browser 
> > showed the address http://www.gnu.org/software/diffutils/manual/ and 
> > marked it "insecure". So I tried 
> > https://www.gnu.org/software/diffutils/manual/ (with an s) and the 
> > browser showed that address.
> >
> > I'm writing to suggest that you might add a redirect from 
> > http://www.gnu.org/software/diffutils/manual/ to 
> > https://www.gnu.org/software/diffutils/manual/ so that no one will get 
> > the "insecure" page. 

Hi,

Sorry about the delayed reply. We want to support both HTTPS and HTTP, for those who are using old browsers with outdated ciphers, etc. The HSTS rule is there for people who do visit the HTTPS site, so they will automatically use it in the future.

I would personally lean towards more HTTPS, but so far, gnu.org is an exception to that. More discussion is welcome.

Thanks,
Andrew

Message #16 received at 56468 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: sysadmin <at> gnu.org
Cc: jpeek <at> jpeek.com, 56468 <at> debbugs.gnu.org
Subject: Re: [gnu.org #1853606] Re: [bug-diffutils] bug#56468: www.gnu.org
 doesn't change http: to https:
Date: Thu, 28 Jul 2022 13:23:58 -0700

On 7/28/22 12:08, Andrew Engelbrecht via RT wrote:

> We want to support both HTTPS and HTTP, for those who are using old browsers with outdated ciphers, etc. The HSTS rule is there for people who do visit the HTTPS site, so they will automatically use it in the future.

That sort of thing made sense years ago. But nowadays all the top 
websites (google.com, youtube.com, facebook.com, wikipedia.org, 
twitter.com, reddit.com, amazon.com, etc.) redirect HTTP to HTTPS. For 
example:

  $ curl --head http://wikipedia.org
  HTTP/1.1 301 TLS Redirect
  Date: Thu, 28 Jul 2022 20:21:38 GMT
  Server: Varnish
  X-Varnish: 376727111
  X-Cache: cp4029 int
  X-Cache-Status: int-front
  Server-Timing: cache;desc="int-front", host;desc="cp4029"
  Permissions-Policy: interest-cohort=()
  Set-Cookie: 
WMF-Last-Access=28-Jul-2022;Path=/;HttpOnly;secure;Expires=Mon, 29 Aug 
2022 12:00:00 GMT
  Set-Cookie: 
WMF-Last-Access-Global=28-Jul-2022;Path=/;Domain=.wikipedia.org;HttpOnly;secure;Expires=Mon, 
29 Aug 2022 12:00:00 GMT
  X-Client-IP: 2603:8001:6407:db8d:2280:c8bd:bd1c:bace
  Location: https://wikipedia.org/
  Content-Length: 0
  Connection: keep-alive


Essentially nobody uses browsers so old that they can't handle this, so 
gnu.org might as well do what major websites do. That way, we won't 
confuse and/or discourage ordinary users like the person who filed GNU 
Bug#56488.

Message #19 received at 56468 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: sysadmin <at> gnu.org
Cc: 56468 <at> debbugs.gnu.org, jpeek <at> jpeek.com
Subject: Re: [gnu.org #1853606] Re: [bug-diffutils] bug#56468: www.gnu.org
 doesn't change http: to https:
Date: Thu, 28 Jul 2022 16:04:22 -0700

On 7/28/22 15:16, Ian Kelling via RT wrote:

> If you
> can figure out a good test on the user agent string, please
> let us know.

Another possibility is to have the HTTP page load a script from HTTPS, 
and if that loads and runs correctly, have the script redirect to HTTPS. 
Or the script could do a more-elaborate test, such as checking whether 
the browser supports SNI. This should work for the use case prompting 
the bug report (a casual user on a modern browser), while not affecting 
ancient browsers, curl, etc. And it'd mean you wouldn't need to worry 
about maintaining a test based on user agent strings.

There's a 10-year-old serverfault post about doing this with SNI, here:

https://serverfault.com/questions/389806/redirect-to-ssl-only-if-browser-supports-sni

If you don't like the idea of a script, that post also talks about 
whitelisting user agents known to support SNI, whicch is more the sort 
of thing you're asking for.

Message #22 received at 56468 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jerry Peek <jpeek <at> jpeek.com>
Cc: sysadmin <at> gnu.org, 56468 <at> debbugs.gnu.org
Subject: Re: [gnu.org #1853606] Re: [bug-diffutils] bug#56468: www.gnu.org
 doesn't change http: to https:
Date: Fri, 29 Jul 2022 11:39:33 -0700

On 7/29/22 00:09, Jerry Peek wrote:
> I just pasted http://www.gnu.org/software/diffutils/manual/ into the 
> address bar on the latest version of six browsers: Firefox, Opera and 
> Microsoft Edge under Windows 10 and Firefox, Opera and DuckDuckGo 
> Privacy Browser under Android 12. All ended up with the address 
> https://www.gnu.org/software/diffutils/manual/ and a padlock or 
> checkmark showing a "secure" page.
> 
> Under older versions of Cygwin on Windows 10 (I'm not sure how to find 
> the Cygwin version), with GNU wget 1.21.1 and curl 7.76.0, that same 
> address did not seem to redirect to https:

Yes, I think that was the intent of the recent change. That is, 
www.gnu.org now acts more like www.google.com (and as you observed, not 
like www.wikipedia.org; see below). Whether this is the "best" is a 
matter of opinion, but clearly www.gnu.org is now in good company.

http://www.gnu.org is outputting a useless Strict-Transport-Security: 
header but as far as I know that's merely an inefficiency, not a bug.


$ curl --head http://www.gnu.org
HTTP/1.1 200 OK
Date: Fri, 29 Jul 2022 18:24:51 GMT
Server: Apache/2.4.29
Content-Location: home.html
Vary: negotiate,accept-language,Accept-Encoding
TCN: choice
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Frame-Options: sameorigin
X-Content-Type-Options: nosniff
Access-Control-Allow-Origin: (null)
Accept-Ranges: bytes
Cache-Control: max-age=0
Expires: Fri, 29 Jul 2022 18:24:51 GMT
Content-Type: text/html
Content-Language: en

$ curl --head http://www.google.com
HTTP/1.1 200 OK
Content-Type: text/html; charset=ISO-8859-1
P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."
Date: Fri, 29 Jul 2022 18:24:59 GMT
Server: gws
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Transfer-Encoding: chunked
Expires: Fri, 29 Jul 2022 18:24:59 GMT
Cache-Control: private
Set-Cookie: 1P_JAR=2022-07-29-18; expires=Sun, 28-Aug-2022 18:24:59 GMT; 
path=/; domain=.google.com; Secure
Set-Cookie: 
AEC=AakniGNul8AgwlW6sC5rGWuEvD--cweQ2yad1Ikhxj26O6Ch8rBqoR-UOME; 
expires=Wed, 25-Jan-2023 18:24:59 GMT; path=/; domain=.google.com; 
Secure; HttpOnly; SameSite=lax
Set-Cookie: 
NID=511=Yz43SAbjtYepJ9nfKqIqYjWR8jRXOtsC-M9HjFxCcycnwg5msMBkCZan5pfszqFU9umKm50lEvR14itBCequZk0xxIONvmoGa2mY3rku-ncBRywiX8T86qX_p7Elcl5exzGTLlDbDelFxQv7bBDw0os8bovMYIUSnP8izGWI0-A; 
expires=Sat, 28-Jan-2023 18:24:59 GMT; path=/; domain=.google.com; HttpOnly

$ curl --head http://www.wikipedia.org
HTTP/1.1 301 TLS Redirect
Date: Fri, 29 Jul 2022 18:25:09 GMT
Server: Varnish
X-Varnish: 123005163
X-Cache: cp1077 int
X-Cache-Status: int-front
Server-Timing: cache;desc="int-front", host;desc="cp1077"
Permissions-Policy: interest-cohort=()
Set-Cookie: 
WMF-Last-Access=29-Jul-2022;Path=/;HttpOnly;secure;Expires=Tue, 30 Aug 
2022 12:00:00 GMT
Set-Cookie: 
WMF-Last-Access-Global=29-Jul-2022;Path=/;Domain=.wikipedia.org;HttpOnly;secure;Expires=Tue, 
30 Aug 2022 12:00:00 GMT
X-Client-IP: 2603:8001:6407:db8d:a841:5d39:9c4c:b408
Location: https://www.wikipedia.org/
Content-Length: 0
Connection: keep-alive

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.