Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×
Security Chrome The Internet IT Technology

HTTPS Adoption Has Reached the Tipping Point (troyhunt.com) 85

Security expert Troy Hunt, who is perhaps best known for creating Have I Been Pwned data breach service, argues that adoption of HTTPS has reached the tipping point, citing "some really significant things" that have happened in the past few months. From a blog post: We've already passed the halfway mark for requests served over HTTPS -- This was one of the first signs that we'd finally hit that tipping point and it came a few months ago. This is really significant -- Mozilla is now seeing more secure traffic than it is non-secure traffic. Now that doesn't mean that most sites are now HTTPS because that figure above has a huge portion of traffic served from a small number of big sites. Twitter, Facebook, Gmail etc. all do all their things over HTTPS and that keeps that number quite high. Hunt also cited security aficionado Scott Helme's recent analysis which found that the number of websites listed in Alexa's top one million websites that have adopted to HTTPS has more than doubled year from August 2015 to August 2016. Troy adds: Browsers are holding non-secure sites more accountable. Chrome 56 is now holding sites using bad security practices to account (by flagging a "not secure" label in the address bar when you visit such websites). Many sites you wouldn't expect are now going HTTPS by default. (He cites websites such as ArsTechnica, NYTimes as examples). Making more cases for his argument, Hunt adds that HTTPS sites are not slow as they used to be, and that services such as Let's Encrypt and Cloudflare have made it free and east to bring this security feature.
This discussion has been archived. No new comments can be posted.

HTTPS Adoption Has Reached the Tipping Point

Comments Filter:
  • by Anonymous Coward

    I'll encrypt when they make it west. Making it east is just racist.

  • Now take the strategies you've learned and do the same for flash vs html5.

    • by tepples ( 727027 )

      It depends on what you mean by "Flash". I thought the rise of Safari for iOS adequately encouraged use of HTML5 instead of Flash Player to play H.264 video on the web.

      That leaves vector animations, which are traditionally made in Flash and displayed in Flash Player. If they're displayed in HTML5, they still have to be made somehow. Last time I asked about tools to create HTML5 vector animation [slashdot.org], someone recommended Hippani [hippani.com]. How easily can an animator make the transition from Flash to Hippani?

      • How easily can an animator make the transition from Flash to Hippani?

        I'm not an animator myself, nor do I know any animators so I can't help. But it seems you still can reply to "trash eighty" on that discussion thread, so maybe ask them.

        I would start looking into replacements for flash as browser vendors are actually wanting to get rid of it.

    • You have to hang around the lowest neighborhoods in the net to find Flash stuff. PHBs got it when they could not experience those marvelous animations in their iPhones. Nothing but interactive video needs flash nowadays, and that moves truckloads of money so, no, Flash might be dead but not buried because now is used for what it was meant to be used.

      Perhaps you think that anything animated on a website is "Flash" it is a possibility, but according to your UID you're not an old fart but more likely a mill
      • Most of the animations today are done precisely within HTML5 with the help of JS libraries

        Flash is still installed on a large part of the desktop population and even if the animators have moved on to creating new things with HTML5, websites are still around requiring Flash.

        I don't know how you can compare HTTPS adoption (an standard) to the freewill or professionalism of the creator of the content in picking the wrong tool

        HTML5 is a standard as well. Flash is a proprietary technology with most parts like ActionScript being NIH of web technologies like JS, and where the only widely used and usually the only supported version is proprietary and full with security bugs.

        And flash is not just about animations. Github required Flash for a long time b

        • Yeah I know all the places where you can find sprinkles of flash here and there, I was focusing in the uses of Flash that always seem to piss people off or actual vectors of attack. You're right that Flash will keep being installed by default for a long time, I think Chrome approach is the best, to bundle flash in a sandbox and have it set off by default or only when really needed, sadly I need Flash to work on Firefox too so I have it installed updated and by default fiewalled (plugin-container.exe) anytim
  • Tipping Point (Score:2, Insightful)

    by Camel Pilot ( 78781 )

    The tipping point towards what? Isn't SSL great for things that need to be secure... ie shopping, banking, etc but pretty much excessive for mundane stuff - like this article and this post for example. I am sure glad by slashdot.org data is transported via SSL connection because you never know....

    • Re:Tipping Point (Score:4, Interesting)

      by Anonymous Coward on Wednesday February 01, 2017 @12:20PM (#53781185)

      I see it as more of a needle in a haystack...
      When only a small amount of traffic is encrypted that traffic screams to be targeted for an attack.
      When all traffic is encrypted it's harder to determine what traffic should be targeted for an attack.

    • It's "evil" to be able to have your traffic sniffed. Leave that data for all the ad networks that serve ads over HTTPS.

    • I pretty much agree with you.

      I create/run a fair number of web applications. Anything with a password associated with it runs https- if there is no password, then it runs insecure.

      You want a picture of a peach? I'll serve up thousands- and let every man-in-the-middle know that you're looking at peaches.

      You want to send me your email and password (that is probably the same you use on 10 other sites)? Now it is secure.

      Asking a real question- why should we encrypt non-sensitive data?

      • by fisted ( 2295862 )

        Asking a real question- why should we encrypt non-sensitive data?

        Because even though the data is non-sensitive, people might still prefer a little privacy. You'll understand when you're behind a proxy that has multiple people constantly tail -F'ing the access log.

        Some stuff is totally mundane and I wouldn't want people to know I'm accessing it regardless even though they would not care about it.

        Then there's the problem of, say, clicking on a google search result that was obtained via https, when the actual result isn't. Congratulation, your google search just leaked as

        • by tepples ( 727027 )

          even though the data is non-sensitive, people might still prefer a little privacy.

          In some cases, even the hostname is sensitive, such as "transgender.example" or "womenshealth.example". HTTPS won't save you there because the browser sends the hostname in cleartext in the Server Name Indication field of the ClientHello packet.

          You'll understand when you're behind a proxy that has multiple people constantly tail -F'ing the access log.

          Watch ISPs offer subscribers a discount on their monthly data plans for configuring their devices to run HTTPS traffic through the ISP's MITM proxy.

          I'd take a 'CONNECT slashdot.org:443' in the access log over GET and especially POST showing up there, telling the reading vs posting rate.

          Until you start getting billed for each CONNECT that shows up in the access log because the requested resource can't be

          • by fisted ( 2295862 )

            HTTPS won't save you there because the browser sends the hostname in cleartext in the Server Name Indication field of the ClientHello packet.

            It already sends the hostname in cleartext in the CONNECT request which comes before ClientHello. I'm not sure why you're pointing this out, you quoted me saying that... Hostname is strictly better than full URL, since the latter contains the former.

            Watch ISPs offer subscribers a discount on their monthly data plans for configuring their devices to run HTTPS traffic through the ISP's MITM proxy.

            Yes, I'll watch. As opposed to participate.

            Until you start getting billed for each CONNECT that shows up in the access log because the requested resource can't be served from a Squid or Polipo cache upstream of you.

            Ok. That is unrelated to the privacy issue, though.

            • Hostname is strictly better than full URL

              Agreed. But there are purists who think "strictly better" is still not good enough.

              Watch ISPs offer subscribers a discount on their monthly data plans for configuring their devices to run HTTPS traffic through the ISP's MITM proxy.

              Yes, I'll watch. As opposed to participate.

              Once your ISP starts doing this, you can either participate, pay overages, move to an area served by a different ISP (and make plans to move again once the ISP serving that area changes its policy as well), or disconnect from the Internet. You have already ruled out participating; which of the remaining three is most attractive to you?

              [Billing for uncacheable use of a connection] is unrelated to the privacy issue, though.

              It's related if the majority of home Internet subscribers prove themselves willing to give u

              • by fisted ( 2295862 )

                Once your ISP starts doing this, you can either participate, pay overages, move to an area served by a different ISP (and make plans to move again once the ISP serving that area changes its policy as well), or disconnect from the Internet. You have already ruled out participating; which of the remaining three is most attractive to you?

                None of the above. I couldn't tell you exactly which, but there's got to be at least half a dozen laws and regulations that would prohibit ISPs from doing that, if not German then at least EU-wide, or so I'd hope. That said, I don't like the web to begin with, so as far as I'm concerned it can DIAF. (No, the irony of me saying that here is not lost on me. I'm not on /. because I like the web, I'm on the web because I like^Whave some weird nostalgia for /. and come to think of it, it would work much bett

                • by tepples ( 727027 )

                  there's got to be at least half a dozen laws and regulations that would prohibit ISPs from [charging extra not to run all HTTPS connections through a proxy], if not German then at least EU-wide

                  But definitely not worldwide. Where does that leave those residing in Slashdot's home country, the United States of America? Here the cable company serving a given city tends to have a monopoly on broadband in that city, except for subscribers who can settle for 1.5 Mbps (DSL) or 10 GB/mo (satellite or fixed cellular).

          • What's sensitive about "womenshealth.example" ? Am I missing something?
            • by tepples ( 727027 )

              "Women's health" is often a euphemism for "reproductive health", which in turn offends those who want to restrict sex education, abortion access, and the like. "You don't need to learn about contraceptives because you can't get pregnant if you abstain from sexual contact, and you don't need to learn about sexually transmitted infections because you can't catch one if you abstain from sexual contact. Only a whore would visit those sites without a valid marriage license."

    • but pretty much excessive for mundane stuff

      The mundaneness of your stuff is entirely at the liberty of the person spying on you, and if one thing has proven true, it's that EVERYTHING you do seems to be of interest to someone now.

    • but pretty much excessive for mundane stuff

      It's also trivial and free to implement with Certbot [eff.org]. If everything were encrypted, then encrypted stuff wouldn't stand out in traffic analysis as "potentially interesting; worth investigating". Given the price, ease, and value in protecting absolutely everything, my policy is that everything that can be encrypted is unless there's a specific reason why it shouldn't be.

    • The full value of HTTPS is only realized with a third-party certificate that authenticates the server's identity. Without the third-party cert, sure, you have encryption, and you can be confident that when submitting info like your credentials or a credit card it can't be sniffed. However, you cannot be confident - without the cert - that you know to whom you are submitting that data. Instead of a thief robbing you on the way to the bank; they just convince you their hideout is the bank. As to why put your
    • How many passwords do you figure I could grab from a web forum that's over HTTP that are common to the same user's banking or utility accounts?

      How do you know that the JavaScript being sent from /. is what the site intended? Over HTTP are you sure it's not something injected with extra code targeted at a security vulnerability in your specific browser (which the attack would know from your headers unless you're masking them)?

      How about people knowing exactly which articles you read from which sites? With HTT

    • The main reason websites had a split between Secure and Unsecure before was due to processing overhead and, depending on how far you go back, actual regulation of encryption by Congress.

      Encryption is now a very small time cost on servers and an accepted cost anyway due to the even greater eventual cost of MITM attacks.

      It's also a benefit as it makes it harder for someone to passively know exactly what you're reading. Nobody can follow you around and see which specific articles you are reading on Wikipedia,

  • by xxxJonBoyxxx ( 565205 ) on Wednesday February 01, 2017 @12:15PM (#53781133)
    HTTPS negotiation was never the "slow" part - it's always been the Javascript, single-pixel images and other crap imported from dozens of other sites. Developers have been driving me nuts with "we can't use HTTPS for our snowflake app - it'll slow the user experience" BS for years.
    • Re: (Score:1, Troll)

      by KingMotley ( 944240 )

      Then you've never tried to have a server actually scale in the past. The HTTPS negotiation was slower than HTTP, but the actual encryption took valuable server compute resources, and would cause many servers to belly up long before they should. Servers have gotten faster, and the the methods used to do the encryption have gotten a lot better, but if you think it doesn't affect how much a server can scale then you'd be mistaken.

      There are solutions today, but none are free, and most aren't "simple".

      • by tepples ( 727027 ) <tepples AT gmail DOT com> on Wednesday February 01, 2017 @01:12PM (#53781851) Homepage Journal

        The HTTPS negotiation was slower than HTTP, but the actual encryption took valuable server compute resources

        True, TLS increases CPU overhead for a site that just serves static documents. But web applications have also become more dynamic since the late 1990s when SSL (now called TLS) was invented. With more server-side processing for each page view, the fraction of server CPU time devoted to actually sending the resource to the PC has diminished. I grant that the cost is greater than zero, but the benefit is also greater than zero.

        There are solutions today, but none are free

        I thought NGINX as the frontend reverse proxy in front of your application server was free software under the 2-clause BSD license [nginx.org].

        • by doom ( 14564 )

          Okay, I must confess that this is the first I've heard about SSL not being SSL any more, but I have a humble suggestion: let's drop this horseshit, no matter how Logical the rationale is, and continue to call SSL SSL.

          You'd think we'd learn something from stuff like the URL/URI "switch" that never happened.

          For that matter you'd think we'd learn something period, from something, anything, but perhaps I'm showing my age.

          • by guruevi ( 827432 )

            No, SSL is SSL, TLS is TLS, they're somewhat different, most notably that SSL runs encrypted sockets, TLS can negotiate encryption while simultaneously allowing unencrypted traffic over the same sockets. Although in web-servers (at this point) there is no true difference between the streams of SSL or TLS, it should be technically possible to TLS over port 80 (as described in RFC2817) and the recommendation is to turn off SSL completely as all incarnations of it are insecure.

        • With more server-side processing for each page view, the fraction of server CPU time devoted to actually sending the resource to the PC has diminished.

          Perhaps it's the sites that you've worked on, but there a vast number that does very little actual per-request dynamic server-side processing. That's pretty much the very first thing you do in creating a scalable website is isolate that from all the other content. Just as an example, the last major site I worked on, all content was cached, and the cache was only invalidated on actual changes, so it was fairly common for only 1 request out of ~1 million to really ever do any server side processing. It was

          • Sorry, I should have just said this at the start, but HTTPS encryption, not including the set-up handshake (which isn't insignificant), and using a modern cypher, like AES will eat up around 2.5 cores by itself if your data rate is ~1gb/s (and we would exceed that at peak hours). Considering the webserver we had was only a quad-core, that would have been 62.5% of the available CPU time just for HTTPS encryption, or tripling our server costs (and/or the added complexity of requiring converting to a web farm

            • using a modern cypher, like AES will eat up around 2.5 cores by itself if your data rate is ~1gb/s

              Newer server CPUs have hardware acceleration for AES [wikipedia.org], or you can put crypto in a shader [anchor.com.au] and run it on a GPU.

              Considering the webserver we had was only a quad-core, that would have been 62.5% of the available CPU time just for HTTPS encryption

              But you also said there's "very little actual per-request dynamic server-side processing", which would presumably easily fit in the remaining 37.5 percent.

      • by guruevi ( 827432 ) <evi@@@evcircuits...com> on Wednesday February 01, 2017 @03:06PM (#53783037) Homepage

        You need to update your knowledge base, the overhead of SSL vs. non-SSL is on the order of 2-5% with modern CPU. A decent set of Intel Xeons can push upwards of 3GBps (that's 24Gbit/s) in encrypted traffic per CPU. Even before HTTP2 there were various methods of speeding up SSL but the whole thing adds less than 2-3ms even on old hardware with relatively up-to-date web servers.

      • Then you've never tried to have a server actually scale in the past.

        "In the past" being the key part. SSL overhead is trivial [maxcdn.com] now and has been for some time.

    • Developers have been driving me nuts with "we can't use HTTPS for our snowflake app - it'll slow the user experience" BS for years.

      Translation: We are too lazy to learn the small adaptations to make sure our app works with SSL properly. What do you mean anything we embed has to have HTTPS vs HTTP references! That is soooooo hard! Although a special annoyance goes out to any web app that can't deal with being put behind an SSL appliance. Or poor documentation for how to do it (Wordpress used to be a major offender here).

      • by tepples ( 727027 )

        Although a special annoyance goes out to any web app that can't deal with being put behind an SSL appliance.

        The web app software can deal with it just fine. But as I understand KingMotley's complaint [slashdot.org], the organization operating it can't necessarily afford to purchase said SSL appliance and lease additional units of rack space in the colo facility.

    • HTTPS negotiation was never the "slow" part

      I see your first computer was Core i5 with multiple gigs of RAM and the wonders to go with it.
      HTTPS negotiation most definitely *was* at one point the "slow" part, especially if you were unfortunate enough to be on the host side of the equation handling multiple requests at a time.

      Ironically enough your UID is low enough to remember a time where simply a story on Slashdot could bring down websites. So you should know quite well that things didn't always scale so beautifully in the past as they do now.

    • by zifn4b ( 1040588 )

      HTTPS negotiation was never the "slow" part - it's always been the Javascript, single-pixel images and other crap imported from dozens of other sites. Developers have been driving me nuts with "we can't use HTTPS for our snowflake app - it'll slow the user experience" BS for years.

      First I agree SSL, TLS, etc. have never been the slow part. There are several culprits for the slowness over the years.

      Javascript - You pointed this out. That only really happened when XMLHttpRequest (or oh my MS specific ActiveX instantiation of the XMLHttpRequest COM object *shudder*) arrived on the scene or whoever figured out how to hack AJAX using an iframe. Javascript in the application it was originally designed for (not ad hoc HTTP posts) was perfectly fine. There was very limited DOM manipulati

      • by zifn4b ( 1040588 )
        Slashdot ought to just include a moderation option for "-1 because I reject reality and insert my own". That's about the quality of the moderation on this forum.
  • by nmb3000 ( 741169 ) <nmb3000@that-google-mail-site.com> on Wednesday February 01, 2017 @12:19PM (#53781175) Journal

    found that the number of websites listed in Alexa's top one million websites that have adopted to HTTPS has more than doubled

    Why do people still use Alexa? There can't be more than a tiny handful of people who still use their crappy browser toolbar and that measuring metric has always had significant selection bias. Do they have a newer, better data source, or is there just nothing better so people fall back to a name that's familiar?

    It would be nice if the major ISPs would aggregate and share all that data they save for the NSA anyway with some nonprofit org for this kind of thing.

  • If I'm accessing a site that simply serves up information and doesn't ask for any details from me, then there's no need for HTTPS. It simply sucks up CPU cycles and ultimately uses up more electricity. And no , I don't care about the 0.001 extra on my bill, but if you add it up over the entire planet its probably a couple of coal fired power plants extra required.

    • by chispito ( 1870390 ) on Wednesday February 01, 2017 @12:38PM (#53781381)

      If I'm accessing a site that simply serves up information and doesn't ask for any details from me, then there's no need for HTTPS.

      Your connection can be man-in-the-middled and malicious content served to you, or the middleman could help himself to your cookies. Maybe you have all cookies and javascript disabled, but most of us don't. I mean, there are other ways to mitigate this kind of attack, but it's easiest just to prefer TLS whenever possible.

      • by Viol8 ( 599362 )

        "Your connection can be man-in-the-middled and malicious content served to you"

        You can spoof an HTTPS site if you know what you're doing.

        "or the middleman could help himself to your cookies"

        If its just a one way information site the cookies will be of little use to him.

    • If I'm accessing a site that simply serves up information and doesn't ask for any details from me, then there's no need for HTTPS.

      That entirely depends on if you knowing that information is of special interest to a third party.
      Did you Google a picture of a kitty? Or are you reading in plain text the Anarchists Cookbook? Doing that latter would be of interest to a lot of three letter agencies and you don't even need to share any personal information to get their attention.

    • by guruevi ( 827432 )

      I think a lot less CPU would be consumed if more people were using HTTPS without allowing the side-loading of third party content. Imagine all 30 ads and 300-something trackers here on /. were never loaded because your browser was set not to trust content that laid outside the HTTPS domain you are requesting.

  • by tepples ( 727027 ) <tepples AT gmail DOT com> on Wednesday February 01, 2017 @12:38PM (#53781379) Homepage Journal

    So I guess the next thing to do is find a way to make HTTPS practical for a web server on a home LAN, particularly with DNS Service Discovery instead of a purchased domain. A lot of routers, NAS boxes, etc. still use cleartext HTTP because the browser publishers' Baseline Requirements forbid certificate authorities trusted by the web browser from issuing certificates for hostnames in the .local TLD. And with browser publishers threatening to make the Fullscreen API HTTPS-only, this would impair video streaming from a NAS.

    Sources for threat to drop Fullscreen API: Secure Contexts: Risks associated with non-secure contexts [github.io]; Secure Contexts: Restricting Legacy Features [github.io]; Deprecating Non-Secure HTTP [mozilla.org]; Deprecating Powerful Features on Insecure Origins [chromium.org]
    Source for impracticality of HTTPS on home LAN: Question to Let's Encrypt rep in /r/IAmA [reddit.com]

  • There are different versions of SSL and TLS that have already been broken. How useful is "https only" is?

  • "have made it free and east"

    Given the actual majority of such traffic is coming from China (thank you, Norse!) this is not a surprise. Also, China is the most populous country, so again, it stands.

  • Worst Offenders (Score:4, Interesting)

    by crow ( 16139 ) on Wednesday February 01, 2017 @02:23PM (#53782621) Homepage Journal

    What sites are still the worst offenders?

    I'll start by nominating amazon.com. Sure, they use https for the actual transaction portion, but every product page you look at is unencrypted. I'm sure every ISP out there is tracking their user's Amazon browsing to create advertising profiles. Verizon certainly is. Why should Amazon give them this information for free?

    What will it take for Amazon to fix their site? What if an ISP started injecting ads into Amazon? It would be just a small step from the tracking they already do. I would love to see Verizon or Comcast do that. (Mainly because it would push more sites to use encryption.)

    • by Anonymous Coward

      Type in amazon.com and any browser later than mosaic 0.5 will redirect you to the https site.

      • by crow ( 16139 )

        Yes, it seems I posted without verifying that my memory was correct. I could swear that at least until recently my assertion was true, but I now I don't know. Too bad I can't delete my post.

    • by lgw ( 121541 )

      How are you seeing an unencrypted page on Amazon? Everything I see is encrypted. Is this something that happens when you're not logged in?

Genetics explains why you look like your father, and if you don't, why you should.

Working...