Re: [Hpr] https
I see that on the main a a warning icon on the https padlock saying "Parts of this page are not secure". I imagine this is what Chris was talking about originally. I will look into why this is happening and attempt to fix it over the holiday period. -- Regards, Ken Fallon (PA7KEN,G5KEN) https://kenfallon.com https://hackerpublicradio.org/hosts/ken_fallon ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] https
On 2021-12-22 01:27, dnt via Hpr wrote: I noticed today that the links in the navigation bar of hackerpublicradio.org actually hard code the http protocol, Bug. Fixed. Test. -- Regards, Ken Fallon (PA7KEN,G5KEN) https://kenfallon.com https://hackerpublicradio.org/hosts/ken_fallon ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] https
I noticed today that the links in the navigation bar of hackerpublicradio.org actually hard code the http protocol, so that even if you first navigate to https, once you click one of those links, you're taken to http (unless your browser enforces https everywhere, of course). —dnt Quoting Mad Sweeney (2021-12-18 15:42:04) > Hi, > > HSTS is trust on first use when used with a http to https redirect; > i.e. the browser remembers to use https for subsequent visits even if > the user continues to request http; the decision been forgotten if not > visited for the Max-Age in the header (typically several years). > That is much more secure than is being characterized in some of the > comments although no use to you if you've been pwned from day 1. > Whether you care to submit your site for inclusion in the HSTS preload > list is a different matter; it's not part of the spec. > > --Mad > > On 18/12/2021, dnt via Hpr wrote: > > 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 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
Re: [Hpr] https
Hi, HSTS is trust on first use when used with a http to https redirect; i.e. the browser remembers to use https for subsequent visits even if the user continues to request http; the decision been forgotten if not visited for the Max-Age in the header (typically several years). That is much more secure than is being characterized in some of the comments although no use to you if you've been pwned from day 1. Whether you care to submit your site for inclusion in the HSTS preload list is a different matter; it's not part of the spec. --Mad On 18/12/2021, dnt via Hpr wrote: > 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 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
Re: [Hpr] https
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 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 > >>>
Re: [Hpr] https
I use the althttpd web server [0] that doesn't itself provide HTTPS functionality but instead requires you to bolt it on using something like stunnel [1]. I've researched this topic previously and still haven't bothered to implement HTTPS for myself. I don't have any good reasons other than I just think it's not necessary for my silly little websites and I'm reflexively opposed to it just because it's being pushed so much. Sort of like a motorcycle helmet, it may be risky not to wear one, but please leave it up to me. Just the other day I was reading a post [2] on not using HTTPS and then this thread started so I thought I'd provide the link. Spoiler alert: he decided to provide an HTTPS option using a self-signed cert and no redirect. [0] https://sqlite.org/althttpd/doc/trunk/althttpd.md [1] https://www.stunnel.org/ [2] http://misc-stuff.terraaeon.com/articles/not-https.html ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] https
I fully concur with the observations expressed by various members of the mailing list regarding security implications of, for example, man-in-the-middle (MITM) scenario type attacks when offering HTTP traffic (even when just offered in addition to HTTPS traffic). Take the scenario of malware injected into an MP3 or OGG stream by a MITM attack scenario as described, for example, in [1]. Albeit the fact this has yet to be observed in the wild, it takes only one flawed media player in combination with the scenario as described in the quoted paper (and may this be as a third-party component carrying a zero-day and not even intended by the author - as the recent log4shell example clearly shows) to wreak havoc on desktop environments, mobile devices and beyond... Switching to a HTTPS-only approach eliminates this risk once and for all - a small price to pay given that even today's mobile / embedded devices carry enough computing power to address this without much overhead. Given the fact that even legacy devices contain enough computing power (by offloading crypto-processing to GPUs, for example; [2] dates back more than ten years; a), I don't see an issue with even older hardware being powerful enough to support modern encryption used by, say, TLS. More recent FLOSS approaches prove to be even more powerful [3]. Just my $.02 :-). Cheers, Chris (CISSP, CSSLP, CEH) [1] https://www.researchgate.net/publication/288646143_Code_Injection_Attacks_on_HTML5-based_Mobile_Apps_Characterization_Detection_and_Mitigation [2] https://github.com/heipei/engine-cuda [3] https://github.com/intel/QAT_Engine -- This email account is monitored seven days a week. ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] https
In my experience all podcatcher clients (at least that I've come across) support the redirects. The one thing to be really cautious of though is that your GUID is the HTTP URL... but don't change this over (or if you do, have a cut-off point in the PHP which generates the RSS) otherwise all your clients will re-download the links. The theory is that the GUID (Globally Unique ID) is used by the podcatchers to know what episodes have been consumed. This is why when sites transition to HTTPS, they see this string starting "http://; and think "Oh, that needs changing"... NO! It's just a "GUID" string, that is used to confirm "I don't need the episode matching that string again". Now, as to whether any systems actually do that... *shrug*. At one point, I toyed with using the SHA1 hash of the CCHits episode content as the GUID for my RSS feeds, but swiftly realised that was a mistake. Another question is whether Podcatching clients will honour HSTS? That one I'm not so sure of. -- Jon "The Nice Guy" Spriggs @jontheniceguy everywhere... https://jon.sprig.gs On Fri, 17 Dec 2021 at 09:21, wrote: > 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 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
Re: [Hpr] https
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 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
Re: [Hpr] https
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 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
Re: [Hpr] https
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
Re: [Hpr] https
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 -- This email account is monitored seven days a week. OpenPGP_signature Description: OpenPGP digital signature ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] https
HTTPS Everywhere is due to be deprecated by it's creator the EFF because "HTTPS is actually everywhere". https://www.eff.org/deeplinks/2021/09/https-actually-everywhere -- Jon "The Nice Guy" Spriggs @jontheniceguy everywhere... https://jon.sprig.gs On Wed, 15 Dec 2021 at 12:23, Kevin O'Brien wrote: > I use "https everywhere" in my browser, and I never had a problem with > the HPR site. I don't see that it is an issue. Yes, someone could do a > Man In The Middle attack to someone using the http site, but that is > really on the person using a non-encrypted connection in my view. And > I'm not sure why anyone would bother. I have no login credentials to > HPR that anyone could steal, and it is not exactly a secret that I > listen to and contribute to HPR. I personally have a security cert on > my sites because Google will downgrade them in search results if I > don't. > > Regards, > > > -- > Kevin B. O'Brien > zwil...@zwilnik.com > http://google.me/+kevinobrien > http://www.google.com/profiles/Ahuka5656 > http://about.me/zwilnik > > “People shouldn't be afraid of their government. Governments should be > afraid of their people.” - Alan Moore, V for Vendetta > > > On Wed, Dec 15, 2021 at 4:22 AM wrote: > > > > > Admins, > > > > > > Ever considered using an LE cert for https for the website and putting > a > > > redirect in place > > > to avoid browser security warnings? > > > > > > Cheers, Chris > > > -- > > > This email account is monitored seven days a week. > > > > > > ___ > > > Hpr mailing list > > > Hpr@hackerpublicradio.org > > > > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > > > > > > > We already have a https version of the site > https://hackerpublicradio.org > > > > Issued For hackerpublicradio.org > > Issued By cPanel, Inc., US ( cPanel, Inc. Certification Authority ) > > Signature Algorithm RSA-SHA256 > > > > If there is anyone browsing the https site and is getting unencrypted > > content back that should be fixed. Please ping me and I'll look into it. > > > > As far as discussing an automatic redirect from http to https, I would > > like to be convinced of the need to do this. Everything on HPR is public > > and open, so why should it be redirected to the encrypted version ? > > > > My personal (hpr host - not admin/janitor) mood on the topic is swaying > > between it allows people to be browsing the site more privately, to > > getting annoyed that this is been forced on everyone. So I for one would > > not be in favour of forcing people from http to https automatically. We > > already have a https site. If people want to use it then they may. If > they > > don't then they don't have to. > > > > What am I missing in the discussions ? > > > > -- > > Regards, > > > > Ken Fallon (PA7KEN,G5KEN) > > https://kenfallon.com > > https://hackerpublicradio.org/hosts/ken_fallon > > > > > > > > > > ___ > > 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
Re: [Hpr] https
Hi all, I know this is a _very_ edge case scenario, but having the http version allows for older, "vintage" computers to access the site easily. AFAIK, the HPR website doesn't use anything that would bring such machines to their knees, but I'd have to test that out. Anyway, just something to think about. -claudiom On Wed, Dec 15, 2021 at 7:23 AM Kevin O'Brien wrote: > I use "https everywhere" in my browser, and I never had a problem with > the HPR site. I don't see that it is an issue. Yes, someone could do a > Man In The Middle attack to someone using the http site, but that is > really on the person using a non-encrypted connection in my view. And > I'm not sure why anyone would bother. I have no login credentials to > HPR that anyone could steal, and it is not exactly a secret that I > listen to and contribute to HPR. I personally have a security cert on > my sites because Google will downgrade them in search results if I > don't. > > Regards, > > > -- > Kevin B. O'Brien > zwil...@zwilnik.com > http://google.me/+kevinobrien > http://www.google.com/profiles/Ahuka5656 > http://about.me/zwilnik > > “People shouldn't be afraid of their government. Governments should be > afraid of their people.” - Alan Moore, V for Vendetta > > > On Wed, Dec 15, 2021 at 4:22 AM wrote: > > > > > Admins, > > > > > > Ever considered using an LE cert for https for the website and putting > a > > > redirect in place > > > to avoid browser security warnings? > > > > > > Cheers, Chris > > > -- > > > This email account is monitored seven days a week. > > > > > > ___ > > > Hpr mailing list > > > Hpr@hackerpublicradio.org > > > > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > > > > > > > We already have a https version of the site > https://hackerpublicradio.org > > > > Issued For hackerpublicradio.org > > Issued By cPanel, Inc., US ( cPanel, Inc. Certification Authority ) > > Signature Algorithm RSA-SHA256 > > > > If there is anyone browsing the https site and is getting unencrypted > > content back that should be fixed. Please ping me and I'll look into it. > > > > As far as discussing an automatic redirect from http to https, I would > > like to be convinced of the need to do this. Everything on HPR is public > > and open, so why should it be redirected to the encrypted version ? > > > > My personal (hpr host - not admin/janitor) mood on the topic is swaying > > between it allows people to be browsing the site more privately, to > > getting annoyed that this is been forced on everyone. So I for one would > > not be in favour of forcing people from http to https automatically. We > > already have a https site. If people want to use it then they may. If > they > > don't then they don't have to. > > > > What am I missing in the discussions ? > > > > -- > > Regards, > > > > Ken Fallon (PA7KEN,G5KEN) > > https://kenfallon.com > > https://hackerpublicradio.org/hosts/ken_fallon > > > > > > > > > > ___ > > 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 > -- Claudio Miranda Contributor - Hacker Public Radio http://hackerpublicradio.org ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] https
I use "https everywhere" in my browser, and I never had a problem with the HPR site. I don't see that it is an issue. Yes, someone could do a Man In The Middle attack to someone using the http site, but that is really on the person using a non-encrypted connection in my view. And I'm not sure why anyone would bother. I have no login credentials to HPR that anyone could steal, and it is not exactly a secret that I listen to and contribute to HPR. I personally have a security cert on my sites because Google will downgrade them in search results if I don't. Regards, -- Kevin B. O'Brien zwil...@zwilnik.com http://google.me/+kevinobrien http://www.google.com/profiles/Ahuka5656 http://about.me/zwilnik “People shouldn't be afraid of their government. Governments should be afraid of their people.” - Alan Moore, V for Vendetta On Wed, Dec 15, 2021 at 4:22 AM wrote: > > > Admins, > > > > Ever considered using an LE cert for https for the website and putting a > > redirect in place > > to avoid browser security warnings? > > > > Cheers, Chris > > -- > > This email account is monitored seven days a week. > > > > ___ > > Hpr mailing list > > Hpr@hackerpublicradio.org > > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > > > > We already have a https version of the site https://hackerpublicradio.org > > Issued For hackerpublicradio.org > Issued By cPanel, Inc., US ( cPanel, Inc. Certification Authority ) > Signature Algorithm RSA-SHA256 > > If there is anyone browsing the https site and is getting unencrypted > content back that should be fixed. Please ping me and I'll look into it. > > As far as discussing an automatic redirect from http to https, I would > like to be convinced of the need to do this. Everything on HPR is public > and open, so why should it be redirected to the encrypted version ? > > My personal (hpr host - not admin/janitor) mood on the topic is swaying > between it allows people to be browsing the site more privately, to > getting annoyed that this is been forced on everyone. So I for one would > not be in favour of forcing people from http to https automatically. We > already have a https site. If people want to use it then they may. If they > don't then they don't have to. > > What am I missing in the discussions ? > > -- > Regards, > > Ken Fallon (PA7KEN,G5KEN) > https://kenfallon.com > https://hackerpublicradio.org/hosts/ken_fallon > > > > > ___ > 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
Re: [Hpr] https
Hi Ken,
There are two usually stated reasons for switching on HTTPS.
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.
The second item is usually the reason that people turn it on by-default.
For example, if you've gone to a coffee shop, and you join the free WiFi
there ("Bob's Coffee Shop WiFi") but it's actually the shady looking dude
in the corner's girlfriend with the MITM box in her handbag, and you browse
to an HTTP based site, then they *could* replace elements of the content
with content they wanted.
For an actual, real world example. In 2014, Comcast were still injecting
Javascript based adverts into HTTP websites you browsed to:
https://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/
Honestly, most web servers now have the CPU features enabled that don't
make stuff like HTTPS encryption-by-default a resource hog, so I'd be
happier knowing that HPR had it switched on... Otherwise "THE MAN" might be
able to add some javascript to your website to make me DDOS ubuntu.com (*)
;)
(*) Context, the "Great Firewall of China" added Javascript to pages served
by Baidu to make repeated requests to github's hosting of GFOC bypass
technologies in 2015 in an attempt to DDOS the site.
--
Jon "The Nice Guy" Spriggs
@jontheniceguy everywhere...
https://jon.sprig.gs
On Wed, 15 Dec 2021 at 09:24, wrote:
> > Admins,
> >
> > Ever considered using an LE cert for https for the website and putting a
> > redirect in place
> > to avoid browser security warnings?
> >
> > Cheers, Chris
> > --
> > This email account is monitored seven days a week.
> >
> > ___
> > Hpr mailing list
> > Hpr@hackerpublicradio.org
> > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
> >
>
> We already have a https version of the site https://hackerpublicradio.org
>
> Issued For hackerpublicradio.org
> Issued By cPanel, Inc., US ( cPanel, Inc. Certification Authority )
> Signature Algorithm RSA-SHA256
>
> If there is anyone browsing the https site and is getting unencrypted
> content back that should be fixed. Please ping me and I'll look into it.
>
> As far as discussing an automatic redirect from http to https, I would
> like to be convinced of the need to do this. Everything on HPR is public
> and open, so why should it be redirected to the encrypted version ?
>
> My personal (hpr host - not admin/janitor) mood on the topic is swaying
> between it allows people to be browsing the site more privately, to
> getting annoyed that this is been forced on everyone. So I for one would
> not be in favour of forcing people from http to https automatically. We
> already have a https site. If people want to use it then they may. If they
> don't then they don't have to.
>
> What am I missing in the discussions ?
>
> --
> Regards,
>
> Ken Fallon (PA7KEN,G5KEN)
> https://kenfallon.com
> https://hackerpublicradio.org/hosts/ken_fallon
>
>
>
>
> ___
> 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
Re: [Hpr] https
> Admins, > > Ever considered using an LE cert for https for the website and putting a > redirect in place > to avoid browser security warnings? > > Cheers, Chris > -- > This email account is monitored seven days a week. > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > We already have a https version of the site https://hackerpublicradio.org Issued For hackerpublicradio.org Issued By cPanel, Inc., US ( cPanel, Inc. Certification Authority ) Signature Algorithm RSA-SHA256 If there is anyone browsing the https site and is getting unencrypted content back that should be fixed. Please ping me and I'll look into it. As far as discussing an automatic redirect from http to https, I would like to be convinced of the need to do this. Everything on HPR is public and open, so why should it be redirected to the encrypted version ? My personal (hpr host - not admin/janitor) mood on the topic is swaying between it allows people to be browsing the site more privately, to getting annoyed that this is been forced on everyone. So I for one would not be in favour of forcing people from http to https automatically. We already have a https site. If people want to use it then they may. If they don't then they don't have to. What am I missing in the discussions ? -- Regards, Ken Fallon (PA7KEN,G5KEN) https://kenfallon.com https://hackerpublicradio.org/hosts/ken_fallon ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
Re: [Hpr] https
> Admins, > > Ever considered using an LE cert for https for the website and putting a > redirect in place > to avoid browser security warnings? > > Cheers, Chris > -- > This email account is monitored seven days a week. > > ___ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > We already have a https version of the site https://hackerpublicradio.org Issued For hackerpublicradio.org Issued By cPanel, Inc., US ( cPanel, Inc. Certification Authority ) Signature Algorithm RSA-SHA256 If there is anyone browsing the https site and is getting unencrypted content back that should be fixed. Please ping me and I'll look into it. As far as discussing an automatic redirect from http to https, I would like to be convinced of the need to do this. Everything on HPR is public and open, so why should it be redirected to the encrypted version ? My personal (hpr host - not admin/janitor) mood on the topic is swaying between it allows people to be browsing the site more privately, to getting annoyed that this is been forced on everyone. So I for one would not be in favour of forcing people from http to https automatically. We already have a https site. If people want to use it then they may. If they don't then they don't have to. What am I missing in the discussions ? -- Regards, Ken Fallon (PA7KEN,G5KEN) https://kenfallon.com https://hackerpublicradio.org/hosts/ken_fallon ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
[Hpr] https
Admins, Ever considered using an LE cert for https for the website and putting a redirect in place to avoid browser security warnings? Cheers, Chris -- This email account is monitored seven days a week. ___ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
