Submitted via IRC for AndyTheAbsurd
As of today, Google begins shipping Chrome 68 which flags all sites served over the HTTP scheme as being "not secure". This is because the connection is, well, not secure so it seems like a fairly reasonable thing to say! We've known this has been coming for a long time now both through observing the changes in the industry and Google specifically saying "this is coming". Yet somehow, we've arrived at today with a sizable chunk of the web still serving traffic insecurely:
The majority of the Internet’s top 1M most popular sites will show up as “Not Secure” in @GoogleChrome starting July 24th. Make sure your site redirects to #HTTPS, so you don’t have the same problem. @Cloudflare makes it easy! #SecureOnChrome https://t.co/G2a0gi2aM8 pic.twitter.com/r2HWkfRofW
— Cloudflare (@Cloudflare) July 23, 2018
Who are these people?! After all the advanced warnings combined with all we know to be bad about serving even static sites over HTTP, what sort of sites are left that are neglecting such a fundamental security and privacy basic? I wanted to find out which is why today, in conjunction with Scott Helme, we're launching Why No HTTPS? You can find it over at WhyNoHTTPS.com (served over HTTPS, of course), and it's a who's who of the world's biggest websites not redirecting insecure traffic to the secure scheme:
The article continues with a list of "The World's Most Popular Websites Loaded Insecurely", tools and techniques used to gather the data, different responses based on the version of curl, differences accessing the bare domain name versus with the "www." prefix, and asks for any corrections. One can also access the aforementioned website set up specifically for tracking these results: https://whynohttps.com/.
(Score: 0) by Anonymous Coward on Wednesday July 25 2018, @09:50AM (6 children)
Enlighten me, what is that bad about encrypting content so that you want us to throw out of the window the benefits of encrypted traffic?
Are you working for a federal agency too [soylentnews.org]?
(Score: 4, Interesting) by Pino P on Wednesday July 25 2018, @01:24PM (5 children)
For sites on the public Internet, what's so bad about HTTPS is that there exists no signing-only cipher suite that allows intermediate caching while precluding tampering. If you're serving the same document to a plurality of users, such as serving an encyclopedia article to a classroom full of devices in a school in sub-Saharan Africa with a harshly metered 128 kbps connection, you want a replay attack to be possible. Otherwise, what's the benefit of the HTTP header Cache-Control: public in an HTTPS environment?
Sites on a private home network have a different problem with HTTPS. in order to qualify for a certificate, you need a domain name. Let's Encrypt will not issue a certificate if any of the following are true:
So if you can't find a dynamic DNS provider that both is on the PSL and supports TXT records, you end up having to buy a domain name and continuing to pay for its renewal.
(Score: 0) by Anonymous Coward on Wednesday July 25 2018, @08:08PM (1 child)
Non-encrypted signing only thing allows for surveillance and data mining.
(Score: 2) by Pino P on Thursday July 26 2018, @04:41PM
In parts of the world where all Internet connections are very slow and very harshly capped, people are likely to consider "surveillance and data mining" an acceptable tradeoff.
(Score: 2) by urza9814 on Thursday July 26 2018, @05:00PM (2 children)
Take one of those laptops and turn it into a caching proxy that drops the encryption. For bonus points, re-encrypt using a self-signed cert that you've already installed as trusted on the remaining laptops.
Why do you need a cert that's trusted on the global Internet for your private home network? Use self-signed certs and install them manually on whatever devices need it. That's a hell of a lot easier than getting a cert from Let's Encrypt or any other CA anyway. I *think* you could also use Let's Encrypt on a free domain like .tk if you configure the redirects properly, but I'm not 100% certain on that.
(Score: 3, Interesting) by Pino P on Thursday July 26 2018, @06:13PM (1 child)
The installation I'm referring to is currently using Polipo software, and Polipo's manual states that it tunnels all HTTPS connections using the CONNECT method. This means we'll have to use something other than Polipo. Which caching proxy software stack do you recommend for terminating HTTPS by issuing a temporary certificate from a private CA and using that to re-encrypt the cached resource?
Because operating systems for non-PC devices make it painful to install and trust a private CA certificate. A user-installed certificate on Android, for example, won't work in applications designed for Android 7 or later unless the app's developer opts in to trusting user CAs (search keywords: Network Security Config), and it may require changing the lock screen. Some set-top box operating systems offer no way to trust a private CA certificate at all.
(Score: 3, Informative) by urza9814 on Thursday July 26 2018, @07:25PM
Squidguard can proxy and filter HTTPS traffic so that would probably work...pretty sure you can configure caching on that too although I'm not 100% sure on that point. Looks like Privoxy with Stunnel would also work although that seems a bit more difficult to configure...