Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Chrome Google The Internet IT

In Encryption Push, Chrome Flags HTTP Sites as 'Not Secure' (zdnet.com) 268

Posted by msmash from the it's-finally-happening dept.
On Tuesday, Chrome started marking sites that don't use HTTPS as "not secure." From a report: First announced two years ago, Google said it would flag any site that still uses unencrypted HTTP to deliver its content in the latest version of Chrome, out Tuesday. It's part of the company's years-long effort effort to gradually nudge more webmasters and site owners into adopting HTTPS, a secure encryption standard for data in transit. Any site that doesn't load with green padlock or a "secure" message in the browser's address bar will be flagged -- and shamed -- as insecure.

[...] According to nightly data compiled by security experts Troy Hunt and Scott Helme, roughly 100 of the top 500 websites are still serving their pages over unencrypted HTTP -- all of which will today be flagged as "insecure." Many of those sites -- like Baidu, JD.com, and Google.cn -- are Chinese language sites, but many popular Western sites -- including BBC.com, DailyMail.co.uk, and Fedex.com -- are HTTP. Of the top million sites, a little over half do not redirect to HTTPS. Chrome 68 also brings with it Page Lifecycle API, and the Payment Handler API. From a report: The Payment Handler API builds on the Payment Request API, which helped users check out online. The new API enables web-based payment apps to facilitate payments directly within the Payment Request experience, as seen above. As with every version, Chrome 68 includes an update to the V8 JavaScript engine: version 6.8. It reduces memory consumption as well as includes improvements to array destructuring, Object.assign, and TypedArray.prototype.sort. Check out the full list of changes for more information.
This discussion has been archived. No new comments can be posted.

In Encryption Push, Chrome Flags HTTP Sites as 'Not Secure' More

In Encryption Push, Chrome Flags HTTP Sites as 'Not Secure'

Comments Filter:

  • MitM https proxies should be flagged too (Score:5, Interesting)

    by nyet ( 19118 ) on Tuesday July 24, 2018 @02:08PM (#57001772) Homepage

    All of this is pointless as long as we encourage corp IT firewall admins to completely break https with their MitM proxies that use fake wildcard certs and bogus CAs as part of a GP push.

    • Re:MitM https proxies should be flagged too (Score:5, Insightful)

      by Wrath0fb0b ( 302444 ) on Tuesday July 24, 2018 @03:02PM (#57002122)

      All of this is pointless as long as we encourage corp IT firewall admins to completely break https with their MitM proxies that use fake wildcard certs and bogus CAs as part of a GP push.

      It's not "breaking" HTTPs, any more that distributed authorized_keys "break" SSH. The owner of Group Policy on a machine has (by definition) the authority to set HTTPs policies, read files, spy on the screen and plant furry porn in your home directory. That's literally what it means to be in group policy.

      As I see it, the IT admins should be absolutely transparent with employees that all content touching the machine is subject to being recorded and have clear policies on whose approvals are necessary to go read the logs.

    • The problem:ALL HTTPS is insecure and allows MitM (Score:5, Informative)

      by Anonymous Coward on Tuesday July 24, 2018 @03:07PM (#57002162)

      The entire concept of certificate "authorities" is already fundamentally broken by design. (Kinda obvious, given the "argument from authority" fallacy.)

      I can not trust an organization that happens to host a website, but I'm supposed to trust an organization that happens to be a CA? Because the browser maker said so? Whose trustworthiness is not established either, by the way.

      If you want at least some trust, you either have to BE the CA (like with my own servers), or meet and get to know the person *personally*. Everything else is just hearsay, and of comparable trustworthiness to whatever you receive when you send out an unencrypted HTTP request to a random unknown domain.

      • Comment removed (Score:4, Interesting)

        by account_deleted ( 4530225 ) on Tuesday July 24, 2018 @04:46PM (#57002772)
        Comment removed based on user account deletion

        • BTW you made a very good point in this other post, though I don't think most people have the background knowledge to fully appreciate your point.
          https://tech.slashdot.org/comm... [slashdot.org]

          > They had to divest themselves of the CA business because they prove themselves repeatedly to be not trustworth

          Symnatec couldn't be trusted, therefore they couldn't have a CA business. That seems to indicate that untrustworthy companies can't be CAs (for long).

      • If you want at least some trust, you either have to BE the CA (like with my own servers), or meet and get to know the person *personally*. Everything else is just hearsay, and of comparable trustworthiness to whatever you receive when you send out an unencrypted HTTP request to a random unknown domain.

        How do you go to the grocery store? Surely you don't believe that unless you personally milked the cow, you can't know that it's milk and of comparable trustworthiness to any white liquid you find in a random

    • Re: (Score:2)

      by jaa101 ( 627731 )

      I'm sure there's an option to run Chrome with these warnings disabled. Any corporate IT capable of running a HTTPS proxy, requiring them to load an extra trusted cert on all their Chrome installs, is going to be able to activate this option. If Chrome lacks such an option it's just going to force companies to choose some other browser.

      So, yes, Google's move is good for personal and small business users who just run with all the defaults. But they have limited power to force changes on large businesses wi

  • Thanks Google! (Score:5, Insightful)

    by Anonymous Coward on Tuesday July 24, 2018 @02:21PM (#57001868)

    Thanks, Google, for breaking the internet.

    Misusing your power (client & server) to push people around and to shape a landscape favoring your business and nothing else. You are finishing the nightmare Microsoft tried to realize.

    Assholes.

    • Comment removed (Score:4, Insightful)

      by account_deleted ( 4530225 ) on Tuesday July 24, 2018 @03:20PM (#57002252)
      Comment removed based on user account deletion

      • Re:Thanks Google! (Score:5, Insightful)

        by Khyber ( 864651 ) <techkitsune@gmail.com> on Tuesday July 24, 2018 @05:08PM (#57002910) Homepage Journal

        The warning isn't fucking unobtrusive, that's the problem.

        Any time you do something Google doesnt' like, it makes sure to make a big fucking fuss about it.

        And that's going to give people the idea that the age they're trying to visit has been hijacked or otherwise when it has not.

        It's going to pretty much result in digital libel and defamation of the site as idiots who don't know better start spreading word that "site x is hacked because Google Said So."

        Too bad nerds like you quite often have shorter sight than your coke-bottle glasses lets on.

        • Re: (Score:2)

          by dissy ( 172727 )

          The warning isn't fucking unobtrusive, that's the problem.

          They changed the "(i)" icon to now say "(i) Not Secure" just to the left of the URL in the address bar.

          How is that obtrusive?

          Do you consider the padlock icon with the words "Secure" equally as obtrusive?
          They are now the exact same length as each other.

          Too bad nerds like you quite often have shorter sight than your coke-bottle glasses lets on.

          No, we just prefer to ignore assholes that make shit up that is demonstrably not true.

          This [bbci.co.uk] is literally the change you are bitching up a storm about as "The warning isn't fucking unobtrusive"

          • Re: (Score:2)

            by Khyber ( 864651 )

            Uh, no, how about a full-page warning going to http-only sites that are known-good yet Google classifies as 'dangerous sites?'

            JUST got that going to an HTTP site (one used for looking up MIDI files.)

            You apparently must be very new with Google and the internet in general despite your UID.

            Shut your mouth until you're fully-informed on the subject. It is apparent that you're only about 10% informed. Good day.

        • I hate when my age is hijacked!

      • W3C maintains a spec called Secure Contexts [github.io], which encourages web browsers to completely disable certain sensitive JavaScript features within HTML documents served over a cleartext HTTP connection. Only HTTPS and http://localhost/ [localhost] are allowed to use Service Workers, Geolocation, Payment Request, Presentation, and several other web platform APIs.

      • I'm failing to see how an unobtrusive warning that the webpage you're looking at wasn't served securely is "breaking the Internet".

        Dude I work corporate IT. Holy Crap will my phone ring off the phone tomorrow with HEEELLLP my intranet site is saying it is compromised! I probably will be working 16 hours a day without lunch telling everyone to use IE. Ugh.

        Yes it does brink corporate apps and remember business use is part of the internet as well and is HUGE. This is unacceptable as no where in the IEEE standards does it say WWW must be encrypted by default.

  • This is stupid garbage (Score:5, Insightful)

    by Anonymous Coward on Tuesday July 24, 2018 @02:26PM (#57001888)

    Most web sites don't need https. Most web sites don't take payments, don't transmit user data, etc.

    Bbc.com doesn't need encryption. My business site which doesn't take payments or allow user accounts does not need encryption. It's a wall of text and pictures.

    Google acting like the entire world needs this is incredibly stupid.

    I already have to use Firefox to access firewalls because Google decided that "go to the site anyway goddammit" just means "allow traffic for 2 minutes, and then complain about the certificate again. And again. And again"

    Now it's going to scare people for no reason. Screw them

    • Come on - http://www.miketaylor.org.uk/tech/oreilly/truenut.html [miketaylor.org.uk] needs to be encrypted. Think of the children.
      (any more cliches?)

    • Re: (Score:3)

      by Luthair ( 847766 )
      Insecure is an accurate description for HTTP. Further given the number of sites I've run into over the years showing locks and claiming to submit credit cards securely that are using HTTP I don't think this change is bad.

      • They say "not secure" rather than "insecure." It's a fair distinction, that makes more sense in the context. The least of the problems are the wording.

    • Re:This is stupid garbage (Score:5, Insightful)

      by Anonymous Coward on Tuesday July 24, 2018 @03:29PM (#57002304)

      Bbc.com doesn't need encryption.

      You visit bbc.com. The great firewall [wikipedia.org] inserts javascript to DoS attack another website.

      You visit bbc.com. You read a simple article about foreign policy. In between you and the BBC, the text of the article has been replaced, changing your knowledge of facts, your opinion, and ultimately your vote.

      You visit bbc.com. To preserve your privacy, you use a VPN or Tor. Your HTTP request has a BBC-UID cookie. Anyone snooping the connection can tell which link is yours as opposed to someone else's, and can track when you're there using the internet and which pages you go to.

      You visit bbc.com. You're an activist in a country which would like to not have you around. Instead of receiving bbc.com, you receive child porn. It only takes a minute for the police to be signalled and break down your door and confiscate your computer. In court, experts testify that you hid the CP in a clever place (the browser cache). Not only do you go away for life, but you're discredited to the public and the court, police and experts don't have to be in on it.

      Explain why it is essential to have bbc.com not be encrypted.

    • Most web sites don't need https. Most web sites don't take payments, don't transmit user data, etc. Bbc.com doesn't need encryption.

      Do you want your ISP to be able to see and use your browsing history? Do you want them to be able to block websites they deem inappropriate? Do you want Comcast to start injecting ads into websites like they've been caught doing before?

      What if your bbc.com login is the same as your bank login? What happens when you get hit by one of those router worms that are popping up all over the place? Hopefully most people on /. will not have this issue, but I guarantee you that this is the case for most users.

      Yes, Go

  • I have to wonder if we lockup all websites as viewable only via SSL - does that limit access to anything (historical) ? Alright - time to through away the crap, we can't keep everything.

    Why is bbc.com insecure because it uses HTTP? I understand why mybank.com would be insecure. I'm worried well lose something valuable when Chrome et al block (some day in the future) all of HTTP.

    Besides - it's only a matter of time before hackers move to SSL attacks. When the low hanging HTTP fruit is all gone, SSL loo

    • It's not just about securing the data in transit, it prevents tampering (eg. ISP or router injected ads) and tracking (your ISP cannot know what you visited on the site, just that you visited that particular ip and domain)

    • I have to wonder if we lockup all websites as viewable only via SSL - does that limit access to anything (historical) ?

      It would only affect servers where the admin is doing just barely enough maintenance to keep the site alive. HTTPS doesn't affect scripts running on the server, page rendering, etc. The content is not affected in any way, and really the only reason that anything at the application layer even needs to know about the encryption is because it has to listen/connect on port 443 instead of port 80.

    • Re: (Score:2)

      by AHuxley ( 892839 )
      More a way to keep ads secure per trusted site. Data to and from the browser. The browser has to trust approved ads for the site they use https with.
      See the site, get the approved secure ads.

    • Re: (Score:2)

      by jythie ( 914043 )
      I already run into problems with one of my NASes. Even if something uses HTTPS, the cert can be old or 'outdated' which Chrome can really complain about, sometimes not even giving you the option to view anyway. Really annoying for embedded devices that you don't replace constantly.

  • You shouldn’t have given Chrome market share (Score:3, Interesting)

    by xack ( 5304745 ) on Tuesday July 24, 2018 @02:53PM (#57002058)
    Now Chrome can do web controlling actions like security extortion. the next step will be making only google approved certificates complete with extortionate prices will be marked as secure. Join the resistance, get one of the xul trio of browsers Waterfox Pale Moon or Basilisk.

  • "Redirect" (Score:3)

    by darkain ( 749283 ) on Tuesday July 24, 2018 @03:12PM (#57002194) Homepage

    Their metric specifically mentions redirecting. One of the sites that I manage is an antique auto parts store. There is still a large fraction of our customers using Windows 98 era PCs. Due to this, automatic redirects from HTTP to HTTPS are disabled, so they can still browse the catalog and call us on the phone to order. Bots testing this site would notice the lack of redirection. However, modern browsers pass in some new additional headers which mention some HTTPS capabilities, and *IF* these headers are available, automatic redirection happens (since we know the client will be on a browser which supports the proper TLS version)

    I'm sure several of these other sites are using a similar approach. I just personally tested FedEx.com, and it is properly redirecting from HTTP to HTTPS in an up-to-date browser. So odds are that these bots testing these sites are not fully supplying all the same headers that browsers do.

    • Due to this, automatic redirects from HTTP to HTTPS are disabled,

      You can check the user-agent string before redirecting and still secure the majority and protect moderately aged browsers. And the rest should be warned heavily what risk they are under.

  • This kind of silliness wasn't what the web was designed for. The web was designed for the free dissemination of free information. Encryption and security are bolted-on hacks that not only don't work very well, but aren't at all in keeping with the original intent of the Web (or the whole Net, for that matter).

    I don't see any reason most web sites need to be encrypted.

    • Re: (Score:2)

      by Ksevio ( 865461 )
      Encrypting the material in transit doesn't make any less freely disseminated or the information less free. The access is suppose to be open, not snooping on other users. Maybe you're still running Lynx or something, but encryption and security are fairly well developed these days and work great!

      • Encrypting the material in transit doesn't make any less freely disseminated or the information less free.

        It prevents caching. Say a school in sub-Saharan Africa has only a 128 kbps, harshly metered connection for all its computers to use. With cleartext HTTP, if all the students visit the same encyclopedia page, a Polipo caching proxy inside the school can retrieve it once and serve it to 25 students in a classroom. But with HTTPS, the proxy can only handle the CONNECT verb to tunnel the connection to the origin server, causing transfer of 25 times as much data compared to the case with an intermediate cache.

    • Back when the web was designed, it was filled with engineers and technogeeks whose interest in information was one where your status and "street cred" depended on the value and veracity of your information.

      In the current time of fake news, lies and deceit, your status depends mostly on how many people you can dupe into hating your opponent in any way possible because you yourself don't have any positive traits either, so you have to get people to hate the other guy even more.

      In this climate, yes, I DO want

  • Software updates etc... (Score:5, Interesting)

    by Strider- ( 39683 ) on Tuesday July 24, 2018 @03:49PM (#57002438)

    Hopefully, though, software updates (such as Windows Update, Apple Update, etc...) will remain unencrypted. I run a network that services some remote communities via satellite, and those things are eminently cacheable (we have a WSUS server for our corporate computers).

    Before you get your panties in a twist about that being insecure, the way I recall these things working is that the update client fetches SHA256 sums of the update files via HTTPS, and then downloads the files over HTTP. That way, the updates can be cached locally, but the end user can still be assured that they haven't been tampered with.

    • internal apps / IPMI's don't need certs so why push this?

  • Crying Wolf (Score:5, Interesting)

    by nuckfuts ( 690967 ) on Tuesday July 24, 2018 @04:28PM (#57002662)
    The upshot of this is that users are going to become accustomed to ignore all such warnings and proceed to the site anyway. Rendering even legitimate warnings basically useless.
  • SSL does more than simply encrypt traffic. The biggest benefit of SSL for static web sites or information-only websites is that you can verify that you are connected to the right source. Some people mentioned content tampering and man-in-the-middle attacks, but what about a good old fashioned DNS cache poisoning? With SSL, you're not as susceptible to that type of attack.

    • Re: (Score:2)

      by chubs ( 2470996 )
      I do realize that DNS cache poisoning is often a means to an end to get to man-in-the-middle attacks, but the two are separate and warrant being talked about separately. With MITM attacks we often talk about surveillance and tampering, so we often talk about encryption and content validation, while we ignore the issue of source validation. I need to be sure not only that my data is unchanged, but that it came from who it claims to come from. The biggest benefit of SSL is CAs, from that perspective.

  • How about Chrome finally taking my word for it when I tell it I trust a particular cert even if it isn't officially signed by some entity I have never heard of.

    Meanwhile, if it's so important, why do they make it a pain in the ass for me to examine the cert used by a site? Shouldn't it be in the menu that drops down when I click on the lock icon?

    For that matter, why isn't it easy for me to tell Chrome that I do NOT trust a given cert no matter who signed it or that I don't trust a particular CA to sign off

    • Re: (Score:2)

      by Ksevio ( 865461 )

      How about Chrome finally taking my word for it when I tell it I trust a particular cert even if it isn't officially signed by some entity I have never heard of.

      The vast majority of users shouldn't be doing that. There are some exceptions (such as for developers), but Chrome should cater to the larger number even if it inconveniences the tiny a minority a little if it means greater security.

      Meanwhile, if it's so important, why do they make it a pain in the ass for me to examine the cert used by a site? Shouldn't it be in the menu that drops down when I click on the lock icon?

      Click the lock, click "Certificate" works for me

      For that matter, why isn't it easy for me to tell Chrome that I do NOT trust a given cert no matter who signed it or that I don't trust a particular CA to sign off on water being wet?

      Not a highly requested feature

      • Re: (Score:2)

        by sjames ( 1099 )

        Developers, admins, people using a private webmail, etc. In those cases, I know with greater certainty that I have the correct un-intercepted site than if a CA signed it. The option exists to temporarily accept the cert, why not be less of a pest? But make it equally easy to stop trusting the cert.

        Click the lock, click "Certificate" works for me

        It's not there, I just tried it. It used to be there once upon a time.

      • Re: (Score:2)

        by tepples ( 727027 )

        The vast majority of users shouldn't be doing [accepting certificates from an unknown issuer]. There are some exceptions (such as for developers), but Chrome should cater to the larger number even if it inconveniences the tiny a minority a little if it means greater security.

        You said home users shouldn't accept certificates from unknown issuers, and Let's Encrypt doesn't issue certificates for names in non-public TLDs. So what certificate should be used instead for a private HTTPS server on the home LAN, such as the configuration page for an Internet gateway or network printer?

  • HTTPS is centralizing the internet (Score:5, Interesting)

    by SkOink ( 212592 ) on Tuesday July 24, 2018 @05:04PM (#57002882) Homepage

    I'm all for encrypting web traffic, but this push for HTTPS-everything is kind of terrifying. It puts us in this dystopian future where we rely on CAs to decide whether or not we can visit a website.

    If a couple of CAs decide (or are told) to revoke my cert, there's literally nothing I can do about it. And all of a sudden my website is inaccessible to 90% of browsers, and there's nothing I can do about it.

    I would happily support some kind of peer-to-peer encryption scheme (HTTPS with no CA, maybe). But centralizing everything through CA gatekeepers is just asking for a government to butt in.

    • A revoked certificate isn't much different from a self-signed certificate. You can still connect to the server, there is just no guarantee that you're actually talking with the correct server. Which is something you kinda need someone to vouch for unless you want to manually verify every certificate of every server you communicate with.

      • Re: (Score:2)

        by SkOink ( 212592 )

        That's logically true, yeah - but browser UIs make it increasingly tough to accept self-signed certs. Tough enough that my grandma wouldn't be able to figure it out. Which effectively makes a revoked cert into a death sentence for a website.

  • Because we're now teaching the mantra of "encryption makes you secure", and people will swallow it. Unfortunately, it's not true. It is absolutely possible that you connect to hxtps://onlinebanking.bankofmurrica.com, log in and be surprised that suddenly your money is gone. Because encryption only means that traffic is secure between you and the target, and a certificate only says that the other side is who they claim to be.

    What a certificate cannot ensure is that you're really connected to who you think yo

Slashdot Top Deals

Say "twenty-three-skiddoo" to logout.

Close