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

← Back to Stories (view on slashdot.org)

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

Posted by msmash on Wednesday February 1, 2017 @04:00AM from the tipping-point dept.

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.

85 comments

Min score:

Reason:

Sort:

security compass by Anonymous Coward · 2017-02-01 04:02 · Score: 1

I'll encrypt when they make it west. Making it east is just racist.
Great by NotInHere · 2017-02-01 04:03 · Score: 0

Now take the strategies you've learned and do the same for flash vs html5.
1. Re:Great by tepples · 2017-02-01 05:04 · Score: 1
  
  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, someone recommended Hippani. How easily can an animator make the transition from Flash to Hippani?
2. Re:Great by indi0144 · 2017-02-01 07:58 · Score: 1
  
  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 millennial trying to add into the circle jerk, so, if thats the case, yeah! we should execute Flash designers and bill Adobe for the bullets./s
  
  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. Most of the animations today are done precisely within HTML5 with the help of JS libraries. Google effectively invented those strategies when they started releasing their design guidelines and simple ignoring content in Flash for SEO.
  
  All I see is that designers and animators moved on, web devs know better (because you don't want to piss on daddy Google), but the bitching about the non-existent issue that is Flash kept lingering around like any other old and stale nerd meme.
3. Re:Great by NotInHere · 2017-02-01 08:17 · Score: 1
  
  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.
4. Re:Great by NotInHere · 2017-02-01 08:55 · Score: 1
  
  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 because of some dumb "put url into clipboard" feature, as do various video sites still today because either they don't care (if you set your user agent to iphone they will show an HTML5 fallback!) or because they believe Flash gives them better DRM than EME does.
  Have you ever actually browsed the web without flash? I've uninstalled it in 2011. Was a tough ride back then, you had to add ?html5=1 urls to youtube, and they at least offered a fallback. But I've seen how more and more content supported HTML5. Its still far from perfect, and I won't shut up until it is perfect.
  I was an early adopter of HTTPS too. It might seem unimaginable, but in the old days google was not encrypted by default. They launched an extra subdomain "encrypted.google.com" that was encrypted with HTTPS, which I then used.
  Yes, I'm calling 2010 "the old days": You are correct with your assessment of me being a millenial.
5. Re:Great by indi0144 · 2017-02-06 15:58 · Score: 1
  
  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) anytime flash wants to connect to the net, I have to manually approve.
  
  I'm ok with websites that uses Flash for what it was really designed, even for some content that might be better approached with interactivity or a graphic layout. It's a tool that was absurdly overused where it wasn't needed in its time. Jobs slapped Flash in the face with the iPhone and when watery-eyed-flash turned to daddy Google, daddy looked in disappointment and you knew Flash was done.
  
  I think the only thing that was preventing mass adoption of HTTPS as default was the associated costs/return: Cert and IP. Mom-and-pop shops that probably make the most of the .com really didn't see the advantage of it until you need it for setting up payment processing. Now certificates are free or mostly free and SNI takes care of the IP side, setting up HTTPS with cloudflare is trivial for example, all this greatly motivates the adoption. But still, FLASH vs HTTPS adoption history is apples and oranges.
  
  Oh and as for millennial, by some definitions I might be one, 34, but I've been labeled generation X, Y not-remember-what-wankery-in-2000's and now millennial, those tags are created by Marketing so you can rehash the same books and conference tours with the same babble but with new keywords. While demographic studies are certainly of serious interest by marketers the reduction of those concepts until the creation of tags like "millennial" is where you can spot the hack from the real marketer. They are meaningless, and in that regard, I use the word for whats it is: a meme.
Yes, I'm familiar with Hot Tips by Anonymous Coward · 2017-02-01 04:08 · Score: 0

- things not to say on a job interview
Tipping Point by Camel+Pilot · 2017-02-01 04:10 · Score: 1, Insightful

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....
1. Re:Tipping Point by Anonymous Coward · 2017-02-01 04:20 · Score: 4, Interesting
  
  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.
2. Re:Tipping Point by omnichad · 2017-02-01 04:21 · Score: 1
  
  It's "evil" to be able to have your traffic sniffed. Leave that data for all the ad networks that serve ads over HTTPS.
3. Re:Tipping Point by bigman2003 · 2017-02-01 04:22 · Score: 1
  
  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?
  
  --
  No reason to lie.
4. Re:Tipping Point by Anonymous Coward · 2017-02-01 04:27 · Score: 0
  
  Because it's not just about encryption but also about authentication. You may not care that middle-men can read your data, but you certainly don't want them to mess with it.
5. Re:Tipping Point by Anonymous Coward · 2017-02-01 04:29 · Score: 0
  
  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....
  TLS secures several things at once: the secrecy of what is transmitted (the content of the site), the identity of the source (you can be sure you actually are receiving content from slashdot.org) and the integrity of the content (no-one between slashdot.org and you can tamper with the content). All three are important in themselves, even for non-controversial sites like slashdot. The injection of malicious content is routine in certain parts of the internet (e.g. http://www.theregister.co.uk/2014/10/27/tor_exit_node_mashes_malware_into_downloads/ and many of the free VPNs out there). Certain ISPs inject their own content into sites (mostly advertising).
6. Re:Tipping Point by Anonymous Coward · 2017-02-01 04:38 · Score: 0
  
  Be careful with the cookies. Some sites run the login over HTTPS but the rest of the site as HTTP. This is better than nothing, but not by a lot. A MITM operator may also change the contents of the site. The peach pictures could be replaced by a malicious image, or the HTTPS based login form replaced by one that works over HTTP.
7. Re:Tipping Point by tepples · 2017-02-01 04:50 · Score: 0
  
  In a discussion on Coding Horror Discourse, bigjosh brought up the example of a whole school in sub-Saharan Africa sharing a slow, capped connection to the Internet. If everybody in the class reads the same article, and this article is served over cleartext HTTP, the proxy could download the article once and serve it to all students. With HTTPS, the proxy would instead have to create a separate tunnel for each user through which to send a separately encrypted copy of the article, causing views of the same document after the first to be far slower and causing the school to hit its daily or monthly data transfer quota sooner.
  For publicly cacheable documents, why isn't there a middle ground between cleartext HTTP and HTTPS that uses a signing-only cipher suite? Then at least an intermediate caching proxy near the client could still work.
8. Re:Tipping Point by Anonymous Coward · 2017-02-01 04:54 · Score: 0
  
  but pretty much excessive for mundane stuff - like this article and this post for example.
  
  until someone steals your slashdot ID and makes a remark on slashdot that either gets you fired or destroys your reputation
9. Re:Tipping Point by Killall+-9+Bash · 2017-02-01 04:55 · Score: 2
  
  Ouch! My heart is bleeding! How did that happen...?
  
  --
  "Prediction: within 10 years, Windows will be a Linux distribution." Me, 7-6-2016
10. Re:Tipping Point by Anonymous Coward · 2017-02-01 04:59 · Score: 0
  
  If you want authentication, then HTTPS isn't the answer. HTTPS in only encryption. Not authentication. Not authorization.
  A MITM can still serve with HTTPS just fine.
11. Re:Tipping Point by tepples · 2017-02-01 05:05 · Score: 1
  
  A MITM can still serve with HTTPS just fine.
  Only if the browser is configured to trust the MITM's certificate.
12. Re:Tipping Point by Anonymous Coward · 2017-02-01 05:19 · Score: 0
  
  So because some areas in the US are limited to dialup, or broadband at ISDN speeds (looking at you Seattle), everyone should be limited to these speeds? Some users only have capped options available for cell phone use, does that mean all cell phones should be limited to the same caps?
13. Re: Tipping Point by Anonymous Coward · 2017-02-01 05:28 · Score: 0
  
  There are a fair number of proxies which MitM co tent and modify it.
  This has made it difficult/impossible to turn on things which should have been OK to turn on, like compression of content, pipelining, etc.
  Https disallows such proxies from screwing with the client-server dynamic, and as such safely allows optimizing features.
14. Re:Tipping Point by fisted · 2017-02-01 05:36 · Score: 2
  
  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 part of the Referrer.
  Then there's the issue of WHAT exactly is going on on a particular site. 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. Not that I'd post must on /. at work, but as a matter of principle.
  tl;dr: If your site doesn't speak https, I'll probably stay away from it. Yes, you might not care, but you asked for reasons and here are a few.
  
  --
  CLI paste? paste.pr0.tips!
15. Re:Tipping Point by Anonymous Coward · 2017-02-01 05:40 · Score: 0
  
  Http and other unencrypted protocols enabled massive invisible bulk data collection. Even unauthenticated encryption would have prevented that since MITM stops being transparent the moment someone manages to set up another channel which is not MITM'ed and uses it to compare keys.
16. Re:Tipping Point by thegarbz · 2017-02-01 05:46 · Score: 1
  
  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.
17. Re:Tipping Point by tepples · 2017-02-01 05:56 · Score: 1
  
  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 served from a Squid or Polipo cache upstream of you.
18. Re:Tipping Point by Anonymous Coward · 2017-02-01 06:01 · Score: 0
  
  Maybe you like your ISP injecting data into your traffic.
19. Re:Tipping Point by Anonymous Coward · 2017-02-01 06:07 · Score: 0
  
  I hear Africa only has access to Lead pipes, so we should limit ourselves to the same. They can use an HTTPS proxy and enjoy all of the problems that come with it. In an enterprise network forum, someone asked why they gave proxy configs such a cold shoulder. The response was in a normal large network with people using the big Web 2.0 sites, the cache hit rate was so low it only gave a bandwidth savings in the 5%-10% range. The only useful local cache was for patches like WSUS for Windows.
20. Re:Tipping Point by fisted · 2017-02-01 07:01 · Score: 1
  
  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.
  
  --
  CLI paste? paste.pr0.tips!
21. Re:Tipping Point by Just+Some+Guy · 2017-02-01 07:22 · Score: 1
  
  but pretty much excessive for mundane stuff
  It's also trivial and free to implement with Certbot. 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.
  
  --
  Dewey, what part of this looks like authorities should be involved?
22. Re:Tipping Point by JoePete · 2017-02-01 09:04 · Score: 1
  
  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 entire site under HTTPS and a cert, an attacker can intercept an HTTP request and send back their own forged content. Whether this is a script, image, text, hyperlink etc. It's analogous to locking your door but leaving a window open somewhere.
23. Re:Tipping Point by mr_mischief · 2017-02-01 09:27 · Score: 1
  
  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 HTTPS and SNI they know what server you used. If you're using insecure DNS then they might already know which hostname you looked up, but that's another data source.
  Do you disable cross-site cookies? Did you think about the fact that any third-party observer who can see your traffic can read first-party cookies anyway if you're on HTTP?
24. Re:Tipping Point by Brukenet · 2017-02-01 09:46 · Score: 1
  
  What's sensitive about "womenshealth.example" ? Am I missing something?
25. Re:Tipping Point by Anonymous Coward · 2017-02-01 10:46 · Score: 0
  
  Authentication, i.e. making sure that the data has not been tampered with. Not authorization, which is a matter of permission.
26. Re:Tipping Point by tepples · 2017-02-01 11:02 · Score: 1
  
  "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."
27. Re:Tipping Point by fyrewulff · 2017-02-01 19:55 · Score: 1
  
  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, for example, they can only tell that you're going to Wikipedia.
  
  --
  "We need to get over this notion, that, for Apple to win... Microsoft must lose." - Steve Jobs, 1997
HTTPS negotiation was never the "slow" part by xxxJonBoyxxx · 2017-02-01 04:15 · Score: 4, Insightful

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.
1. Re:HTTPS negotiation was never the "slow" part by KingMotley · 2017-02-01 05:03 · Score: 0, Troll
  
  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".
2. Re:HTTPS negotiation was never the "slow" part by Shawn+Parr · 2017-02-01 05:05 · Score: 2
  
  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).
  
  --
  Shawn's Tech Articles
3. Re:HTTPS negotiation was never the "slow" part by tepples · 2017-02-01 05:17 · Score: 1
  
  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, the organization operating it can't necessarily afford to purchase said SSL appliance and lease additional units of rack space in the colo facility.
4. Re:HTTPS negotiation was never the "slow" part by thegarbz · 2017-02-01 05:48 · Score: 1
  
  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.
5. Re:HTTPS negotiation was never the "slow" part by zifn4b · 2017-02-01 06:53 · Score: 1
  
  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 manipulation in that case. It's when we got AJAX happy because no one liked the stateless HTTP model because during post backs browsers displayed a polar bear in a snow storm and that was deemed an unacceptable user experience. Never mind the fact that by exclusively using HTTP the way it was intended for web applications enabled the creation of platforms like ASP.NET that could support any browser without the developer having to specifically code to some other browser's quirks mode. Nope, that postback was annoying to the point that certain people bitched and moaned very loudly until we hacked AJAX together and got all the additional challenges associated with it including DOM manipulation performance. NOTE: I think where we ultimately ended up is better than the pure stateless HTTP model.
  Web Server platforms like Apache and IIS were not originally built to scale. They couldn't utilize parallel processing effectively to serve up multiple requests. I believe both of them for a while were handling all requests one at a time in synchronous/serial fashion.
  As far as your developers providing the excuse of HTTPS being slow that is and always was a BS excuse but you know why your developers told you that right? It's something you most likely don't understand. Hosting and configuring a website is completely outside of the realm of software development. Software developers write the application. DEVOPS deploys the application. IT provides the infrastructure. You probably work somewhere where there is a game of "hot potato" of where the line is between division of responsibilities. Do you really want your developers establishing relationships with certificate authorities to get properly signed certificates or just creating their own bogus ones that can't be verified? Furthermore, you want the developers to have access to your produce environment violating the criteria of many types of audits like PCI, not a good idea. I bet you've never had to deal with the auditors. :)
  It sounds like you still have a lot to learn about the Software Engineering field. It also sounds like you're a manager and that is a scary proposition.
  
  --
  We'll make great pets
6. Re:HTTPS negotiation was never the "slow" part by guruevi · 2017-02-01 07:06 · Score: 3, Informative
  
  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.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
7. Re:HTTPS negotiation was never the "slow" part by Just+Some+Guy · 2017-02-01 07:25 · Score: 2
  
  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 now and has been for some time.
  
  --
  Dewey, what part of this looks like authorities should be involved?
8. Re:HTTPS negotiation was never the "slow" part by zifn4b · 2017-02-01 09:32 · Score: 1
  
  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.
  
  --
  We'll make great pets
9. Re:HTTPS negotiation was never the "slow" part by Anonymous Coward · 2017-02-01 10:31 · Score: 0
  
  OK, right then, noted. KingMotley thinks that fundamental security technologies that have been around for, oh, a couple of decades, are "too hard", "too expensive", and that "scaling is a problem not adequately solved".
  Right, HR, make a note of this. Any applicant with a persona named KingMotley is not actually qualified to be a web or server administrator. We do not hire candidates to make excuses, stall important organizational initiatives, or trot out technical issues from the 1990's.
  Next!
Alexa Rankings by nmb3000 · 2017-02-01 04:19 · Score: 2

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.

--
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
1. Re:Alexa Rankings by Anonymous Coward · 2017-02-01 07:25 · Score: 0
  
  There's pretty much no alternative source for data like this. Sometimes big websites share stats, but they obviously cannot give us insight into stats about sites as such, and sometimes search giants share stats, but so far they pretty much confirm what Alexa says, at least qualitatively.
Not everything needs HTTPS by Viol8 · 2017-02-01 04:27 · Score: 1

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.
1. Re:Not everything needs HTTPS by chispito · 2017-02-01 04:38 · Score: 4, Insightful
  
  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.
  
  --
  The Daddy casts sleep on the Baby. The Baby resists!
2. Re:Not everything needs HTTPS by Viol8 · 2017-02-01 04:58 · Score: 1
  
  "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.
3. Re: Not everything needs HTTPS by Anonymous Coward · 2017-02-01 05:31 · Score: 0
  
  Wrong.
  Accessing content you don't want to can enable a malicious attacker to probe a othwrwise secure site unrelated to the one the attacker modified. ... Allowing for DOS attacks, discovery of passwords, etc.
4. Re:Not everything needs HTTPS by thegarbz · 2017-02-01 05:50 · Score: 1
  
  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.
5. Re:Not everything needs HTTPS by guruevi · 2017-02-01 07:10 · Score: 1
  
  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.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
6. Re:Not everything needs HTTPS by Anonymous Coward · 2017-02-01 07:38 · Score: 0
  
  "You can spoof an HTTPS site if you know what you're doing."
  Not without installing a malicious cert on the client, which you cannot do without tricking the user into installing malware or physical access to the machine.
  "If its just a one way information site"
  They can still see what information you are looking at and (subtly) alter it. Even if you can find that one special snowflake site for which HTTPS really doesn't do anything, the fact of the matter is that in most cases HTTPS is an objectively better choice than plain HTTP.
  You might think that the info you're looking up is plain and mundane, but governments, society and companies are more judgemental in various ways than you think and you might end up paying in some way for the fact that you've been looking at information about, say, constructed languages, without you ever knowing what you did wrong.
  And (subtle) alterations to information might coax you into making wrong decisions, like buying an unnecessarily expensive product or voting for the wrong candidate or taking the wrong pill.
  Sure, your site might not fall into any of those categories. But exceptions themselves have a price. The browsers need to maintain extra code paths and the very existence of plain HTTP is a risk in that it makes the whole security situation unnecessarily complicated for the average user. With only HTTPS, the browser can simply display a site or not. With the additional existence of HTTP, the browser must communicate that the displayed content is not secure, and lay people have to make correct judgements about what that means with near infallibility. I think the major browsers (Chrome, IE, Firefox, Safari, Opera) should just convene on an ultimatum after with support for HTTP will be dropped.
Any hope for practical HTTPS on home LAN? by tepples · 2017-02-01 04:38 · Score: 4, Interesting

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; Secure Contexts: Restricting Legacy Features; Deprecating Non-Secure HTTP; Deprecating Powerful Features on Insecure Origins
Source for impracticality of HTTPS on home LAN: Question to Let's Encrypt rep in /r/IAmA
1. Re:Any hope for practical HTTPS on home LAN? by Anonymous Coward · 2017-02-02 00:05 · Score: 0
  
  It's local. Create a self-signed certificate and add it to your client's certificate store.
  Certificate authorities with their root certificates are a weak solution to distributed trust, and should only be used for that.
2. Re:Any hope for practical HTTPS on home LAN? by tepples · 2017-02-02 04:04 · Score: 1
  
  It's local. Create a self-signed certificate and add it to your client's certificate store.
  This doesn't help in two cases:
  1. Devices whose certificate store is managed by the manufacturer, not the device's owner, such as game consoles and other set-top streaming devices
  2. BYOD, such as the phone, tablet, or laptop of a friend or relative visiting your house
Is https enough? by lucasnate1 · 2017-02-01 04:55 · Score: 1

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

--
Avantgarde Hebrew science fiction
1. Re:Is https enough? by Anonymous Coward · 2017-02-01 06:27 · Score: 0
  
  Browsers do when visiting an HTTPS URL than simply using SSL or TLS and calling it a day. They treat that scheme as an indication that the connection is intended to be secure, and guard against connections that are insecure even over SSL or TLS. They warn you if the site uses an unsafe cipher, if the certificate has expired, if the site or CA certificate has been revoked, etc.
Perfect slip-up by Khyber · 2017-02-01 05:02 · Score: 1

"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.

--
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
free and east? by Anonymous Coward · 2017-02-01 05:02 · Score: 0

Surely the east is not free :P Im sure that was supposed to read free and easy.
Web apps have become more dynamic by tepples · 2017-02-01 05:12 · Score: 3, Informative

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.
1. Re:Web apps have become more dynamic by doom · 2017-02-01 06:12 · Score: 1
  
  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.
2. Re:Web apps have become more dynamic by guruevi · 2017-02-01 06:48 · Score: 1
  
  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.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
3. Re:Web apps have become more dynamic by Anonymous Coward · 2017-02-01 07:02 · Score: 0
  
  Netflix is serving out HTTPS data over 100Gb ports and is IO limited, not CPU. HTTPS is getting pretty cheap except for number of round-trips to hand-shake. That sucks over a high latency connection. Not to say HTTP2 is great, but HTTP2 will help alleviate this issue.
4. Re:Web apps have become more dynamic by Anonymous Coward · 2017-02-01 15:57 · Score: 0
  
  We didn't rename anything, you are just uninformed about the difference between protocols. Most webservers under my control are TLS-only, meaning browsers that only support SSL are shit out of luck.
5. Re:Web apps have become more dynamic by KingMotley · 2017-02-02 18:07 · Score: 1
  
  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 wasn't a small site either, at it's peak, it would have 10k concurrent users with pretty rich media assets, so tacking on https encryption overhead to that would have killed the server.
  And yes, the site had javascript, and "single pixel" images as well. And it all ran off a single server (well, 1 web server), and it ran well that way.
6. Re:Web apps have become more dynamic by KingMotley · 2017-02-02 18:21 · Score: 1
  
  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).
Comment removed by account_deleted · 2017-02-01 05:25 · Score: 1

Comment removed based on user account deletion
Worst Offenders by crow · 2017-02-01 06:23 · Score: 3, Interesting

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.)
1. Re:Worst Offenders by Anonymous Coward · 2017-02-01 07:39 · Score: 0
  
  Ebay also does not use https site-wide, last time I was there.
2. Re:Worst Offenders by lgw · 2017-02-01 08:09 · Score: 2
  
  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?
  
  --
  Socialism: a lie told by totalitarians and believed by fools.
3. Re:Worst Offenders by crow · 2017-02-01 11:36 · Score: 3, Informative
  
  It must be a recent change, but you're right. I remember it being http except when dealing with transactions. I'm glad I'm wrong. Now I wish I could delete my original post.
HTTPS works so well... by Anonymous Coward · 2017-02-01 06:25 · Score: 0

HTTPS works so well that it's generally not attacked, right? All the bad actors, including government actors, are attacking the machines, going right around HTTPS. It means squat if your box has monitoring software installed and you don't even know it.
Call me when there's a simple protocol of some kind that can guarantee this machine isn't logging all my keystrokes and sending them someplace.
HTTPS forces you to ID yourself by Anonymous Coward · 2017-02-01 06:28 · Score: 0

Unless one generates a new key for every session it would seem to me that by using HTTPS everywhere we are being compelled to identify ourselves in every transaction.
They may not know WHO we are, or WHERE we are, but 'they' may know that we are the same browser instance that connected to those other sites.
There are many sites that offer useful information that does not need encryption. It doesn't need to be everywhere. Maps. Bus schedules. Board minutes. No secrets there.
Excessive use becomes interference (having trouble connecting to that site because your browser needs to be upgraded?) and then oppression (if you can't afford a new computer or a new operating system, you cannot connect to the latest websites and slowly fall into obsolescence - not what the Internet or the World Wide Web was intended to be).
Food for thought.
~childo
Another company affecting this by Anonymous Coward · 2017-02-01 06:55 · Score: 0

services such as Let's Encrypt and Cloudflare have made it free and east to bring this security feature.
cPanel servers seem to be giving them out too now:
https://blog.cpanel.com/securi...
compared to Let's Encrypt:
https://letsencrypt.org/stats/
cP is probably even eastier.
Privacy? That'll be $$ per month extra. by tepples · 2017-02-01 07:21 · Score: 1

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 up their privacy for a discount on Internet access. It's like ISPs that zero-rate Facebook under the "Free Basics" program: users expose everything to Facebook because their ISP has made it cheaper than using other sites that respect the user's privacy.
1. Re:Privacy? That'll be $$ per month extra. by fisted · 2017-02-01 07:44 · Score: 1
  
  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 better over (correctly chained) email.)
  [Puts writing a /. <-> email gateway on his todo list]
  
  [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 up their privacy for a discount on Internet access. It's like ISPs that zero-rate Facebook under the "Free Basics" program: users expose everything to Facebook because their ISP has made it cheaper than using other sites that respect the user's privacy.
  Fair point.
  
  --
  CLI paste? paste.pr0.tips!
2. Re:Privacy? That'll be $$ per month extra. by tepples · 2017-02-01 10:58 · Score: 1
  
  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).
Amazon does it right. by Anonymous Coward · 2017-02-01 07:51 · Score: 1

Type in amazon.com and any browser later than mosaic 0.5 will redirect you to the https site.
1. Re:Amazon does it right. by crow · 2017-02-01 11:38 · Score: 1
  
  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.
That's MY "bitch" too along w/... apk by Anonymous Coward · 2017-02-02 05:08 · Score: 0

See my subject: Not ONLY on sites slowed but in programs I've written using TLS/SSL - why? No backward compatibility & when the people making these libs do NEW ones??
* It BREAKS THE PROGRAMS, forcing a rebuild (this is not bullshit, & it's a F'ing PAIN in the ass!) - yes, even w/ Try-Catch errtrapping + overriding std. err handers in programs (doesn't 'crash', & you record the err in a log instead to diagnose it) but it doesn't WORK then either!
(Until the "powers that be" get their shit together & do a layer for secure sockets that is FAST + doesn't bust up what uses it? I don't have a lot of FAITH in either its efficacy NOR its maintainability!)
APK
P.S.=> Sorry for the rant but it's one that's PISSED ME OFF big while I was coding for years professionally (& even in freewares I do now for fun), caused issues galore (mainly in not having backward compat, & even though toolkits attempt to 'fall back' on older methods? The changes made in the libs for SSL/TLS are so 'radical' the programs using it bust up forcing patches a LOT)... apk
AES-NI exists now by tepples · 2017-02-03 03:53 · Score: 1

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, or you can put crypto in a shader 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.