Slashdot Mirror
Google Encrypts All Blogspot Domains With HTTPS
Reader Mickeycaskill writes: Google is continuing its crusade to encrypt the web by enabling an HTTPS version of every single domain hosted on Blogspot. The search giant started the rollout last September, but as an opt-in service. Now users can opt to visit an HTTPS version of a site without its participation, while administrators can turn on an automatic redirect so all visitors are sent to the encrypted version. "HTTPS is fundamental to internet security; it protects the integrity and confidentiality of data sent between websites and visitors' browsers," said Milanda Perera, security software engineer at Google. Google already encrypts its search results, Google Drive and Gmail, while it also ranks HTTPS-enabled sites higher in the search. Blogspot rival WordPress began rolling out HTTPS in 2014.
Why is HTTP used anywhere now? I see no advantage to transferring any data in the clear. Why not use HTTPS everywhere?
This Google company must be pretty elite and is right on top of security.
This may be overly cynical of me, but could they be doing this to imbue the sense of improved security, while still being able to decrypt and observe the traffic themselves? For themselves as well as for the government, where the particular datacenter is located?
And, yes, even if they are being self-serving, this is still good news for folks accessing these sites from places, where government does far worse things to the innocent, than mere snooping.
In Soviet Washington the swamp drains you.
Now if they could fix their custom gadget support (custom gadgets have been broken for at least 6 months maybe more, trying to add one gives an error message even for their demo gadgets)....
Why not use HTTPS everywhere?
There are about three reasons:
Third-party resource does not support HTTPS Mixed content policies tend to block use of HTTP resources in HTTPS documents. For example, until September 2013, no major ad network supported HTTPS, and websites redirected non-subscriber visits from HTTPS to HTTP to ensure ad display. September 2013 is when AdSense added HTTPS. Shared web host without HTTPS In the early 2010s, many shared web hosts charged extra for HTTPS support. Having already paid for several more months of hosting is a disincentive to switching. Troublesome certificate renewal Let's Encrypt, a recently popular CA that issues domain-validated certificates automatically using the ACME protocol, currently makes them valid for 90 days. But some shared web hosts do not offer anything like cPanel for automatic installation of a renewed certificate. Instead, they require manually filing a support ticket every time the certificate is renewed. WebFaction is like this, and someone has staged a passive-aggressive protest by making an an ACME client that requests a certificate and then automatically files a support ticket. Users of SNI-ignorant browsers The site shares an IPv4 address with another site, and the site receives significant traffic from web browsers that do not support Server Name Indication, which allows name-based virtual hosting of HTTPS sites. The most popular such browser was Internet Explorer on Windows XP. But since April 2014, this browser has reached its end of support. Not only has its usage share plummeted, but because it is no longer receiving security updates, we can assume it to be no longer secure against man-in-the-browser attacks.Good observation. Google wants to filter out independent voices so that paid interests predominate. That benefits Google's business model more than search results pointing people to free sites.
The downside is that a SSL or TSS certificate is often not free
Certificate cost is no longer the obstacle it used to be, as a TLS certificate is free unless you need organizational validation. StartSSL and WoSign have been providing domain-validated (DV) certificates without charge to individuals for years, and automated ACME CA Let's Encrypt has been in operation for several months.
This may be overly cynical of me, but could they be doing this to imbue the sense of improved security, while still being able to decrypt and observe the traffic themselves? For themselves as well as for the government, where the particular datacenter is located?
How is encryption of data on-the-wire relevant to the observation of data stored in their datacenters?
Whether or not they use HTTPS, Google has always been able to access the content of Blogspot-hosted blogs because Google runs Blogspot and the data resides on their servers. Adding HTTPS doesn't change that at all.
Sure. But now the users will think themselves more secure. And they will be indeed — except not from Google.
You and I realize this. Many others might not.
In Soviet Washington the swamp drains you.
I don't understand this rage to encrypt everything. I publish some web pages (a couple of blogs, my résumé, a few very specific instructions pages, etc) and cannot see any reason to have these pages delivered over encrypted links.
I use the web to _publish_ stuff, and to read what others _publish_. When I buy a newspaper at my local newsstand, I don't want it encrypted, and I don't care that the owner knows what papers I read.
While there are many good reasons to have some web traffic encrypted (passwords, transactions, ...), this sudden movement to encrypt everything looks really weird to me.
Or are there reasons which I don't see, why some people or entities would have some interest in everything being encrypted?
The data between server and client is secured. Nobody can steal your passwords in route because they are locked up in an envelope. This is marginal security improvement, and a much needed one.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
This is mostly related to antivirus that do extra certificate verification.
Oddly, they did not enable Strict-Transport-Security
Now all they have to do is update their default templates to ones that doesn't look like something out of 2003.
Currently, Google changes all their certs several times a week. This is obviously bad, though most users will not notice, since they don't have browsers/extensions that warn about that.
That explains all the mismatched content errors.
Back in the day, many moons ago it was not uncommon to prefix all your image/script/css URIs with "http://" now all those sites break and in some cases horribly. Not to mention all the third party widgets that fail when called as https. I have seen plenty of big names that cannot handle calls to their API on https.
But not to worry most of these sites are unmantained.
What you describe likewise falls into the category "because DNS-SD doesn't support a PKI yet". If it did, browsers would be updated to trust it for the local TLD. Until then, it's easier to apply a trust-on-first-use model, like that used by SSH, through the "add exception" button that browsers show for an untrusted issuer. The device generates a self-signed certificate, the user manually verifies the key fingerprint out of band on the exception screen, and the browser adds it to the list of user-vetted certificates. Public sites use a CA because it's impractical to verify the fingerprint out of band, but this verification is more practical on a LAN.
The point of ACME, the protocol used by Let's Encrypt, is that you can script the acquisition of a certificate for each domain on which you spin up a virtual server. If you also script association of the acquired certificate with each virtual server, there's very little ongoing labor.