SoylentNews is people
SoylentNews
posted by
cmn32480
on Sunday September 11 2016, @05:48PM
from the there's-gotta-be-a-downside-to-this dept.
from the there's-gotta-be-a-downside-to-this dept.
According to a post on the Google Online Security Blog, beginning in January 2017 Google Chrome will begin flagging all sites that use traditional HTTP rather than HTTPS for passwords or other sensitive information as "insecure". It also indicates that Google plans to eventually start flagging ALL traditional HTTP-only sites as "insecure". While HTTPS has always made sense for truly sensitive information, a pure HTTPS web does have implications for legacy tools - essentially if anyone is not using the absolute latest of one of the "big three" web browsers, they will always potentially be just one security update away from being locked out of the web.
This discussion has been archived.
No new comments can be posted.
Google to Start Punishing HTTP-Only Sites
|
Log In/Create an Account
| Top
| 63 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
I don't want a pickle,
I just wanna ride on my motorsickle.
And I don't want to die,
I just want to ride on my motorcy.
Cle.
-- Arlo Guthrie
(Score: 3, Informative) by TheRaven on Monday September 12 2016, @09:25AM
scaring away everyone with my self-signed certificate
Serious question: You've gone to the trouble of generating a certificate and configuring your web server to use it. You've generated a CSR and signed it yourself. That's 95% of the effort in getting a proper certificate, so why would you not go the rest of the way?
sudo mod me up
(Score: 0) by Anonymous Coward on Monday September 12 2016, @02:49PM
Generating a key and a self-signed certificate represents 95% of the effort? You can do that in a single command-line invocation of openssl:
That leaves the other 5% (one-nineteenth of the total effort) to reach out to a third party to get them to sign your key. I think you're either overestimating the difficulty of creating a self-signed key or underestimating the difficulty of dealing with third parties.
(Score: 2) by TheRaven on Monday September 12 2016, @03:17PM
That's not a self-signed cert, that's an unsigned cert. With an unsigned cert, your web server has access to the only private key in the chain. There's no way that you can revoke, and anyone that compromises your web server can generate new certificates that appear to be you.
To generate a self-signed cert, you need to generate a signing cert, a CSR from your unsigned cert, sign the CSR with the signing cert, and (typically, depends a bit on the server) merge the two. When you've done this, you keep the private key for the signing cert on a different machine, and then if your web server is compromised you can revoke the cert, yet keep using other certs signed with your trust root and not need to update any client devices that trust that root. Even if you're not doing revocation, you can create certs with a short lifetime and roll them over every couple of months without surprising clients (same signing cert) and reduce the impact of a compromise.
With StartSSL, the only extra step is that you paste the CSR into a web form instead of passing it to an OpenSSL command line. Actually, if you trust your web browser, you can generate the keypair using the browser's built-in functionality, and then you just need to enter the domain name and copy the cert and key to the correct location, without needing to use the openssl command line at all. With LetsEncrypt, you set up a fairly simple daemon and it will automatically generate and refresh the certs for you.
Generating the key and cert is not the sum total of the effort involved, you also need to configure the server (or servers, if you're also turning on TLS for email, XMPP, and whatever else you run servers for) to use ssl, tell it where to find the key, and so on. When you include these steps, having a third-party sign the cert is, as I said, a tiny fraction of the total effort.
sudo mod me up
(Score: 2) by Pino P on Monday September 12 2016, @03:43PM
With StartSSL, the only extra step is that you paste the CSR into a web form instead of passing it to an OpenSSL command line.
With StartSSL, as with all other CAs that follow the CAB Forum's Baseline Requirements, the machine still needs a valid fully qualified domain name (FQDN). You can't have StartSSL sign a certificate for an RFC 1918 private IP address or for a domain in some made-up TLD such as .local. This means everyone who wants to run a NAS internally on a private home LAN and access the NAS through HTTPS has to buy a domain for that LAN and renew it annually.
(Score: 2) by TheRaven on Monday September 12 2016, @03:48PM
sudo mod me up
(Score: 2) by Pino P on Tuesday September 13 2016, @01:10AM
If you want to run a device on a private network, without connection to the Internet, then you probably have a far smaller set of client machines to worry about.
But this set would include friends and family visiting my home, who aren't guaranteed to know how to install a trusted root CA on their phone or tablet.
if you run a device on a private network without connection to the Internet, then it probably won't be listed on Google anyway.
Clear HTTP will be penalized not only in Google Search but also in Google Chrome, including the copy of Google Chrome on the device of a visiting friend or family member.