Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Wednesday July 25 2018, @06:07AM   Printer-friendly
from the wasn't-worth-the-work...-until-now? dept.

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/.

Source: https://www.troyhunt.com/why-no-https-heres-the-worlds-largest-websites-not-redirecting-insecure-requests/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Informative) by Anonymous Coward on Wednesday July 25 2018, @08:39AM (6 children)

    by Anonymous Coward on Wednesday July 25 2018, @08:39AM (#712226)

    The problem is that there's no protocol available for just signing your content. For public, static HTML pages that would be perfect: On one hand, cryptographic signatures would make sure that the content is not modified during transmission, while on the other hand the static content (and thus also static signature) not being encrypted by a session key would allow caching.

    So:

    • Completely unprotected transfer (HTTP): Bad.
    • Signed unencrypted transfer: Perfect for public, static content, but not available.
    • Encrypted transfer (HTTPS): Required for anything containing private/sensible information. In principle overkill for public, static content, but since the only available alternative is unacceptable, it's the best you can do.
    Starting Score:    0  points
    Moderation   +4  
       Insightful=1, Interesting=1, Informative=2, Total=4
    Extra 'Informative' Modifier   0  

    Total Score:   4  
  • (Score: 0) by Anonymous Coward on Wednesday July 25 2018, @10:19AM (5 children)

    by Anonymous Coward on Wednesday July 25 2018, @10:19AM (#712243)

    so browsers should allow me to completely forbid javascript whenver pure http is used.
    does that solve the problems you're talking about?
    or is it still possible for the man in the middle to replace the text of the website?

    • (Score: 2) by Pino P on Wednesday July 25 2018, @01:31PM (4 children)

      by Pino P (4721) on Wednesday July 25 2018, @01:31PM (#712317) Journal

      so browsers should allow me to completely forbid javascript whenver pure http is used.
      does that solve the problems you're talking about?

      Let's say you set up a network attached storage (NAS) device on your home LAN, and it offers a web interface for a user to browse the files stored on the device. Some of the more advanced features of this web interface, such as audio visualization and video playback in the full screen, use JavaScript. But in your proposal, websites on cleartext HTTP cannot use JavaScript. So what certificate should this NAS device use for HTTPS?

      • (Score: 0) by Anonymous Coward on Wednesday July 25 2018, @02:20PM (3 children)

        by Anonymous Coward on Wednesday July 25 2018, @02:20PM (#712350)

        nothing, because its pretty dumb to enforce such requirements on local network devices and appliances like that.

        hackers may read what you are doing on your home network and your IoTs might search it for midget porn, but i can take the risk if someone would at least let me make the decisions for myself.

        probably i wouldnt administrate anything with chrome anyway if the device is that old. i'd be using a dedicated old browser like an ancient esr of firefox or something like that, just for that purpose. provided there's no fat client or cli anyway

        i wish html wasnt used to dumbify stuff, since it just causes problems like this that shouldnt need solving.

        yeah someone will enable http admin access over the internet or something after giving a web managed device a public ip address or due to convenience because dumb, but i can't be held responsible for stupid unless its my stupid.

        • (Score: 2) by Pino P on Wednesday July 25 2018, @02:47PM (2 children)

          by Pino P (4721) on Wednesday July 25 2018, @02:47PM (#712379) Journal

          nothing, because its pretty dumb to enforce such requirements on local network devices and appliances like that.

          Yet the Secure Contexts spec [w3.org] does exactly that, on grounds that your web browser can't always tell the difference between a (relatively safe) home network and a (far more dangerous) public hotspot in a coffee shop. The only hostname exempt from the policy is localhost.

          probably i wouldnt administrate anything with chrome anyway if the device is that old.

          Even a brand new device would still need a certificate, which in turn needs a domain name. Should the manufacturer of a web-managed device be responsible for provisioning TLS certificates on the devices it ships? If so, that would encourage the manufacturer to terminate CA service for a device the day the warranty runs out, creating planned obsolescence and increasing the e-waste load. It would also exclude homemade IoT devices, such as a gateway modded to run DD-WRT or a device built around a Raspberry Pi single-board computer.

          provided there's no fat client or cli anyway

          i wish html wasnt used to dumbify stuff, since it just causes problems like this that shouldnt need solving.

          Other than a web application, what administration means would you prefer for a device on a home network? SSH? VNC-over-SSH? RDP? If so, you'd still need some way for the client to verify the device's server key fingerprint. You mention "fat client" as an alternative, but good luck running a binary-only, Windows-only fat client in any rational computing environment built on free software.

          • (Score: 2) by urza9814 on Thursday July 26 2018, @05:37PM (1 child)

            by urza9814 (3954) on Thursday July 26 2018, @05:37PM (#713242) Journal

            These devices *already* use HTTPS with self-signed certs. The ones I use won't even allow a non-secure connection. Sure, it's potentially not quite as secure as an "official" CA-issued cert, but it's still better than unsecured HTTP. It's not like the devices can't handle the overhead -- they already do. It's not like the companies can't find a way to set that up -- they've been doing it for years. I don't see the problem here...

            • (Score: 2) by Pino P on Thursday July 26 2018, @06:19PM

              by Pino P (4721) on Thursday July 26 2018, @06:19PM (#713280) Journal

              These devices *already* use HTTPS with self-signed certs. The ones I use won't even allow a non-secure connection.

              You must be using different brands of device from the brands I have used. The brands I have used default to cleartext HTTP precisely because current browsers provide a scarier warning for HTTPS using a certificate from an unknown issuer than for cleartext HTTP.