Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Google Chrome Privacy Security

Google Chrome Begins Warns Users About Insecure Pages (certsimple.com) 86

An anonymous reader shares an article on CertSimple, a firm that helps companies prove their identity on their websites: Today Chrome's stable channel was updated with a new HTTPS UI. The changes in these versions of Chrome (Chrome 53 for Windows, Mac users got them in Chrome 52) complete 'transition 1' in Google's HTTPS plans, first announced in December 2014: T1: Non-secure origins marked as Dubious. In other words: Chrome now explicitly tells users non-HTTPS sites aren't private. If a Chrome user visits a site that isn't private -- for example, there's no HTTPS, broken HTTPS, or HTTPS only on 'checkout' pages -- Chrome now displays a mid-grey colored info box.
This discussion has been archived. No new comments can be posted.

Google Chrome Begins Warns Users About Insecure Pages

Comments Filter:
  • by Anonymous Coward

    "Google Chrome Begins Warns Users About Insecure Pages"

    Good work, editors.

    • don't you know that current slashdot editors believe that adding 's' to verbs is more secure. they will duplicate the story later in the day to ensure.

  • by 110010001000 ( 697113 ) on Friday September 02, 2016 @04:37PM (#52817939) Homepage Journal
    Google is a spyware company. Chrome is their spawn. You are their product.
    • by Anonymous Coward

      You beat me to it.

      All pages are insecure if you use Chrome.

  • by Anonymous Coward

    Many public wifis have a page they redirect you to. And they will redirect on https as well. You have to tell your browser that you trust the page but there should be a better way to do the public wifi messages. Browser developers and wifi redirect engineers need to talk and should be able to develop a means of notifying user without making it incredibly difficult to accept.

    • Why can't public Wi-Fi use something like RADIUS [wikipedia.org], or at least a pre-shared key changed daily and posted on all cash registers, instead of a captive portal?

    • by epyT-R ( 613989 )

      Wouldn't having the cert signed by a public authority fix this?

      • In order to redirect HTTPS traffic to a login page you would need a valid certificate for wherever the user was trying to get to in the first place. Giving random wifi hotspot operators those kinds of certs would be very bad for security and very impractical.

    • by thsths ( 31372 )

      A public wifi login page is by definition insecure, so there should be a warning. And you should never enter any sensitive information, which also means that any password for a public wifi better not be an important one.

    • Most operating systems I've seen recently test if they can get to the internet themselves and if they are redirected to a captive portal they then automatically open a browser window to where the portal redirected them to (usually a login page). This avoids the issue of trying to MitM attack whatever site the user was trying to get to. You can still make the login page you get redirected to secure with proper certificates. The following are examples of the different things companies use in detecting if they

  • HTTPS on home LAN (Score:5, Insightful)

    by tepples ( 727027 ) <tepples.gmail@com> on Friday September 02, 2016 @04:43PM (#52817987) Homepage Journal

    And thus people will start seeing the "dubious" mark in the UI when accessing the web-based administration interface of a home router, a home NAS, or a home network printer, which lacks HTTPS because it lacks a certificate, in turn because it lacks a globally unique fully qualified domain name.

    Or should a device maker instead deploy the same wildcard certificate with the same private key on all of a given make and model?

    • by aix tom ( 902140 ) on Friday September 02, 2016 @05:13PM (#52818173)

      This. Plus, browser that puts warnings on all un-enctypted pages is somehow like a radio that warns before every song that the next song isn't encrypted and might be listened to by anybody. Or a barkeeper telling you at the bar "Don't talk so loud, the police might hear."

      Of course you should have the right to whisper any time you want. But you also should have the right to shout something for everybody to hear whenever you want, without somebody warning that you shouldn't do it.

  • by eyenot ( 102141 )

    Eyenot User Begins Just Smashing The Fuck Out Of This Headline With A Hammer

  • I'm not using Chrome. What's up Slashdot? Is this a time stamp thing?

  • by jez9999 ( 618189 ) on Friday September 02, 2016 @05:26PM (#52818251) Homepage Journal

    I used to think that maybe this kind of thing was a good idea, but I've changed my mind. There are all sorts of reasons you might not want to use HTTPS for a website, usually revolving around the fact that it is just a pain in the ass to set up and maintain (especially if you run your own server). It's often overkill during development, or in a situation where you're piggybacking on an already-secure connection like SSH.

    I suspect this is all to do with the desire of big corporations like Google to make the web more of a place for people with $$$. The money and time to setup and maintain SSL infrastructure.

    And yeah I know you can use Let's Encrypt... if you're happy to put up with ludicrously short certificate expiration times, or install their software on your server and configure it to work with whatever you're serving your certs with (good luck if it's not Apache). But that sucks, frankly.

    • I still think a better solution is to treat HTTP and self-signed HTTPS the same - giving no warning for them. By all means display a secure icon for HTTPS with a CA cert, but there's nothing inherently dangerous about an HTTP or self-signed HTTPS connection.

      • I agree. An even better thing would be to store the identity if the other side the first time when it is visited, warn the user when it changes afterwards, and leave the initial authentication to side channels. Like SSH does without manual keys. The certificate system with its dubious chain of trust is broken anyway. But corporations and authorities can't allow this, because that would make the Web more secure without giving them any control or other benefits.
    • by tepples ( 727027 )

      It's often overkill during development

      Chrome considers the loopback interface secure. If you can't use localhost because you're testing a web application on a mobile browser, you can run a private CA with OpenSSL and install its root certificate on your testing devices.

      And yeah I know you can use Let's Encrypt... if you're happy to put up with ludicrously short certificate expiration times, or install their software on your server and configure it to work with whatever you're serving your certs with

      You don't have to install Certbot (the canonical client recommended by LE) to get a certificate for a host in a domain that you own. Certbot is only one of many ACME clients that LE supports. Some of these clients support a DNS challenge, in which the CA asks you to put a TXT rec

  • Try reading it like this, "Google Chrome Warns Begins ...." What a terrible turn of phrase, get it together editors.

  • This story has been on the front page for two hours with a glaring error in the headline? Do you guys even look at the site?

  • by SlaveToTheGrind ( 546262 ) on Friday September 02, 2016 @09:12PM (#52819319)

    Google Chrome Begins Warns Users

    Come on, manishs, I know it's after beer thirty on a holiday weekend, but good grief -- this would take about 30 seconds to fix.

  • Chrome was one of the first to hide the "http://" prefix.

    That is exactly what "http://" means: no encryption, no authentication.

    And of course, some other browsers started to copy chrome in this regard.

    Stop hiding important information from the user!!!

    The browser UI was perfect around firefox 25 or so. It's gone downhill since.

    • by allo ( 1728082 )

      http vs https in the Adressbar were never a good indicator. People do not want to know if its http or https, they want to know if its secure or not.
      And we nerds should acknowlege, that http, spdy, http2, gopher or ftp should be the same for a transport protocol and the user does not need to care, but if its ftp or ftps is important to him.

  • Here we have still unencrypted pages that ask for the single sign on login information. And IT say that's ok, because the HTML POST request is sent off over https...

    I assume Google Chrome would think otherwise.

  • by frovingslosh ( 582462 ) on Saturday September 03, 2016 @02:28PM (#52822041)

    Google Chrome Begins Warns Users About Insecure Pages

    I've always wished for a job that involved no manual labor and no mental labor.

If you have a procedure with 10 parameters, you probably missed some.

Working...