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: 1, Insightful) by Anonymous Coward on Wednesday July 25 2018, @12:32PM (2 children)

    by Anonymous Coward on Wednesday July 25 2018, @12:32PM (#712288)

    https is overrated, in my opinion because it provides a false sense of security. There is no way I would connect to anything important without it, but isn't the solution to all of the internet's security woes. There is a better way to do away with plain http than shaming.

    They are taking the wrong approach. Instead of shaming http, https should be the default protocol if not specified in the address bar. Defaulting to http leaves the user suspect to a MiTM 301ing them to an interception proxy on a domain they control. If the domain the proxy is on uses https, they will get the green lock and everything. It will still be the real site. It will still function as normal. Is the average user going to notice this?

    https won't prevent social engineering.

    DNS and router logs can reveal what you connected to.

    https won't protect you from bugs in your browser or web applications. Languages with anal retentive type systems, like Haskell and Ada, can prevent a lot of bugs and still produce fast, native code. They aren't a magic bullet either, but a step in the right direction. Mucking around with the UI on the browser and server side instead of the core logic certainly doesn't help. I actually liked the way things looked in the early/mid 2000s better than today.

    malware downloaded from the "clean your pc" ads over https just means you know you are getting the real malware.

    https is a pain to proxy. If you have as many machines as I do, there is no way you wouldn't proxy linux package repositories. I have to disseminate a local CA cert and use squid's ssl-bump feature to cache https repos. I don't want to modify the .list and .repo files because I want to get the latest version through the package that created them.

    Starting Score:    0  points
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  

    Total Score:   1  
  • (Score: 1, Insightful) by Anonymous Coward on Wednesday July 25 2018, @01:29PM

    by Anonymous Coward on Wednesday July 25 2018, @01:29PM (#712316)

    I tend to agree.

    While https may increase resistance to MITM, it also makes reverse engineering web site and browser functionality vastly more difficult. Which is to say fixing security problems above TCP gets harder. And it would seem quite a coincidence, that reverse engineering Googles vast client side surveillance drag net gets harder about the same time they get spanked for billions of dollars of privacy violations.

    More importantly MITM attacks violate existing computer intrusion laws in many states. So this is a technical solution, that gives up a freedom (the freedom to reverse engineer) to combat an act that is already a crime. So you ask: "Why doesn't Google file charges on behalf of their customers?"

    The answer is of course self evident.

    Overall, SSL everywhere drives up administrative complexity (and costs) for the WWW, and corresponding drives up the costs of free speech. If the related criminal statutes were enforced at the ISP level it wouldn't be neccessary. But clearly they aren't. So this really works for the ISP view that the web is really just a fancy broadcast cable TV network, and that full duplex digital interpersonal communications are just a fad.

    What happens after, is predictable. The big software vendors, the social media sites, and the ISP's will merge, and then they will proprieterize http itself. Breaking the whole Internet. If existing laws were enforced against corporations, as they are enforced against indeviduals, this wouldn't happen. Thanks SCOTUS for that.

    Clearly the liquidation of NN has already had a huge effect. When Google loads faster on TOR transmitted across transoceanic boundaries than it does over clearnet, obviously the carrier is selectively throttling competitors. So the "going dark" complaint by the FBI, can be largely said to have been caused by the FCC killing NN. By failing to defend the civil rights of everyone, the state has compelled the tech sector to defend itself.

    I think SSL everywhere is a defensive move on Googles part. And it wouldn't be neccessary if NN and related Constitutional rights were actually defended by the states when it comes to ISP interference with third party interpersonal communications. What SSL everywhere prevents, is already a crime. It just isn't prosecuted against corporations. If the state won't protect the public, then the public has the right to protect itself.

    One thing that should be noted by the shorts, is that there is a LOT of equipment in the networks of certain ISPs that becomes redundant if SSL everywhere becomes highly adopted. Which is to say that there are some switch companies that specialize in this kind of product, that will likely fail. And the companies that buy those products will also have to endure a great deal of expense at reengineering their networks, to remove all of the dirtbag surveillanceware that no longer works.

    So there will be at least one good thing that comes out of this.

  • (Score: 0) by Anonymous Coward on Wednesday July 25 2018, @08:14PM

    by Anonymous Coward on Wednesday July 25 2018, @08:14PM (#712634)

    Any security provides false sense of security because it isn't 100% secure. Therefore we shouldn't do anything. Wait a minute here…