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.
Can anyone remember when the times were not hard, and money not scarce?
(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