Chrome 55 to start highlighting Not Secure websites
medium.servertastic.com
medium.servertastic.com
This flag has been available for a long time, since at least December 2014. The visual has been updated slightly in 54 or 55 (secure sites do now get the "Secure" badge instead of just a green lock). There is no change in default behaviour though. From time to time Canary changes the default to mark non-secure sites as non-secure, but it's always been rolled back very quickly. It's coming, but probably not very soon.
A story like this makes tech news from time to time. In January this year a lot of sites posted about it, and when the flag was introduced late 2014 many of them did too. As long as there's no announcement from Google or the Chromium team (and there would be), nothing is changing.
The behavior in Chrome 55 (and also 53, the current stable) is the (i) indicator. Clicking on it tells you the website "isn't private": https://certsimple.com/images/blog/american-apparel-insecure...
However Google do intend to mark HTTP as non secure: for indications of future plans, best place to go is directly to the source: see 'Marking HTTP As Non-Secure' https://www.chromium.org/Home/chromium-security/marking-http...
Note: I work at CertSimple.
Sites that do financial transactions, or require user logons or user submissions (forums, comments etc.) need to be SSL, most others don't need to be secure at all. If I am reading a random blog by Joe, and he doesn't have a comments section, why does the site need to be in HTTPS?
Scaling that up - if I'm not logged into Wikipedia, and simply searching and reading articles, why does that need to be served under HTTPS either?
By forcing every site to go HTTPS not only increases the cost of ownership (in time, and optionally, cost) but also adds complexity for small site owners, and completely goes against the open web ideal.
It should be down to the owner of the site if they want to add SSL, those that don't and fulfil the criteria I've outlined, should not be penalised for it.
There's hardly any overhead involved if you add to the browsers page parsing routines a function to identify input fields, and mark a warning on the address bar accordingly if the site is not secure.
Blanket warning on all non-HTTP sites is just lazy.
Because we have already seen tampering that could really cause some issues. Injecting ads, snooping on search info to target advertising, things like censoring specific articles or specific topics.
Because of how global the internet is, regulation can't really solve many of it's issues (unless literally everyone can agree on the rules), so we need to solve them technically. Securing you to the server makes all of those things much more difficult.
>By forcing every site to go HTTPS not only increases the cost of ownership (in time, and optionally, cost) but also adds complexity for small site owners, and completely goes against the open web ideal.
Then let's solve those issues. Added complexity is not a reason to abandon TLS for most sites, it should be a goal to not only get TLS, but to make the process easier for the average joe to setup and run.
By starting to push in the direction of "TLS everywhere" we are encouraging more automatic and easy ways of maintaining this stuff (just look at how far let's encrypt has come in such a short time! How long until it's a GUI program that even my grandfather can use?).
Encryption protects against an eavesdropper logging what you read.
> It should be down to the owner of the site if they want to add SSL
The owner of the site shouldn't also be able to force others to drop their protections against eavesdropping. There are two parties to each conversation.
> There's hardly any overhead involved if you add to the browsers page parsing routines
That only covers a small subset of threat models. Passwords and other credentials are not the only data that needs protection. Thanks to Lets Encrypt, enabling encryption has hardly any overhead. Most of the problems are outdated software and hosting services.
Encryption is important not only for personal safety, it's also needed to protect against threats like China's Great Cannon[1]. Choosing to say with plaintext is socially irresponsible because the decision about using encryption is also about providing ammunition for the Great Cannon.
Because a malicious MITM could modify the content you are reading (and thus affect your perception of a subject). A bit of misinformation here and there can go a long way.
The UX is going to be tricky to get right.
Which is a bit disappointing. Chrome and later Mozilla announced years ago that they'd do this, yet as long as it's an announcement for some undefined point in the far future it doesn't create any pressure to the ecosystem to become more https friendly. I'm saying this as someone who regularly works for publications that can't use HTTPS, because Ad-networks don't care.
I'd really wish Google/Mozilla make their plans to mark HTTP as insecure true.
If a site doesn't have a certificate , there's no identity verification at all and whether or not to trust the site is left up to the user.
If it does have a certificate, and the certificate doesn't appear to be validated by a CA for the domain or organization, or whatever, then there's a risk of misplaced trust. Anyone can issue a certificate for any domain, but they're only "trustworthy" if they've been signed by a CA.
That's the problem. Why are you deriving trust from a self signed certificate? The UI should be similar to plaintext if there isn't a verifiable chain of trust. There isn't any issue of misplaced trust if you aren't actually labeling the connection as trusted.
> Anyone can issue a certificate for any domain
No, they can issue a certificate that allows for encrypted communication with the current host. Trusting a self signed certificate for any other purpose would be a serious bug.
that's why it's so important to blacklist fast certificate authority that do no domain ownership validation; it's a frail system, but it's the best we got for now.
All of your concerns require an assumption that the browser uses unauthenticated encryption the same as PKI authenticated. Please stop conflating encryption with authentication; they solve different problems. This attitude that a partial solutions should be actively discouraged is why the internet is still uses plaintext which should have been dropped years ago.
encrypted works against MITM because of the certificate trust, if you remove certificate trust from the equation, you'd get the exact opposite result: encrypted would be as secure as plaintext.
What, exactly, are you suggesting is a strawman? I was directly addressing your points.
> encrypted works against MITM because of the certificate trust
Nonsense. Encryption works because of $MATH and a shared secret (or matched pair of secrets) between the two parties communicating (the key or public-key/private-key set). With those elements, communication is protected from 3rd party eavesdroppers. What is not provided is authentication of the 2nd party.
Authentication entirely separate feature. Yes, you should use these two features together whenever possible, as it is very important to both authenticate who you are talking to and protect the conversation from 3rd parties. However, either feature on its own is still better than plaintext.
Yes, without authentication it is possible (and sometimes easy) to MITM an encrypted channel. That does not mean all situations are equal[1]. Self signed certificates can be logged, for example, which can sometimes detect a new or changed MITM. The MITM doesn't have the signing key, which is why the certificate is self signed instead of simply leaving it unsigned.
> encryption would be as secure as plaintext
Security depends on your threat model, and encryption alone protects against traditional non-MITM wiretapping. This includes many forms of mass-surveillance. Just because it is possible to bypass that protection with a MITM doesn't mean you should just give up and send plaintext. (and assuming that everyone can and will get a certificate is delusional; see this very thread for examples) Raising the complexity and cost of an attack is good security.
Yes, the UI should probably report unauthenticated encryption as not trusted, just like plaintext. Also, "secure" is a vague term that is overloaded with multiple meanings which can be misleading. It is better to indicate if something is "authenticated", "protected against eavesdropping", etc.
[1] http://chem.tufts.edu/answersinscience/relativityofwrong.htm
> So you prefer plaintext
Anyone else?
Occasionally in a build it flips on then another build off.
Until then, everything else is PR and money grabbing.
There is no announcement that I know of that Chrome will start highlighting http:// sites with a red warning icon and the text "not secure". The headline is wrong. The article is cleverly worded to be misleading while technically correct.
I consider this a broken stupid change.
In saying that, HTTPS is easier than ever to deploy to a website. This will only increase adoption of 'secure by default'
If all sites are HTTPS, Google kills ISPs' ability to inject ads and to profile customers.
Not through any sense of altruism, but because Google is only interested in one megacorp being able to sell ads and track browsing: Google.
It's good business for Google, but let's not pretend it's about "making the web better". It's about keeping commerce on the web as a Google monoculture.
There are simple one-click setup programs that can monitor a wifi network, and inject malware into any downloads of executable or zip files that it can find.
With things like Stagefright still affecting a scary large amount of android users, what happens when someone starts injecting malware into images which can compromise an entire phone without so much as a hiccup.
It could even serve as a sort of plausible deniability...
I'm also unwilling to switch to https. If your ISP is attacking you then you should be tunneling things. I personally like the image compression and caching that they do and think it's somewhat important for my site and others like it.