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.
This login session: $13.76, but for you $11.88.
(Score: 5, Informative) by The Mighty Buzzard on Sunday September 11 2016, @07:03PM
You don't currently have to but you absolutely should. Unless your visitors have a means of verifying your cert, you're arguably worse off than using plain old http because of the illusion of security*. My personal server is subscribed to a dynamic dns provider and has a LE cert. Both together took maybe ten minutes to set up automatic renewals for.
* Granted the NSA probably has plenty of ways to see through it anyway but our respective ISPs and everyone sharing a network with us do not.
My rights don't end where your fear begins.
(Score: 2) by Username on Sunday September 11 2016, @11:07PM
How exactly does verifying a cert protect anyone? The point when someone is at your ISP, they already have all the keys. It makes no difference. If a server was compromised the CA revoking a cert does nothing either, since whoever compromised the server already has all the information, and the first person to figure this out wouldn’t be the CA, it would be the webmaster. They can switch certs faster than a CA can void, plus saves the added steps of dealing with the CA.
(Score: 2) by TheRaven on Monday September 12 2016, @09:32AM
The next step up the adversary model is someone who can perform a MITM attack. That includes your ISP, anyone whose WiFi hotspot you're using, and so on. If you're using a self-signed cert, and the client isn't doing certificate pinning, then MITM is trivial. Anyone can create a cert that has the same public information in it, just a different key. They establish a connection to the server, you establish a connection to them. Both hops are encrypted, but you don't realise that they're inspecting and potentially tampering with the content. Boxes that do this are mass produced and easy to buy.
The next step up the adversary model is someone who has compromised (either technically or legally) a trusted SSL root. This basically limits you to nation state actors. Certificate Transparency helps against this model, because if two people accessing the same site see different certificates then it's harder to falsify. There are also some special DNS records that you can set to indicate who people should expect to see your cert signed by (though this only works well if you're using DNSSEC). This means that if you signed your cert with SmartCom and someone visits it and sees an encrypted connection with a cert signed by the Turkish national CA, then someone somewhere is probably doing something bad.
Finally, there's the thread model of a targeted attack that actively compromises either the client or the server. You're basically screwed in this situation, but this is a much harder thing to do on a large scale. All of the other attacks can be done on hundreds to hundreds of thousands of clients at a time quite easily.
sudo mod me up
(Score: 2) by The Mighty Buzzard on Monday September 12 2016, @11:59AM
There's a lot more ways to secure TLS than just having a cert nowadays. Look into HPKP especially if you're really interested but be aware that losing your key can lead to permanent bricking of TLS for your website.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Monday September 12 2016, @04:20PM
The big three browsers cap HPKP at 60 days. So, while it can screw you over for awhile, it shouldn't be permanent. However, 60 days is a long time on the internet.
(Score: 2) by NotSanguine on Monday September 12 2016, @02:58PM
How exactly does verifying a cert protect anyone?
Not very much. However, encrypted communications across the internet keeps prying eyes that don't control the endpoints from viewing your traffic.
HTTPS is as much (or more) about encryption as it is about identity.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by Pino P on Monday September 12 2016, @03:36PM
My personal server is subscribed to a dynamic dns provider and has a LE cert. Both together took maybe ten minutes to set up automatic renewals for.
How did you get a Let's Encrypt cert for a subdomain at a dynamic DNS provider? I thought LE's rate limits [letsencrypt.org] forbade issuing more than 20 certificates per domain per week. So if 20 other customers of the same dynamic DNS provider have been issued a certificate in the past 168 hours, you get the rate limit error message instead of a certificate. LE does make an exception for DNS providers on the Public Suffix List, but I've read on LE official forums and the PSL's issue tracker on GitHub that since LE entered general availability, there's been a huge backlog for dynamic DNS providers that want onto the PSL.
And do "automatic renewals for" the dynamic DNS provider include a recurring fee?
(Score: 2) by The Mighty Buzzard on Monday September 12 2016, @05:23PM
Well, I was one of the lucky few who made the initial cut for my dyn dns provider but they just got whitelisted recently as well, so I'd be okay now even if I weren't lucky at the outset. My best advice is to pick an already whitelisted provider and redirect to that domain name if you already had another set up on a non-whitelisted provider. Or, you know, annoy your provider and then wait.
Ye gods no! I wouldn't pay for a subdomain no matter how many bells and whistles they offered. I'd put a record in for tmb.soylentnews.org and update it manually as my ip changed before I paid a dyn dns provider.
My rights don't end where your fear begins.