
Chrome 55 to start highlighting Not Secure websites - andygambles
https://medium.servertastic.com/chrome-plans-to-start-highlighting-not-secure-websites-2babf35b46e6#.er35bih8j
======
Ambroos
Not by default. When leaving chrome://flags/#mark-non-secure-as on "default",
even in Chrome 55, non-secure sites are just neutral and don't have any
specific non-secure indication.

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.

~~~
nailer
You're correct: this is hidden behind a flag that's not currently enabled.

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...](https://certsimple.com/images/blog/american-apparel-insecure.png)

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...](https://www.chromium.org/Home/chromium-security/marking-http-as-non-
secure)

Note: I work at CertSimple.

------
userbinator
One of my biggest concerns is that the _many_ "Not Secure" websites out there,
likely older ones, will get ostracised as a result of this type of change. I
don't think that's necessarily a good thing, because that's where I've found
the most informative and interesting content. You can imagine in the future,
users coming across some site that actually has good information, but being
scared away by the "Not Secure" and instead going to some vapid ad-filled
"modern" site with very little in the way of detailed content, just because it
happens to be using HTTPS.

~~~
Jaruzel
I totally agree with this.

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.

~~~
asherkin
> 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?

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.

~~~
tdkl
Targeting Wikipedia is different then personal static blog of John Doe.
Wikipedia has resources for this, John doesn't - hence threatening the open
web.

------
hannob
This latest flash of "chrome marks http as insecure" news seems very
premature. It's an experimental feature behind a flag and as far as I can see
there's nowhere any indication that this will hit average users any time soon.

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.

------
wallunit
I never got, in the first place, why browsers show a big fat warning when
accessing a properly encrypted website where the certificate can just not be
verified, while a completely unencrypted website on the other hand looks just
legit in the address bar.

~~~
LoSboccacc
because the whole thing lives off trust. if any certificate could be self
signed for getting the browser trust, all MITM attack would go unnoticed
unless the browser is pinning the hash of specific domains.

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.

~~~
pdkl95
So you prefer plaintext, which is even _easier_ to MITM? These MITM attacks go
unnoticed every day. Logging self signed certificates at least gives us a
_chance_ at detecting a MITM.

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.

~~~
LoSboccacc
nothing like that, this is just a strawman and you don't get to put words that
weren't in my comment just to make a random point about authentication and
encryption

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.

~~~
pdkl95
> strawman ...words that weren't in my comment

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](http://chem.tufts.edu/answersinscience/relativityofwrong.htm)

~~~
LoSboccacc
sure thing, then please go and highlight for me where I wrote, suggested,
hinted or implied

> So you prefer plaintext

------
andybak
Just downloaded Canary. I'm not seeing it. I get the green secure on https but
I don't see the red on any http sites.

Anyone else?

~~~
andygambles
As per an earlier comment option to enable this feature is here:
chrome://flags/#mark-non-secure-as

Occasionally in a build it flips on then another build off.

------
quickben
The proper news would be that Chrome started properly highlighting all MITMed
https pages in the enterprise setting where an organization just blankly subs
the cert.

Until then, everything else is PR and money grabbing.

------
Flimm
This is what it actually looks like in Chrome Canary:
[http://i.imgur.com/PN8OewF.png](http://i.imgur.com/PN8OewF.png)

There is no announcement that I know of that Chrome will start highlighting
[http://](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.

------
jbb555
Still not changing my websites to https. They don't need to be "secure", they
are not going to be "secure".

I consider this a broken stupid change.

~~~
Aaron1011
Why? Without HTTPS, anyone between a user and your server can modify your
page, without you noticing.

~~~
madeofpalk
There are certain types of sites where that doesn't really matter. My personal
blog, for instance, I don't see the need for HTTPS there.

In saying that, HTTPS is easier than ever to deploy to a website. This will
only increase adoption of 'secure by default'

~~~
Symbiote
People modifying your page can include ISPs injecting ads or reducing the
resolution of images to save bandwidth.

~~~
userbinator
I'm not the parent, but I say "let them".

~~~
andybak
How about injecting malware?

~~~
Klathmon
And this isn't a "it could happen some day" threat, it's already a thing.

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.

------
gokhan
If Google starts serving ads over https without affecting revenue, many sites
will convert overnight.

------
helthanatos
Runescape need fix Runemetrics... Chrome almost always says it's insecure :(

