Google Encrypts All Blogspot Domains With HTTPS 56
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.
Simple question (Score:1)
Why is HTTP used anywhere now? I see no advantage to transferring any data in the clear. Why not use HTTPS everywhere?
Re: (Score:1)
Which is some people are now trying to offer free SSL/TSS certificates, such as Linux Foundation's Let's Encrypt platform.
Let's Encrypt (Score:5, Informative)
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.
Re:Let's Encrypt (Score:5, Interesting)
Its almost free for google anyway. They have their own CA, so while they have to maintain to fulfill CA requirements and do all the paperwork, they do not have to pay for one particular certificate.
Re: (Score:3)
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.
Indeed. TLS certs are, as you point out, available for free. Even if one wishes to pay for a cert, DV certs are available for a pittance: Comodo's PositiveSSL certs are available for as low as $14.97 for three years ($4.99/year) from SSLs.com [ssls.com], a reseller owned by NameCheap. I spend more getting take-out lunch one day than it'd cost to get a cert for three years. That's basically a non-issue when it comes to even the most budget-constrained websites.
Other interesting details:
- Comodo's PositiveSSL offering i
Re: (Score:2)
Except last I checked neither company offers wildcard certificates which makes it somewhat useless when running multiple virtual servers.
Re: (Score:2)
If each virtual server has its own IP address, each virtual server can install its own certificate to its own web server. If they share an IP, the SSL terminator in front can select the appropriate certificate to present to the browser based on the SNI hostname provided by the browser.
Re: (Score:2)
That is true, but that requires registering each virtual server with it's own SSL certificate. Fine if you're doing a few fixed domains, less fine with each domain you add, and even less fine if the domains don't stick around.
If it's automated with script, it's not labor (Score:2)
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.
Re: (Score:3)
There have been 'free' SSL certificates for a very long time. You don't need to buy a certificate to enable encryption (it's just more convenient).
Re: Simple question (Score:3)
You can get a basic SSL certificate for $5 or something like that these days.
Re: (Score:1)
Four excuses against HTTPS (Score:1)
Why not use HTTPS everywhere?
There are about three reasons:
Re: (Score:2)
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 serv
Re: (Score:2)
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.
SSH-style TOFU for DNS-SD (Score:2)
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 cer
Re: (Score:2)
I don't think PKI is really feasible for .local, because the definition of what is trusted for .local depends on what network you're using. I'm more than willing to trust certain arbitrary signing certs at work, but that doesn't mean I want to trust those signing certs if they suddenly show up on a server on some other network in the wild.
Re: (Score:2)
Certs cost usually and clear HTTP traffic is free.
Re: (Score:2)
WOW! Such Technical Innovation! (Score:1)
This Google company must be pretty elite and is right on top of security.
Re: (Score:2)
Yeah, they are so elite. Just recently they have encypted their whole main site over https [neowin.net]! Their main site, just think of the processing power required for this. Of course, slashdot is much more advanced than them, we already have encryption since months now.
Re:Who signs the certificates and maintains the ke (Score:4, Insightful)
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.
Re: (Score:3)
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.
I don't understand (Score:2)
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 (pas
Re:I don't understand (Score:5, Informative)
HTTPS provides several benefits:
- Encryption which, as you point out, keeps other parties from knowing the content of data you access. Sure, the bulk of that data may be mundane, everyday stuff that you don't really care if anyone knows about, but there's no harm in keeping it private in transit. It's the same reason you enclose letters in envelopes rather than sending postcards.
- Verifying the authenticity of the server. Domain-validated certificates offer a relatively low level of validation, but they still provide you reasonable assurance that the server you're communicating is the one operated by the actual owner of that domain name -- your connection isn't being intercepted and spoofed by some shady wifi hotspot, for example. Organization-validated and Extended Validation certificates provide higher degrees of validation, and include details (e.g. company name, location, etc.) of the entity to whom the certificate was issued.
- Tamper-resistance. All HTTPS connections provide tamper-resistance by using either HMAC or AEAD ciphersuites. This prevents third parties from altering the content. A public hotspot or your ISP may inject content [arstechnica.com], malicious or not, into unencrypted connections. HTTPS prevents this.
Considering that there's essentially no costs for using HTTPS (certificates are free or exceedingly cheap, CPUs have hardware support for AES so there's basically no overhead for encrypting data, ECDHE key exchanges are extremely fast, as are ECDSA signatures, and so present minimal load to servers. RSA signing is a bit slower for servers, but modern CPUs are fast and TLS handshakes are brief and only happen occasionally.) and many benefits, why wouldn't everyone want to secure data in transit?
Re: (Score:2)
slow https loading (Score:2)
Re: (Score:2)
"and I don't care that the owner knows what papers I read."
Which of course, they do anyway since they do one end of the encryption/decryption. And in any case, the site owner, their ISP, your ISP, everyone in between, the NSA, the Chinese, white hat hackers, evil hackers, and everyone else who cares knows "what paper you read" albeit not necessarily what specific content you are interested in. The IP routing information isn't (more or less can't be?) encrypted. So the fact that you sent packets to/ recei
Re: (Score:2)
If you write a blog post that gets reasonably popular, someone MITM it and changes a link you recommended to one that has a shadier purpose, it can screw over some visitors.
https helps with that.
Re: (Score:2)
Funny you should say that rduke15 ... if that is in fact your real name!
When you use the web to publish how do you control what you publish? You sound like you live in a nice country where you can't be prosecuted for your ideas or the things which you read. Not everyone does so. What to you is an innocuous article you wrote on some incredibly stupid thing the ruler of an oppressive regime has done is to someone else content that could potentially affect their lives.
I for one consider myself lucky to live in
Re: (Score:2)
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.
Anonymity is like a seatbelt: you don't need it most of the time, but when you do, you either have it or die.
Strict-Transport-Security (Score:2)