Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Chrome Google Security The Internet

More Than 50 Percent of All Pages In Chrome Are Loaded Over HTTPS Now (onthewire.io) 136

Reader Trailrunner7 writes: After years of encouraging site owners to transition to HTTPS by default, Google officials say that the effort has begun to pay off. The company's data now shows that more than half of all pages loaded by Chrome on desktop platforms are served over HTTPS. Google has been among the louder advocates for the increased use of encryption across the web in the last few years. The company has made significant changes to its own infrastructure, encrypting the links between its data center, and also has made HTTPS the default connection option on many of its main services, including Gmail and search. And Google also has been encouraging owners of sites of all shapes and sizes to move to secure connections to protect their users from eavesdropping and data theft. That effort has begun to bear fruit in a big way. New data released by Google shows that at the end of October, 68 percent of pages loaded by the Chrome browser on Chrome OS machines were over HTTPS. That's a significant increase in just the last 10 months. At the end of 2015, just 50 percent of pages loaded by Chrome on Chrome OS were HTTPS. The numbers for the other desktop operating systems are on the rise as well, with macOS at 60 percent, Linux at 54 percent, and Windows at 53 percent.
This discussion has been archived. No new comments can be posted.

More Than 50 Percent of All Pages In Chrome Are Loaded Over HTTPS Now

Comments Filter:
  • by Anonymous Coward on Friday November 04, 2016 @02:47PM (#53214307)

    loaded over...and then blanked out by JavaScript looking at Adblock's actions.

    do they really think my next action would be to disable Adblock? Really? I just close the tab and move onto another page...

  • Needless bullshit (Score:4, Insightful)

    by JustAnotherOldGuy ( 4145623 ) on Friday November 04, 2016 @02:52PM (#53214347)

    Yes, HTTPS is fine for anything sensitive, but does my recipe site really need to provide HTTPS pages?

    Seriously, there is no need for every site to output HTTPS pages. If you're really afraid that someone might eavesdrop and see you looking at Banana Bread recipes, you have bigger problems than an HTTPS connection can fix.

    • by kangsterizer ( 1698322 ) on Friday November 04, 2016 @02:57PM (#53214405)

      https also ensure the pages cannot be modified. if someone knows your recipe site, they trust you and its content.
      if tomorrow they visit and it asks for a donation for example, they'll think its for you and donate. bad luck, it was the attacker.

      basically, there is more than confidentiality issues ("they can see your data"). there's also integrity issues ("they can change the data displayed")

      besides - there's plenty of ways this can go wrong for confidentiality as well. there are billions of websites. some start as a recipe site, and end up asking login, processing password, etc. some not. people make mistakes along the way. its much safer and easier to basically require https across the board - specially that its pretty much free to do so now.

      • by tnok85 ( 1434319 )
        Hmmm, this Banana Bread recipe calls for dinitrotoluene... not sure what that is, but it sounds delicious!
      • Sad news for you, if an attacker can penetrate and change my banana bread website, it doesn't matter whether it what running https or http. you'll get their donation request and links via https with my trusty certificate.

        Or are you imagining hijacking and rerouting traffic? most https sites don't use HSTS so can still do that.

      • by Cramer ( 69040 )

        99.9999999999999999999999999999999999999999% of "rewriting" attacks happen on the webserver itself -- i.e. hacks that insert crap into your swiss cheese wordpress blog. The remaining rounding error are the result of local malware on the web browsing PC -- i.e. the browser inserted that crap. I have yet to even hear of a nefarious operation inserting crap into live traffic. (yes, there have been ISPs with aggressive proxies that can (and did) insert/modify content. If you cannot trust your ISP, you have othe

        • by tepples ( 727027 )

          yes, there have been ISPs with aggressive proxies that can (and did) insert/modify content. If you cannot trust your ISP, you have other problems that SSL won't always fix.

          Unfortunately, most of us are not in a position to move our families within the service area of a trustworthy ISP, if there even is a trustworthy ISP in our home country or any other country to which we hold an entry visa.

        • Last year [arstechnica.com], Github was hit by a DDoS caused by attack code injected into plain-text http:// traffic by someone in China.

          Let's assume for a moment that the attack on Github consisted of altering the contents of a single 50 byte packet. If that 50 byte packet corresponds to 0.0000000000000000000000000000000000000001% of rewritten traffic, then the remaining 99.9999999999999999999999999999999999999999% would correspond to 10^19 yottabytes of traffic.

          Bearing in mind that total global internet traffic is barely e

          • by Cramer ( 69040 )

            The JavaScript was silently injected into the traffic of sites that use an analytics service that China-based search engine Baidu makes available so website operators can track visitor statistics.

            It was just yet another "bad ad" hitting people. They didn't man-in-the-middle anyone's traffic to slip their code in. They didn't hack into thousands of websites to slip in their code. The ad network operators already used decided to push out malware instead of, or in addition to, a normal ad. This ALREADY happens all the damn time, except this time it was the ad network itself doing it and not one of their crafty customers.

            Someone rewriting traffic in transit is exceptionally rare. Because it's really har

            • Read the rest of the post. Strong evidence that the JS was being injected by a middle hop, notably one inside the network of the ISP responsible for China's great firewall.

              That they targeted an ad network doesn't mean it was yet another bad ad, it just means that the ad network was a good target because of the way it was included on many other sites.

      • more like google wants to be the only advertiser to you and not say your ISP or wireless carrier knowing which ads to push to your phone

        it's always about the $$$$$$$$$$$$$$$$$$$$$ and not some bullshit about making the world a better place

      • EFF HTTPS Everywhere

        https://www.eff.org/https-ever... [eff.org]

    • Without HTTPS, you can't trust the Chinese government to not MITM your recipe and add a superdose of red hot chilli pepper as an ingredient in your recipe. Once they do, expect to get sued for burning my tongue.
      • actually, 95% of https sites don't use HSTS with their HTTPS so they can still put chinese lead red paint in the recipe.

    • by Anonymous Coward

      does my recipe site really need to provide HTTPS pages?

      your choice of recipes will reveal if you have a health problem such as diabetes or food allergies

      you have bigger problems than an HTTPS connection can fix.

      Your inability to deal with more than one problem is YOUR problem

      • by tepples ( 727027 )

        I guess that depends on how much plausible deniability is built into a particular site's hostname. If you're on diabetesrecipes.info, for example, then your ISP can already see diabetesrecipes.info in cleartext in the Server Name Indication field of the TLS handshake. If the client doesn't send this field, the HTTPS server where diabetesrecipes.info is hosted won't know which certificate to send out of the hundreds of sites on the same IP address.

    • Re:Needless bullshit (Score:5, Informative)

      by swillden ( 191260 ) <shawn-ds@willden.org> on Friday November 04, 2016 @03:18PM (#53214497) Homepage Journal

      Yes, HTTPS is fine for anything sensitive, but does my recipe site really need to provide HTTPS pages?

      That depends, is every user's browser perfectly secure? (Hint: the answer is no)

      HTTPS provides three guarantees that HTTP does not.

      1. Secrecy. This is the one that you focused on; keeping the contents of the traffic between your recipe server and its clients secure against eavesdroppers. You're probably right that it doesn't matter.
      2. Authentication. HTTPS verifies to the client that it is talking to the server it thinks it is, rather than some other, possibly malicious, server.
      3. Integrity. HTTPS that the contents of the traffic between your reciper server and its clients is secure against modification.

      Both 2 and 3 are important individually, and together they provide an assurance that your clients are getting your content and nothing else. Not only does this mean the recipes won't be modified, but it means the recipe documents cannot be modified so they exploit browser vulnerabilities to hijack the user's browser, or possibly the user's entire computer.

      Of course, this still leaves open the possibility that your recipe server is malicious, either because you are or because someone else has taken control of it. Those possibilities are addressed by Safe Browsing infrastructure that attempts to identify and warn users away from malicious sites. But that only works if the browser actually knows what site it's talking to, so HTTPS is an essential enabling technology for Safe Browsing.

      • by Cramer ( 69040 )

        Actually, [i]EVERYTHING[/i] is pinned on #2. Unfortunately, the chain of trust for SSL certificates has been proven, over and over again, to be weak enough a toddler could toss a matchbox truck through it. The instant you get a browser to accept your certificate, the house of cards blows away.

        The simple truth is very little of the internet actually needs to be "protected" by SSL. Very few web sites are interesting ("valuable") enough to be worth the effort to divert or otherwise intercept their traffic. All

        • by Anonymous Coward

          Actually all non-ssl websites are very interesting to me, or more specifically to my special wifi access points that use squid to inject ads into everyone's web traffic who uses it.
          I make quite a bit of money off these things, but the whole scheme depends on websites not using ssl to work.

          Now sure, every so often some of those injected flash ads have malware in them, but that's the ad it's not my fault. I mean it's not like I can use quality ad delivery networks here, they actively stop this kind of thing,

          • by Cramer ( 69040 )

            For those playing along at home, this falls into the bucket of "I CANNOT TRUST MY ISP".

    • by Second_Derivative ( 257815 ) on Friday November 04, 2016 @03:27PM (#53214563)

      If a small amount of global web traffic is encrypted then the encrypted traffic will stand out and bring scrutiny.

      If everything is encrypted, no matter how mundane, then genuinely sensitive traffic becomes less conspicuous.

    • All of the responses to the OP miss his point. Not every website needs to pay the cost of encryption for no real reason. Yes it is a trivial cost on your recipe site, but not so much when you have a thousand hits a minute. For example, why encrypt a popular photography website? (Unless it has a login) When my website was slashdotted I was very glad it was not encrypted! Performance stayed good in spite of the slashdotting. But my monitoring showed it was at 90% plus for a few days! That extra bit of
      • All of the responses to the OP miss his point. Not every website needs to pay the cost of encryption for no real reason. Yes it is a trivial cost on your recipe site, but not so much when you have a thousand hits a minute.

        That's a good point.

        There's also the expense and upkeep of maintaining current certificates. I have 100+ sites currently, which means I could be renewing a cert every few days or have to do 100 of them all at once every year. Yes, there are some free certificate services out there, but for some sites it just doesn't seem worth it.

        Finally, with the many, many certificate exploits that have occurred, adding HTTPS doesn't really mean you're secure....it just means that the browser thinks everything is secure.

        • by markus ( 2264 )

          If you have hundred domains, you should look at using either a hosting service or a content delivery network. Thanks to Let's Encrypt, almost all of the big players allow you to turn on HTTPS support with a single check box. You do that once and you're all set.

          As a nice she effect, your site will get much faster, as it can now use HTTP/2, which has huge performance improvements.

          And Google's index will rank you higher.

          Also, future browser versions won't show warning messages when they access your site (that

          • by tepples ( 727027 )

            Finally, you get to use new HTML5 features. A lot of the newer features are only available to encrypted sites

            Say I want to run a web server on a private network, such as a home NAS, and allow HTML5 playback of videos stored on this NAS. But there has been talk of restricting the Fullscreen API to secure contexts because of the potential for phishing [feross.org]. So how would I go about encrypting a server that doesn't have its own domain name, especially if I want visitors to my home to be able to see the videos in the full screen but not a scary self-signed certificate warning?

            • by markus ( 2264 )

              You'll need to own at least one domain name (e.g. "example.com"). But it is OK if your internal service is hosted on a sub domain (e.g. "videos.example.com"). So you only need to pay for a single domain name.

              The internal host name does not need to be accessible from the internet, just from your LAN. But you need to be able to control DNS for your entire domain. You can then use DNS validation to prove to Let's Encrypt that you control all of "example.com", and they'll issue you a certificate for "videos.exa

        • There's also the expense and upkeep of maintaining current certificates. I have 100+ sites

          Then set up Certbot or another ACME client to renew certificates for 100+ of these sites, and put it on a cron job.

    • Re:Needless bullshit (Score:4, Informative)

      by vadim_t ( 324782 ) on Friday November 04, 2016 @03:50PM (#53214713) Homepage

      Some ISPs and access points have been doing realtime traffic modification and inserting ads into websites. Since it's well known that some ads are malicious, then yes, it's very much beneficial for a recipe site run on SSL, because it makes it impossible to hijack the trusted and harmless site for nefarious purposes, such as serving you some kind of trojan via an ad.

      • Some ISPs and access points have been doing realtime traffic modification and inserting ads into websites. Since it's well known that some ads are malicious, then yes, it's very much beneficial for a recipe site run on SSL, because it makes it impossible to hijack the trusted and harmless site for nefarious purposes, such as serving you some kind of trojan via an ad.

        I'll agree that this is one scenario where SSL would help.

    • by Anonymous Coward

      Yes, HTTPS is fine for anything sensitive, but does my recipe site really need to provide HTTPS pages?

      Seriously, there is no need for every site to output HTTPS pages. If you're really afraid that someone might eavesdrop and see you looking at Banana Bread recipes, you have bigger problems than an HTTPS connection can fix.

      No, I'm afraid about visiting a site and having code injected into the bit stream:

      * http://www.pcworld.com/article/2062400/british-spies-reportedly-spoofed-linkedin-slashdot-to-target-network-engineers.html

      Or your ISP as well:

      * https://www.reddit.com/r/canada/comments/2nv1un/rogers_still_using_content_injection_after_7/
      * http://www.infoworld.com/article/2925839/net-neutrality/code-injection-new-low-isps.html

      HTTPS Everywhere prevents "tapping glass" and forces the intel folks to hopefully actually focus on i

      • by Anonymous Coward

        My small (but still monopoly) ISP loves to inject content in.

        Constant bandwidth warnings? Check
        Terms of Service changes? Check
        (My favorite) Upgrade to a new modem now with this offer! Check

        I cringe every time I see one of their banners, because I know how dangerous of an avenue this is, and the potential for how bad it can get.

        But like most other people in America, I don't have a choice to use another provider if I want equivalent service. And the service isn't even good.

    • by rtb61 ( 674572 )

      From Google's economic point of view, yes it should all be encrypted. Why, you are wandering, why is it so important from Google's economic point of view, because they want to sell you privacy, they do not want Government's and ISPs to access that data for free, not when Google wants to sell it. Whilst definately a good idea in principle make no mistake there is greed and evil behind it. No free targeted marketing data for you, unless you pay, everything encrypted all of the time except for Google skulking

  • Thanks to these guys encryption like it should be - quick, easy and no exorbitant fees imposed by the old school certification mob. Got everything running over TLS now - in production, staging and private... Cheers
    • by dargaud ( 518470 )
      I just decided to convert my ancient and minor (used to be big in '96 [like yahoo!!!]...) website to https with let's encrypt, but CentOS 5 is not supported and I have no plan to reinstall the entire server. I spent 2 hours looking at various pages giving complex and non-working workarounds without success before giving up. A decade ago I went through the entire 'normal' https process, spent a morning to get it all working with success and then 6 months later when I had to renew I had no clue what I had to
      • Just use the Let's Encrypt client in manual mode (letsencrypt-auto certonly --manual) then install the generated certificates the "old" way.
        • Just use the Let's Encrypt client in manual mode (letsencrypt-auto certonly --manual) then install the generated certificates the "old" way.

          While my OS has the lets encrypt client available, I've got one service I run on it that doesn't have any predefined rules for generation and auto-renewal. Manual mode works great for this, its just a little annoying to use.

          • by markus ( 2264 )

            There are several other clients apart from CertBot. Take a look. They are all linked from the letsencrypt.org website. You might find something that is a better fit for you.

            I think, there are a couple of ACME clients that also act as HTTPS reverse proxies. That could be a really easy option to solve your problem

      • by markus ( 2264 )

        The easiest way to switch a legacy service to HTTPS is to install an NGINX reverse proxy in front of it.

        As for the certificate, get a free certificate from Let's Encrypt. There are are plenty of options to automate and integrate Let's Encrypt with existing services (e.g. the aforementioned NGINX).

        And yes, Let's Encrypt has probably done more for the universal adoption of HTTPS than any other effort -- including everything that Google has done.

        If you like Let's Encrypt, please consider donating. They are cur

        • The easiest way to switch a legacy service to HTTPS is to install an NGINX reverse proxy in front of it.

          Provided it has its own fully-qualified domain name.

          If a service accessible over a LAN is normally accessed with a private IP address (such as one in 192.168/16), or with a hostname under a phony TLD (such as .local), the CAs won't issue a certificate. This is true, for example, of the HTTP server for administering a router, printer, or NAS. Mozilla's FAQ about deprecation of cleartext HTTP [mozilla.org] acknowledges this problem but offers no fix yet:

          Q. What about my home router? Or my printer?

          The challenge here is no

          • by markus ( 2264 )

            You don't need a separate domain for internal services. Use your external domain and create sub domains. All your internal machines could be on dhcp.public.com and all your containers on vm.public.com. Neither one needs to use publicly routable IP addresses, and in fact you can continue using dnsmasq (or an exquisitely DHCP server) to manage this part of your internal network.

            You then operate the Let's Encrypt ACME client in DNS mode to get globally trusted SSL certificates. But nobody other than your inter

            • by tepples ( 727027 )

              Use your external domain and create sub domains.

              Home users who bought a printer or NAS appliance tend not to already own a domain. Should buying a domain be considered part of the total cost of ownership of home networking?

      • but CentOS 5 is not supported and I have no plan to reinstall the entire server

        Sorry but you'll need to do that very soon as CentOS 5 is supported only until March 2017, and in releases that ancient they didn't provide a reasonable way of upgrades. And if you accrued that much technical debt, it might be faster to just nuke and reinstall anyway.

    • by Cramer ( 69040 )

      Right. Because a FREE, NON-VALIDATED certificate is 100% trustworthy. They are on par with a self-signed certificate. Only worse, because they won't trigger a warning from your browser. People who actually care about security do not trust their certificates.

      In fact, any "domain validated" certificate should, as Clarkson would say, make some poo come out. If I have control of your DNS, then I can easily man-in-the-middle your site; SSL doesn't prevent anything here. Thanks to Let's Encrypt, I can now get a c

      • Right. Because a FREE, NON-VALIDATED certificate is 100% trustworthy. They are on par with a self-signed certificate.

        The validation is essentially the same as budget CAs. The difference is LetsEncrypt convinced the major browsers to trust them even though they're a non-profit, automated service.

        • by Cramer ( 69040 )

          Actually, they're WORSE. One script and you're set; run it from cron and your cert is always up-to-date.

          And no, they didn't get any browser to accept them. They got some other idiot CA to sign their intermedia CA, and *poof* browsers accept them now.

          • Easier does not mean worse. It is the same low level of verification as a $10 domain validated cert, but now there's less chance Joe Blogger's readers will be FireSheeped at Starbucks because it costs him nothing and auto renews itself. It is a GOOD thing that it is easy and automatic. Lowering the barrier of entry to apply a basic level of encryption raises the barrier of entry to intercept and modify traffic.

            If your primary challenge is to train users to differentiate between Extended Validation and Doma
  • by Anonymous Coward

    How do they know what websites I visit and what percentage of them are using HTTPS?

    Sounds like I don't have the privacy they are trying to protect

    • by Alumoi ( 1321661 )

      Google? Privacy for the product(s)? You must be joking.

    • How do they know what websites I visit and what percentage of them are using HTTPS?

      Unless you opted in to allowing Chrome to send usage statistics, they don't.

    • by markus ( 2264 )

      The hostname isn't encrypted, when issuing HTTP over SSL. So any network between you and the internet (I.e. your ISP) has this information.

      I think HTTP/2 is a little better in this regard, but it is not yet very widely deployed.

  • I run Apache and I even compiled in HTTPS support, but here's the thing; I need a valid certificate which costs real money.

    Is there an anonymous way to run an HTTPS server?
    Something that doesn't guarantee the identity of the website, but still allows the traffic to be encrypted?

    • by fph il quozientatore ( 971015 ) on Friday November 04, 2016 @03:08PM (#53214459) Homepage
      Ever heard of https://letsencrypt.org/ [letsencrypt.org] ?
    • by Junta ( 36770 )

      lets encrypt will issue certificates, without even so much as a registered account.

    • You can create a self-signed certificate. The user's browser will warn the hell out of them, but it will be encrypted.

      • ... The user's browser will warn the hell out of them ...

        Exactly. Which is why I find that unacceptable.

        The problem lies not with the ability to turn on encryption - that's relatively easy.
        It's the browser acting as if a self signed certificate is less secure than no certificate.

        Let's encrypt may be better, but it depends on how browsers decide to treat domain-validated certificates.

        • It's the browser acting as if a self signed certificate is less secure than no certificate.

          Browser makers find it important to accurately report the truth of the sense of security. A self-signed certificate used with the https: scheme gives a false sense of security, whereas the http: scheme gives a true sense of insecurity.

          Let's encrypt may be better, but it depends on how browsers decide to treat domain-validated certificates.

          The only browser I've ever seen that warns for valid domain-validated certificates is Comodo Dragon. Any certificate that isn't at least organization-validated causes Dragon to show the "mixed passive content" icon in the location bar and an amber interstitial [netcraft.com], which resembles

    • by Cramer ( 69040 )

      Create your own self-signed certificate. If your users want SSL, they can accept that certificate. Most browsers make it fairly easy to install an otherwise unknown/untrusted certificate.

  • And the fact that them being able to get this information doesn't scare and infuriate people? Even if the metric is anonymized, why the fuck do people accept software that spies on you? Yes I'm aware that majority of software does.. but why the hell do we accept it?

  • spyware (Score:2, Informative)

    by markdavis ( 642305 )

    Not only does most stuff not need to be HTTPS, it often destroys caching, lowers battery life, and hurts performance.... but also.... how does Google know these statistics unless they are freely admitting that they have major spyware in their non-open, binary-only Chrome browser? So this whole https on non-important pages is theoretically so much better for privacy and security, except that Google gets to know everywhere you go?

    There are many reasons I don't use Chrome....

    • by tepples ( 727027 )

      Not only does most stuff not need to be HTTPS, it often destroys caching

      Your browser can cache resources delivered through HTTPS as easily as through cleartext HTTP.

      lowers battery life, and hurts performance

      This was true until most battery-powered laptops, tablets, and smartphones started shipping with support inside the CPU for commonly used ciphers.

      but also.... how does Google know these statistics unless they are freely admitting that they have major spyware in their non-open, binary-only Chrome browser?

      In both Google Chrome and its free subset Chromium, users can opt in or out of synchronizing bookmarks and history across all devices on the same Google account.

      • >"Your browser can cache resources delivered through HTTPS as easily as through cleartext HTTP."

        Which does absolutely nothing for centralized caching like Squid.

        • by tepples ( 727027 )

          Then have your office's Squid proxy act as a man in the middle for HTTPS, and install its root certificate on all devices authorized to connect to the network.

          • While that is an option, as you probably know, it has disadvantages:

            1) Can be difficult
            2) Time consuming
            3) Erodes all security
            4) Introduces more things to break & support
            5) Puts a lot more load on the server (which in same cases is old and can't handle it well)
            6) Won't work for clients you don't control (think public and guest access)

            I still don't believe it makes sense to force the majority of web browsing to be https.

            • by tepples ( 727027 )

              In the cleartext HTTP case, there was no security to erode anyway. And clients you don't control would connect to a separate subnet not behind the caching proxy.

              1, 2, 4, and 5 will probably end up solved by some information security appliance manufacturer.

    • by markus ( 2264 )

      HTTP/2 requires encryption and gives much better performance than plain old HTTP.

      If you want a fast and efficient site, there is no way around getting a valid certificate.

      The same is true if you want to use any of the more modern HTML5 features. They're disabled for legacy sites

    • how does Google know these statistics

      Part of it is that by default Chrome will report your browsing habits, partly because Google's OS might (just guessing on this), and partly because Google search returns links to Google which then redirect to the target website.

I just asked myself... what would John DeLorean do? -- Raoul Duke

Working...