Hi, https://https.cio.gov/hsts/ clearly advises against redirecting http to https, and it's easy to see how it doesn't deliver the desired security. Unfortunately Let's Encrypt kind of nudges people into the redirect.
The HSTS header being served only via https means a client that doesn't support https will never see it, so they will just keep getting the http site. Looking at it that way, I think there's really no downside to HSTS, as long as you don't redirect http to https. About the HSTS preload, I would probably skip it. It adds a dependency on a list maintained by others and takes away some control. -dnt Quoting k...@fallon.ie (2021-12-17 03:19:48) > Hi Mad et al., > > It's important we implement changes for a reason and not just because it > feels like the right thing to do. Just putting in a redirect will not > prevent tools like SSLstrip from taking the http connection and > manipulating the clients into thinking that they are on the HTTPS site > when in fact they are on the attackers site in clear text. > > To combat that we would need to implement HTTP Strict Transport Security > (HSTS). https://https.cio.gov/hsts/ "HSTS exists to remove the need for > the common, insecure practice of redirecting users from http:// to > https:// URLs." > > They go on to say that "In the long term, as the web transitions fully to > HTTPS and browsers can start phasing out plain HTTP and defaulting to > HTTPS, the HSTS preload list (and HSTS itself) may eventually become > unnecessary." > > So is there still value in doing this now ? We know all the browsers > support a redirect but do all the podcatcher clients ? > > Again I would appreciate thoughts on this topic, especially from the > security peeps out there. > > Ken. > > > Hi, > > > > I would prefer https to be the default by redirect for visits to > > hackerpublicradio.org or www.hackerpublicradio.org. > > For those who just want http you could have > > idontcareaboutsecurity.hackerpublicradio.org. > > That way everyone would have what they want. > > > > --Mad > > > > On 16/12/2021, Ken Fallon <k...@fallon.ie> wrote: > >> Hi Chris, > >> > >> > I concur with Jon and other people that the advantages of the use of > >> HTTPS far outweigh the disadvantages > >> > >> Yes and if this was about having a HTTPS site you would have a point. > >> > >> Let's review what everyone said. > >> > >> Jon's email has 2 points, > >> > >> > 1. Better SEO (not sure whether that's a thing that HPR will care > >> *that* much about?) > >> > 2. Reducing the risk of your ISP/Law Enforcement Community/Malicious > >> nare-do-well being able to man-in-the-middle a connection between you > >> (the browser/listener) and the web server, and inject content without > >> there being some sort of obvious injection. > >> > >> Both are covered by the fact we have a HTTPS site in place. Just to make > >> clear what I said before, if there are any cases when you are browsing > >> the HTTPS site and you are getting HTTP content then that is a bug which > >> we will fix. > >> > >> Kevin pointed out that if he goes to the http version of a site his > >> "https everywhere" extension will send him to the https version. > >> > >> Jon pointed out that that extension has been dropped and linked to the > >> EFF page which says "Now that world is closer than ever, with mainstream > >> browsers offering native support for an HTTPS-only mode." > >> > >> > > >> https://developers.google.com/search/blog/2014/08/https-as-ranking-signal > >> > >> > And that goes back seven years. > >> > >> Back in 2014 we got a lot of emails from Google about moving to HTTPS. > >> Which we did, and issues they found, which we fixed. We still get > >> regular emails whenever there is anything that the self appointed rulers > >> of the Internet feel would hamper our SEO there. > >> > >> So let's be clear what you are suggesting is that we remove the option > >> of having a http site on port 80 and force everyone to the https site on > >> 443. > >> > >> That will prevent claudio "vintage" computers from accessing the site > >> easily. It will also prevent low cost IOT devices like the ESP32's from > >> connecting to the site. They should all be using https as well but to > >> get the initial connection there is the http option available. > >> > >> So given that Google have no issues with our current situation, and that > >> the EFF are happy as browsers will automatically redirect to the HTTPS > >> version, and that it will make life harder for hackers, I still see no > >> argument for turning off http. > >> > >> Again what am I missing ? > >> > >> -- > >> Regards, > >> > >> Ken Fallon (PA7KEN,G5KEN) > >> https://kenfallon.com > >> https://hackerpublicradio.org/hosts/ken_fallon > >> > >> > >> On 2021-12-16 07:28, Christoph wrote: > >>> https://developers.google.com/search/blog/2014/08/https-as-ranking-signal > >>> > >>> And that goes back seven years. > >>> > >>> It's safe to assume that search engines like Google nowadays put more > >>> and more emphasis on HTTPS vs. HTTP for the reasons mentioned. I > >>> concur with Jon and other people that the advantages of the use of > >>> HTTPS far outweigh the disadvantages - that's precisely the reason why > >>> top-ranking sites have moved to a HTTPS-only approach > >>> long ago. > >>> > >>> So if we are serious about the episodes being found on search engine > >>> result pages and thus improving HPR's popularity in general, I propose > >>> putting a 301 in place. > >>> > >>> Cheers, Chris > >>> > >>> _______________________________________________ > >>> Hpr mailing list > >>> Hpr@hackerpublicradio.org > >>> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > >> > > > > > > > > > > _______________________________________________ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org _______________________________________________ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org