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.
security compass (Score:1)
I'll encrypt when they make it west. Making it east is just racist.
Great (Score:1)
Now take the strategies you've learned and do the same for flash vs html5.
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
Tipping Point (Score:2, 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....
Re:Tipping Point (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.
Re: (Score:3)
Re: (Score:2)
It's "evil" to be able to have your traffic sniffed. Leave that data for all the ad networks that serve ads over HTTPS.
Re: (Score:2)
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?
Re: (Score:1)
In a discussion on Coding Horror Discourse [codinghorror.com], 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 d
Re: (Score:2)
A MITM can still serve with HTTPS just fine.
Only if the browser is configured to trust the MITM's certificate.
Re: (Score:3)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Privacy? That'll be $$ per month extra. (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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).
Re: (Score:1)
Re: (Score:2)
"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."
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:1)
Re: (Score:2)
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
Re: (Score:2)
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,
HTTPS negotiation was never the "slow" part (Score:5, Insightful)
Re: (Score:1, 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".
Web apps have become more dynamic (Score:4, 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 [nginx.org].
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
AES-NI exists now (Score:2)
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.
Re:HTTPS negotiation was never the "slow" part (Score:4, 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.
Re: (Score:3)
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.
Re: (Score:3)
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).
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Alexa Rankings (Score:3)
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.
Not everything needs HTTPS (Score:2)
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.
Re:Not everything needs HTTPS (Score:5, 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.
Re: (Score:2)
"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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Any hope for practical HTTPS on home LAN? (Score:5, 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 [github.io]; Secure Contexts: Restricting Legacy Features [github.io]; Deprecating Non-Secure HTTP [mozilla.org]; Deprecating Powerful Features on Insecure Origins [chromium.org] /r/IAmA [reddit.com]
Source for impracticality of HTTPS on home LAN: Question to Let's Encrypt rep in
Re: (Score:2)
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? (Score:1)
There are different versions of SSL and TLS that have already been broken. How useful is "https only" is?
Perfect slip-up (Score:2)
"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)
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.)
Amazon does it right. (Score:1)
Type in amazon.com and any browser later than mosaic 0.5 will redirect you to the https site.
Re: (Score:2)
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.
Re: (Score:3)
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?
Re:Worst Offenders (Score:4, 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.