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.
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.
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
You left out one, and it's a pretty big one. By policy, no certificate authority is allowed to issue a TLS certificate for any host in the .local domain, because there's no ownership/legitimate control over those domains, multiple people could legitimately lay claim to the same domains on different networks, and the domain names are chosen by random end users who don't even know what a TLS certificate is, much less how to buy their own domain name. Therefore, any Wi-Fi-connected device that needs to serve content via DNS service discovery must currently use an unencrypted connection.
IMO, that's a rather serious flaw in the notion of requiring HTTPS everywhere. Unlike the issues you listed, which all fall into the category of "because X hasn't upgraded Y yet" or "because X hasn't bothered to support it yet", this one is actually a problem for which there is currently no solution, and any possible solution would require completely changing the way we think about site security, moving us from a strict central trust model to something much more flexible and decentralized.
Basically, until that problem is solved, the IoT is DOA as far as HTTPS is concerned.
Check out my sci-fi/humor trilogy at PatriotsBooks.
You make a good point about DNS service discovery being incompatible with CAs. This thus makes DNS service discovery incompatible with Service Workers and other new features that browser publishers have declared to be HTTPS-only.
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.