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

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

Comments

Vonage® Business VoIP Phone Systems

[Anonymous Coward]

Over 9,000 Business users have switched to the Vonage Business Hosted VoIP service. Join the revolution & save up to 36.4% on your lol landlines are for oldies, Bill.
Upgrade your business phone system and save or don't. Our Hosted VoIP service empowers businesses like yours with over 40 built-in features, like ringing and answering. Enhance your productivity by talking more on a phone. Activation and on boarding is simple but our tools 24/7. Ready to move to the reliable Vonage Cloud? Speak to a VoIP specialist today and put your phone in the cloud. like what, I don't even. How did Vonage do it? They put the phone in the cloud! With my phone in the cloud I can use it anywhere, but I can't because it's a landline and the cord isn't very long.

Re: Vonage® Business VoIP Phone Systems

[Anonymous Coward]

That made my fucking day

...and then blanked out by JavaScript

[Anonymous Coward]

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

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

Re:...and then blanked out by JavaScript

[Anonymous Coward]

I think the Mirai botnet would be put to good use DDoSing sites that lock out users who have ads blocked.

Forever.

Re:...and then blanked out by JavaScript

[houstonbofh]

Then skip the puff piece and hit the source. Google raw data... https://www.google.com/transpa... Google blog about the data... https://security.googleblog.co...

Note that adblock did not blank the content for me. Perhaps because I lock down java?

Re:...and then blanked out by JavaScript

[Anonymous Coward]

my ISP from time to time inserts an ad page on http webs, never seen it on https sites

Re:...and then blanked out by JavaScript

[Anonymous Coward]

What's Java*?

(*) Browser context only, not including enterprise stuff and other non-browser usage.

AWESOME!

[Anonymous Coward]

Great push for HTTPS, guys.

Good to know that when state actors or, heck, our own government, want to flood out DNS again, we'll be stuck resolving certificates and failing to consume services because we got so giddy with SSL everywhere.

Keep writing downgrade proxies and alternate routes. We're reaching a point where the US is self-sabotaging DNS.

Needless bullshit

[JustAnotherOldGuy]

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

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

Re:Needless bullshit

[kangsterizer]

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

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

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

Re:Needless bullshit

[tnok85]

Hmmm, this Banana Bread recipe calls for dinitrotoluene... not sure what that is, but it sounds delicious!

Re:Needless bullshit

[Anonymous Coward]

does my recipe site really need to provide HTTPS pages?

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

you have bigger problems than an HTTPS connection can fix.

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

Re:Needless bullshit

[swillden]

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

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

HTTPS provides three guarantees that HTTP does not.

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

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

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

Re:Needless bullshit

[Second_Derivative]

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

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

Re:Needless bullshit

[rubycodez]

Sad news for you, if an attacker can penetrate and change my banana bread website, it doesn't matter whether it what running https or http. you'll get their donation request and links via https with my trusty certificate.

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

Re:Needless bullshit

[houstonbofh]

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

Re:Needless bullshit

[vadim_t]

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

Re:Needless bullshit

[Cramer]

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

Re:Needless bullshit

[known_coward_69]

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

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

Re:Needless bullshit

[Cramer]

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

The simple truth is very little of the internet actually needs to be "protected" by SSL. Very few web sites are interesting ("valuable") enough to be worth the effort to divert or otherwise intercept their traffic. All SSL does is [i]substantially[/i] increase the processing overhead for a site. (key generation is exceptionally expensive -- simple would be trivial to break.) And then there's the money expensive of buying a trusted certificate. (which only perpetuates the lie inherent with #2 -- very little, if any, validation is done)

Re:Needless bullshit

[Anonymous Coward]

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

Especially no for Chrome itself, which is fundamentally insecure by design because of all the data Google sucks out of it, regardless of their bullshit about opting in to usage statistics.

Re:Needless bullshit

[Anonymous Coward]

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

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

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

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

Or your ISP as well:

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

HTTPS Everywhere prevents "tapping glass" and forces the intel folks to hopefully actually focus on individuals instead of sucking everything up (possible storing it for years).

Re:Needless bullshit

[Anonymous Coward]

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

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

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

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

Re:Needless bullshit

[Anonymous Coward]

Encryption also adds technical debt, which will inevitably be a drag on its proper use.

It also creates a false sense of security. This, IMO, is Google's aim:

1. People feel secure. Page-views go up. Ad impressions increase. Google cashes more checks.
2. People feel secure. eCommerce increases. Competition for customers increases. Ad-buys go up. Google cashes more checks.

Unfortunately, HTTPS does little to add genuine security for the average person, since most compromises are performed before or after data is encrypted for transport.

Re:Needless bullshit

[Anonymous Coward]

Of course the telemetry data collected by Google needs to be transferred via HTTPS or people would complain. Just shut up and bend over to your corporate overlord, who does no evil.

Re:Needless bullshit

[JustAnotherOldGuy]

All of the responses to the OP miss his point. Not every website needs to pay the cost of encryption for no real reason. Yes it is a trivial cost on your recipe site, but not so much when you have a thousand hits a minute.

That's a good point.

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

Finally, with the many, many certificate exploits that have occurred, adding HTTPS doesn't really mean you're secure....it just means that the browser thinks everything is secure. But if you compromise the site to serve up malware, an HTTPS connection does nothing to hamper that. It just means you'll get your malware over a secure connection.

Re:Needless bullshit

[JustAnotherOldGuy]

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

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

Re:Needless bullshit

[tepples]

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

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

Re:Needless bullshit

[Anonymous Coward]

I'm amazed at how selective people's paranoia is sometimes.

Facebook recording the url of every site anyone ever visits, including non-facebook users? What's the big deal? No one's forcing you to use the internet.

Google using phones to track people literally everywhere they go? No problem, they can disable it - sort of - if someone with more tech knowledge than them happens to tell them it's happening and show them how to turn it off

Hackers theoretically being able to obtain information about your food allergies? ENCRYPT. EVERYTHING.

Re:Needless bullshit

[tepples]

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

Re:Needless bullshit

[Anonymous Coward]

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

Now sure, every so often some of those injected flash ads have malware in them, but that's the ad it's not my fault. I mean it's not like I can use quality ad delivery networks here, they actively stop this kind of thing, so I have to take what I can get. Besides, the fuck do I care, they aren't my computers.

I'm just glad there's so many people still fighting ssl with me. Keep fighting the good fight man!

Re:Needless bullshit

[Anonymous Coward]

Sad news for you, if an attacker can penetrate and change my banana bread website, it doesn't matter whether it what running https or http. you'll get their donation request and links via https with my trusty certificate.

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

Yah, uh, I'll remove that header when I'm reverse proxying you, and block port 443. Nothing you do will prevent the user from accessing the non-secure site first, and they will not care or think twice about the SSL lock icon unless they are typing in payment info - if that.

Browsers will have to drop support for plaintext HTTP eventually. Until then, you're boned.

Re:Needless bullshit

[Dagger2]

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

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

Bearing in mind that total global internet traffic is barely even one zettabyte per year, let alone over a million trillion yottabytes, I think it's reasonable to conclude that the percentage of attacks that occur on the webserver as opposed to somewhere in-flight is lower than 99.9999999999999999999999999999999999999999%. (Especially when you consider that the DDoS that Github was struggling with for 4 days most likely involved rewriting more than a single 50-byte packet.)

Re:Needless bullshit

[rtb61]

From Google's economic point of view, yes it should all be encrypted. Why, you are wandering, why is it so important from Google's economic point of view, because they want to sell you privacy, they do not want Government's and ISPs to access that data for free, not when Google wants to sell it. Whilst definately a good idea in principle make no mistake there is greed and evil behind it. No free targeted marketing data for you, unless you pay, everything encrypted all of the time except for Google skulking in the background behind 'Google Tagmanager', 'Google Tagservices', 'Google Analytics', 'Google adwords', 'Googleapis', and that crappy advertising company that Google bought, that I have blocked for so long I have forgotten the name of it, basically they have all the resources to access your privacy prior to your encrypting anything, no where near as mr Probe themselves M$ but pretty bad.

Re:Needless bullshit

[markus]

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

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

And Google's index will rank you higher.

Also, future browser versions won't show warning messages when they access your site (that hasn't rolled out yet, but all the major browser vendors are working on it).

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

Re:Needless bullshit

[tepples]

and block port 443

This will be noticed when the user tries to visit a couple sites that do use HSTS, such as Google, Facebook, Twitter, or anything else in the preload list.

Re:Needless bullshit

[tepples]

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

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

Re:Needless bullshit

[markus]

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

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

If you don't already have an"always-on" computer, this is well within reach of a cheap raspberry pi

Re:Needless bullshit

[Woldscum]

EFF HTTPS Everywhere

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

Re:Needless bullshit

[Cramer]

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

Re:Needless bullshit

[Cramer]

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

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

Someone rewriting traffic in transit is exceptionally rare. Because it's really hard to do.

Re:Needless bullshit

[Dagger2]

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

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

Re:Needless bullshit

[Anonymous Coward]

1. Secrecy. This is the one that you focused on; keeping the contents of the traffic between your recipe server and its clients secure against eavesdroppers. You're probably right that it doesn't matter.

3. Integrity. HTTPS that the contents of the traffic between your reciper server and its clients is secure against modification.

I have a use case where I want to override this. Specifically, I was writing a proxy server that intercepts and records data between the webserver and browser so that it can be browsed later when offline, without having to worry about subtle modifications that other mirroring utilities do.

While HTTPS is certainly a good defense against third-party stuff, this use case has made it harder for me to do what I intend, especially when combined with HSTS and related.

Re:Needless bullshit

[Anonymous Coward]

my ISP from time to time inserts an ad page on http webs, never seen it on https sites. so I might not see your recipes just my ISP ad

Re:Needless bullshit

[Anonymous Coward]

soo google knows whats inside my desk drawer? and will sell that info?

Let's Encrypt definitely helped...

[dimethylxanthine]

Thanks to these guys encryption like it should be - quick, easy and no exorbitant fees imposed by the old school certification mob. Got everything running over TLS now - in production, staging and private... Cheers

Re:Let's Encrypt definitely helped...

[dargaud]

I just decided to convert my ancient and minor (used to be big in '96 [like yahoo!!!]...) website to https with let's encrypt, but CentOS 5 is not supported and I have no plan to reinstall the entire server. I spent 2 hours looking at various pages giving complex and non-working workarounds without success before giving up. A decade ago I went through the entire 'normal' https process, spent a morning to get it all working with success and then 6 months later when I had to renew I had no clue what I had to do again and said fuck it instead of wasting another morning.

Re:Let's Encrypt definitely helped...

[Mr.Radar]

Just use the Let's Encrypt client in manual mode (letsencrypt-auto certonly --manual) then install the generated certificates the "old" way.

Re:Let's Encrypt definitely helped...

[trogdor8667]

Just use the Let's Encrypt client in manual mode (letsencrypt-auto certonly --manual) then install the generated certificates the "old" way.

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

Re:Let's Encrypt definitely helped...

[Cramer]

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

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

(Yes. Slashdot is using their shit. And yes, my browser says "SITE NOT SECURE" Being slashdot, I don't care; in fact, a few days ago when they started using this crap, I had to add an exception. This site is the very definition of "does not merit encryption." How much money has Slashdot spent on crypto hardware or additional server capacity just to have a trendy "https" url?)

Re:Let's Encrypt definitely helped...

[markus]

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

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

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

If you like Let's Encrypt, please consider donating. They are currently running a fund raising effort: https://www.generosity.com/com...

Re:Let's Encrypt definitely helped...

[chispito]

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

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

Re:Let's Encrypt definitely helped...

[markus]

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

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

Re:Let's Encrypt definitely helped...

[Cramer]

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

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

Re:Let's Encrypt definitely helped...

[KiloByte]

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

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

Re:Let's Encrypt definitely helped...

[Anonymous Coward]

You still haven't actually explained why they're worse than self-signed certs, or why self-signed certs are better. Not to mention that if you had your way, every thing you do online would require accepting a new cert. Kind of defeats the point of using them in the first place when everyone just blindly has to accept them in order to even function online.

Basically, neither system is great, but browser vendors can't ship your certs with them, and they can't be easily managed or revoked if every joe makes their own. Self-signed certs are okay for PERSONAL use. CAs are okay for public use.

Re:Let's Encrypt definitely helped...

[Cramer]

With a self-signed certificate, the browser emits a warning alerting the user to question what they're doing. You will get that warning each time unless you install it in your personal certificate store. If the cert is later changed, it will differ from the one stored and you'll start getting warnings again. The certificate has no trust until you say so.

With LetsEncrypt, the certificates are just as untrustworthy. The problem is, you don't know they're the idiots behind that lock. They're handed out like pez to anyone who can set a DNS record. Granted, they aren't the only ones with near zero vetting. Yet people are perfectly OK with LetsEncrypt's shenanigans. Let's see how OK things are when their bot is tricked into signing a cert for paypal or gmail. "Oh, it's only valid for 3 months", and "but we revoked it as soon as we knew about it"... how many lesser sites will be noticed and revoked?

I'm not saying every site on the internet should be making their own certificates. However, given the the absolute zero trust we can place in the whole CA web-of-trust, and browsers blindly accepting CAs that do nothing meaningful to ensure a certificate request is valid, maybe we should. People are too dumb to understand the closed green lock doesn't necessarily mean anything.

Re:Let's Encrypt definitely helped...

[chispito]

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

If your primary challenge is to train users to differentiate between Extended Validation and Domain Validation, then they are already in a better place than if the challenge was to simply train them to look for the green symbol.

I'm not sure what it is you believe is happening or will happen that is worse than the alternative.

Nobody is allowed to spy on you but us

[Anonymous Coward]

Thanks Google. I feel so much safer now.

Protect users from eavesdropping?

[Anonymous Coward]

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

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

Re:Protect users from eavesdropping?

[Alumoi]

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

Re:Protect users from eavesdropping?

[swillden]

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

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

Re:Protect users from eavesdropping?

[Anonymous Coward]

Hah - I was wondering the same thing, so I took five seconds to look it up.

You'd think the tinfoil hatters would do the same, but ya know... sanity.

Re:Protect users from eavesdropping?

[Anonymous Coward]

Right, and a lot of people also used to believe that Google isn't evil....

Re:Protect users from eavesdropping?

[markus]

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

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

Lets Encrypt should help

[Anonymous Coward]

it's not a perfect solution, but it's far better than nothing

Another reason to wipe the Chromebook

[Anonymous Coward]

And install Linux. Telemetry on what you pages you load going back to Google? No thanks.

Re:Another reason to wipe the Chromebook

[Cramer]

If you run chrome from that fresh linux install, they'll get exactly the same stats from you.

Re:Another reason to wipe the Chromebook

[tepples]

And then the firmware will beg you to wipe the machine right back to "OS verification" (that is, the factory image) every single time you turn it on. If you've installed a "regular" GNU/Linux distro on your Chromebook, you have to make sure nobody else has physical access to it even for a moment, or they'll end up tempted to inadvertently wipe it.

And with StartCom dead...

[jez9999]

... it's a racket for SSL authorities who charge for their certs. Unless you want to install onerous ACME software on your server. Suckage.

Re:And with StartCom dead...

[Drizzt Do'Urden]

Why do you say StartCom is dead? My website is secured with a StartCom SSL certificate and it's still working. I can also buy a new one.

Re:And with StartCom dead...

[swillden]

... it's a racket for SSL authorities who charge for their certs. Unless you want to install onerous ACME software on your server. Suckage.

https://letsencrypt.org/

Re:And with StartCom dead...

[Zocalo]

Following numerous severe breaches of CA protocol by WoSign (StartCom's parent company) and by StartCom under their ownership, Mozilla, Google and Apple have all decided to revoke the trust in both the CAs - MS has yet to commit, but is very likely to follow suit. The only saving grace is that they are doing so in such a way as to not disrupt existing certificates, but if you get a new StartCom certificate now, it's not going to work in any of the major browsers in a few months time.

Re:And with StartCom dead...

[houstonbofh]

But your new one will not work in most popular browsers. https://blog.mozilla.org/secur... And Chrome joined them this week...

Re:And with StartCom dead...

[__aaclcg7560]

My webhost offers FREE SSL certificates through Let's Encrypt or you can roll your own. There's also a paid SSL certificate option.

https://letsencrypt.org/

Re:And with StartCom dead...

[Drizzt Do'Urden]

Thanks for the heads-up! I'll have to look for an other SSL provider...

Re:And with StartCom dead...

[fred6666]

so what's the alternative now to get a free SSL certificate valid in browsers?

Re:And with StartCom dead...

[Anonymous Coward]

"jez9999 ( 618189 )" says:

... it's a racket for SSL authorities who charge for their certs. Unless you want to install onerous ACME software on your server. Suckage.

"swillden ( 191260 )" says:

I know what will make me look smart, I'll provide an alternative to requiring ACME software running as root, by giving a link to a cert provider requiring ACME software running as root!

https://letsencrypt.org/

This is clearly the solution, the exact thing you are complaining about!

Re:And with StartCom dead...

[Zocalo]

LetEncrypt is still free, if their system will work for you, and Symantec is in the process of setting up something that seems similar over at FreeSSL. Otherwise, you can get cheap certs from Comodo and GoDaddy (yeah, their rep isn't great either, but it's just a binary file when you get right down to it) - ideally via one of their resellers who will offer lower prices, and the prices go up from there. Another approach is to shop around for a suitable VPS or other hosting bundle that includes a certificate in the price, which can often work out quite cost effective. Finally, if you fit the criteria, there are some commercial vendors that offer free certificates to non-profits - e.g. GlobalSign's offer of a free certificate for OSS projects.

Re:And with StartCom dead...

[Anonymous Coward]

You seriously haven't heard of letsencrypt.org?

Re:And with StartCom dead...

[Anonymous Coward]

I feel for you. StartCom was nice to use, but after a string of naughty behaviour most browsers are revoking trust in their certificates. I recommend finding a new CA.

Re:And with StartCom dead...

[markus]

If anything, ACME is a vast improvement over what we had before.

You might not mind 1) obtaining a new client certificate, 2) installing it in the browser, 3) generating and uploading a CSR, 4) proving that you have control over the domain, 5) downloading the new certificate, 6) installing it the server, 7) restarting the server with minimal downtime.

It used to take about 30min of work once a year for each of my domains. It also was a little tedious to schedule, as StartCom only gave a relatively small time window to do so. I think it was only about two weeks or so. But everything considered, for a private site with only one or two domains, it just about bearable.

With Let's Encrypt, things are a lot easier. You set things up once, and certificates will continue renewing automatically in perpetuity. Very little if any maintenance is required, and you can do it on your own schedule. Also, Let's Encrypt is much saner with regards to "subject alternate names". That solves a lot of problems that I used to have with StartCom.

Finally, there is a plethora of different ACME clients to chose from with lots of different feature sets and designs. I don't have first-hand experience with how things look on Mac or Windows, but on most traditional UNIX systems (including Linux), there really is no excuse for not setting up ACME. Also, most of the clients support both HTTP and DNS as way to verify control of the domain. That's huge! It solve a lot of the problems of dealing with complicated firewalls and legacy server software.

Re:And with StartCom dead...

[tepples]

Then use an ACME client that doesn't require administrator privilege, in particular one that uses the DNS challenge instead of the HTTP challenge.

Re:And with StartCom dead...

[Anonymous Coward]

so what's the alternative now to get a free SSL certificate valid in browsers?

Really, who do you expect to honestly verify that the person ordering the certificate actually owns the domain name being issued to for FREE?
For FREE you can't even match a credit card against DNS registration records. At a small loss, someone can auto-approve all requests. You're missing the point of SSL if you're using an encrypted channel to an anonymous server.

Re:And with StartCom dead...

[jez9999]

Isn't it a bit stupid to support HTTP for domain validation? The whole point of HTTPS is that you can't trust the identity of HTTP as it's vulnerable to a MITM attack yet it's just fine for getting an automated cert.

Re:And with StartCom dead...

[tepples]

You can trust HTTP as much as you can trust DNS. That's why automated CAs hit a site from several different paths through the Internet. The only practical way the MITM can compromise the validation is by being on the server's only uplink.

And don't bring up DNSSEC until the root is signed with a key longer than 1024 bits.

Re:And with StartCom dead...

[markus]

DNS validation is awesome. I have a couple of embedded devices (e.g. a remote KVM switch) that have minimal support for SSL certificates. I was never able to figure out how to use them with traditional CAs. But ACME over DNS was super easy to set up for these devices

Re:And with StartCom dead...

[markus]

That's what "certificate transparency" is for. And it's quickly becoming a mandatory feature.

Also, "certificate pinning" can help. But there are pros and cons to it. It's not appropriate for every site.

Re:And with StartCom dead...

[tepples]

Anyone else trying that will first need to buy a domain with which to do ACME over DNS, correct?

Re:And with StartCom dead...

[markus]

Yes, you need to own at least one domain. But you can then use sub domains for everything else. Any cheap domain will do. But yes, it'll cost you on the order of $10/year for all your computation needs

Re:And with StartCom dead...

[Dagger2]

Even most paid certs are only verified with a file on the webserver or an email sent to the domain.

EV certs are the exception (and in that case the CA does, or at least is supposed to, provide an actual useful identity verification service), but for normal certs you can easily automate the check in exactly the way LE does.

Re:And with StartCom dead...

[Anonymous Coward]

The "onerous ACME software" that the OP was complaining about is the Let's Encrypt application, FYI.

Re:And with StartCom dead...

[fred6666]

Thanks, went with Let's encrypt. Turns out it's even better as the certificate auto-renew. So even if the duration is only 90 days (1 year with Startcom) it doesn't matter.

Absolutely is a need

[bigbang137]

Without HTTPS, you can't trust the Chinese government to not MITM your recipe and add a superdose of red hot chilli pepper as an ingredient in your recipe. Once they do, expect to get sued for burning my tongue.

Re:Absolutely is a need

[rubycodez]

actually, 95% of https sites don't use HSTS with their HTTPS so they can still put chinese lead red paint in the recipe.

My personal web site does not support HTTPS

[AnotherBlackHat]

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

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

Re:My personal web site does not support HTTPS

[fph il quozientatore]

Ever heard of https://letsencrypt.org/ ?

Re:My personal web site does not support HTTPS

[Junta]

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

Re: My personal web site does not support HTTPS

[Anonymous Coward]

Yes, the little orphan Annie secret decoder ring

Re:My personal web site does not support HTTPS

[stinerman]

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

Re:My personal web site does not support HTTPS

[drago177]

Yup, and any host running cPanel will do it through Comodo (or letsencrypt with a plugin):
https://blog.cpanel.com/autoss...

Re:My personal web site does not support HTTPS

[drago177]

Ya, and any webhost running cPanel can do it through Comodo (or letsencrypt with a plugin):
https://blog.cpanel.com/autoss...

Re:My personal web site does not support HTTPS

[dargaud]

Unless your server is still on CentOS 5...

Re:My personal web site does not support HTTPS

[AnotherBlackHat]

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

Exactly. Which is why I find that unacceptable.

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

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

Re:My personal web site does not support HTTPS

[Cramer]

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

So why should Google know...

[Anonymous Coward]

...where anyone visits with a browser?? Let this be a reminder, all you Chrome consumer sheep, not to wander anywhere that you wouldn't want Google (and therefore, the cops and feds) to know about.

Re:So why should Google know...

[houstonbofh]

Firefox and IE know as well unless you turned it off. https://www.stopbadware.org/fi...

Not mine... Nope.

[Anonymous Coward]

My site is a podcast hosting where people connect to simply grab the latest episode, I am not going to pay for a fucking SSL cert for a read only site.
Sorry but there is no reason at all for SSL everywhere. read only sites dont need it and adding that heavy overhead to read only sites is a bunch of BS.

Re:Not mine... Nope.

[Anonymous Coward]

I'm sorry; are you from the past?

Re:Not mine... Nope.

[tepples]

I am not going to pay for a fucking SSL cert

Neither am I. If a site is public, you can obtain certificates without charge from Let's Encrypt.

adding that heavy overhead to read only sites

Most of the overhead in TLS is in the setup and teardown of connections. And even that is mostly mitigated by keep-alive, HTTP/2, or large files. Podcasts are large files.

Scared

[rtkluttz]

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

spyware

[markdavis]

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

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

Re:spyware

[tepples]

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

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

lowers battery life, and hurts performance

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

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

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

Re:spyware

[markus]

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

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

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

Re:spyware

[penguinoid]

how does Google know these statistics

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

Re:spyware

[markdavis]

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

Which does absolutely nothing for centralized caching like Squid.

Re:spyware

[tepples]

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

Re:spyware

[markdavis]

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

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

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

Re:spyware

[tepples]

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

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

Spyware? How do they know this?

[Anonymous Coward]

How does Google know this? I would assume they are keeping metrics of which sites people are viewing, in which case...

Whoa, Big Brother, much? I do not want my browser reporting back to the mothership of what sites I use or what passwords I use when I access whichever bank I use.

Google's competitors can't do https ads

[Anonymous Coward]

So https and "Let's Encrypt" is a massive money maker for Google.

Google makes their money off advertising. The more https, the more ad sales for them! And the less for their competitors.

It's a mega win for Google.

Re:Google's competitors can't do https ads

[Anonymous Coward]

So https and "Let's Encrypt" is a massive money maker for Google.

Google makes their money off advertising. The more https, the more ad sales for them! And the less for their competitors.

It's a mega win for Google.

They also make money when you buy a new smartphone or Chromebook because your old hardware is too slow and the battery life sucks.

"Our effort"

[Anonymous Coward]

>After years of encouraging site owners to transition to HTTPS by default, Google officials say that the effort has begun to pay off.

Of fuck off, go sell some ads. Is this mere ad broker really claiming the credits of increased https adoption? That's rich. This is a company that loads all kinds of crapware ads and data collection crap in websites everywhere. The kind of shit company you have to filter out with ad blockers, with dns and anti-tracking plugins.

Not Your Recipe Site Specifically, No

[Anonymous Coward]

I keep saying that we want to encrypt all internet traffic, so as to make it impossible for the Three Letter Agencies to snoop on us all.

However I'm willing to amend that. Your recipe site does not need HTTPS. There, are you happy?

What we really need is for a substantial component of all Web traffic to be encrypted, and for 99.999% of all encrypted traffic to be recipe sites, standard commercial or financial traffic, porn, cat videos, political arguments, just boring old business as usual. That way, simply being encrypted does not draw the attention of the TLAs. We want that because when 0.1% of all Web traffic is encrypted, you can become a suspect just for using encryption. That's not right no matter what the TLAs say about it.

I don't know how great a traffic percentage a "substantial component" needs to be. Let's say between one-third and two thirds of all internet traffic, as a lower bounding limit. If I really had my way however, it would be 99.999% of all packets, everywhere.

And that's the problem. Until recently HTTP was the default and you had to specifically request and implement HTTPS. This resulted in the vast majority of all packets being unencrypted. We need to flip that around, so that HTTPS is the default and you only get HTTP if you specifically request and implement that.

Re:Not Your Recipe Site Specifically, No

[tepples]

If HTTPS becomes the default, then what becomes the default way to obtain a certificate for a web server on a private LAN?

Re:Not Your Recipe Site Specifically, No

[markus]

With Let's Encrypt, it is pretty easy to automate all of the necessary steps. When they launched about a year ago, there were a couple of device manufacturers that wanted to know how to integrate Let's Encrypt into their wireless access points.

Each owner of an access point would automatically be assigned a (sub)domain administered by the device manufacturer. I haven't seen any devices for sale that do this yet, but as SSL becomes more prevalent I'd expect routers to create hostnames such as windos123.wifi567.netgear-secure.com, and to automatically make a certificate available.

Truth of sense of security

[tepples]

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

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

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

The only browser I've ever seen that warns for valid domain-validated certificates is Comodo Dragon. Any certificate that isn't at least organization-validated causes Dragon to show the "mixed passive content" icon in the location bar and an amber interstitial, which resembles the red interstitial for an untrusted issuer and has text to this effect:

It may not be safe to exchange information with this site

The security (or SSL) certificate for this website indicates that the organization operating it may not have undergone trusted third-party validation that it is a legitimate business. Although the information passed between you and this website will be encrypted, you have no assurance of who you are actually exchanging information with, and many websites connected to cyber-crimes use this type of security certificate. Prior to exchanging sensitive information including login/password, personal identity information, or financial details such as credit card numbers with any website that generates this warning, you should find some alternative method of validating this business or consider abandoning the transaction.

Legacy service on a private LAN

[tepples]

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

Provided it has its own fully-qualified domain name.

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

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

The challenge here is not that these machines can't do HTTPS, it's that they're not provisioned with a certificate. A lot of times, this is because the device doesn’t have a globally unique name, so it can't be issued a certificate in the same way that a web site can. There is a legitimate need for better technology in this space, and we’re talking to some device vendors about how to improve the situation.

It should also be noted, though, that the gradual nature of our plan means that we have some time to work on this. As noted above, everything that works today will continue to work for a while, so we have some time to solve this problem.

Re:Legacy service on a private LAN

[markus]

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

You then operate the Let's Encrypt ACME client in DNS mode to get globally trusted SSL certificates. But nobody other than your internal machines will ever get to interact with those certificates.

Re:Legacy service on a private LAN

[tepples]

Use your external domain and create sub domains.

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

Let cron do the donkey work

[tepples]

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

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

Chrome and Google?

[Anonymous Coward]

Anyone still trusting Google for ANYTHING in 2016 is a fool. If you're not actively blocking everything Google-powered from a trustworthy browser (anything Google didn't create or help create), you're being tracked by Google, and a quick visit to your Google preferences will show you a disturbing trail of all the Googlebot sites you've been to. And while they say you can "disable" this, they're still tracking you behind the scenes.

Just say "fuck you" to Google and embrace privacy and common sense. Oh, and if you have a smartphone of ANY description, not just Google and even if you've disable as much Googleification on the Androids, you're still being tracked. We need to start fighting back against being tracked, cataloged, categorized, and watched NOW. Say no to Google, Microsoft, Amazon, Apple, and many other companies that wants nothing but to watch everything you do and give themselves and other companies the opportunity to deny you things or at least change what they offer based on your innocent habits. The fallacy of "I have nothing to hide" is complete bullshit, and you need to understand that not giving your habits to companies is not just for people trying to hide illegal or bad activities.

misleading statistic

[Anonymous Coward]

how many pages that chrome loads are to google's own sites, services, and pages? gmail? https. youtube? https. photos and g+? https. search? https. even grandma's web searches for "google" and "yahoo" and "hotmail" get counted.

tamil ringtones

[Anonymous Coward]

HyperText Markup Language (HTML) is the standard markup language for creating web pages and web applications. With Cascading Style Sheets (CSS), and JavaScript, it forms a triad of cornerstone technologies for the World Wide Web.[1] Web browsers receive HTML documents from a webserver or from local storage and render them into multimedia web pages. HTML describes the structure of a web page semantically and originally included cues for the appearance of the document.
tamil ringtones

Handout to registrars

[tepples]

Thus the inclusion of WebRTC and Fullscreen in the Secure Contexts proposal, currently a W3C Candidate Recommendation, is one big handout to domain registrars. Ten million homes with NAS devices means 10 million domains that need to be registered and renewed annually, to the tune of $100 million a year for registrars. At least it's not quite as bad as it'd be without Let's Encrypt, in which it would have been a handout to both the registrar racket and the CA racket.

Google collecting URL info?

[Anonymous Coward]

How come no one points out the concern about how Google is apparently harvesting URL information from deployed instances of Chrome?