
Chrome is warning users about insecure pages - tombrossman
https://certsimple.com/blog/your-connection-to-this-site-is-not-private
======
eatbitseveryday
Tim Berners-Lee has an article titled 'Web Security - "HTTPS Everywhere"
harmful'[1]. He argues not that encryption is bad (as the title might
ambiguously suggest), but that the use of a different URI prefix (http vs
https) is harmful because it requires use of that prefix to ensure encryption
and authentication is used. Rather, the HTTP prefix should be used for
encryption, and upgraded in real-time by the client.

> A proposal then is to do HTTPS everywhere in the sense of the protocol but
> not the URI prefix. A browser gives the secure-looking user interface
> message, such as displaying the server certificate holder name above the
> document, only when the document has been fetched in an authenticated over
> an encrypted channel. This can be done by upgrading the HTTP to include TLS
> in real time, or in future cases by just trying encrypted version first.

He also states

> It is the user's task to ensure that their interactions are secure.

meaning, users are trained to look for the 's' but browsers are hiding the URI
prefix, making this difficult.

[1] [https://www.w3.org/DesignIssues/Security-
NotTheS.html](https://www.w3.org/DesignIssues/Security-NotTheS.html)

~~~
hannob
This pops up every time. I don't really get what he's trying to tell us here.
If we forward HTTP requests to HTTPS and use HSTS on top we're basically doing
what he wants, right?

~~~
pdpi
As I understand it, he's suggesting that HTTP should incorporate something
equivalent to STARTTLS as seen in some form in IMAP, POP3, FTP, LDAP,
Postgres, and probably several others I'm forgrttingg

~~~
marcosdumay
Well, that gave really bad results in SMTP IMAP, POP3, and LDAP. Postgres just
does not suffer much because the client always knows wether to upgrade the
connection or not.

Ideally, we should be using DANE or some other kind of signed broadcasted
info. Telling the user what happened is just a very good workaround (that will
stay useful even if we change to DANE).

~~~
tho9Ohx1eo
What bad results in IMAP or SMTP? In my experience this works as advertised.

------
newjersey
Is there a good reason why squarespace can't enable https at least for those
who "buy" their domain names from squarespace as well? It shouldn't cost
squarespace any significant amount of money, should it?

And yet [https://support.squarespace.com/hc/en-
us/articles/205815898-...](https://support.squarespace.com/hc/en-
us/articles/205815898-Does-Squarespace-support-SSL-access-)

~~~
nailer
My understanding (I talked to them about it a year ago) was they have to do
some work on making a big SNI-based load balancer that works with their
current network setup.

~~~
arrty88
HAProxy does this out of the box. They should be all over this IMHO.

~~~
nailer
Of course, but I don't think they're using a generic LB / terminator and while
they could move to one, it'd still take a long time to migrate on their scale

------
cpeterso
Firefox already adds an (i) icon (with a "Connection is Not Secure" note in
the popup) for all [http://](http://) pages plus a red icon for
[http://](http://) pages with a password field.

------
anonymousguy
HTTPS everywhere is nice... except if your current web host makes free HTTPS
hard because they make money from selling certificates.

~~~
sotojuan
I once tried to do Let's Encrypt or any free SSL with my namecheap domain and
apparently you can't. Is that true? I don't really want to change domain name
companies because I'm lazy and it's probably time consuming to get right...
can I get free HTTPS if I host my site on Netlify and just point my URL there?

All I use it for is my Jekyll-powered personal site on GitHub pages. I don't
mind not using GitHub for it anymore, just want it to work with SSL.

~~~
moosey
In order to do this, you'd need to put an SSL endpoint between your github
page and the client. It could probably be done but it sounds like a no-no.

For instance, I'll bet that if you set it up so that your namecheap DNS A
entry was pointed to your own box that had nginx/haproxy/cloudflare/whatever
handling SSL decryption (and certs) and then backended to your github pages,
it would work, but I'm not a fan of the idea.

------
pyre
The blog post is dated September 2, 2016, and it claims:

> Today Chrome's stable channel was updated with a new HTTPS UI.

But I remember noticing these changes _at least_ a week ago if not longer. The
Chrome Stable channel link he used supports me in this as it's dated July 20,
2016.

~~~
lorenzhs
In the next sentence, the article goes on "Chrome 53 for Windows, Mac users
got them in Chrome 52" \- could that explain the situation perhaps?

~~~
pyre
It's a little confusing that a sentence saying "today" links to a blog post
from July.

~~~
nailer
I originally posted it in July for the Mac changes, then updated it today when
they hit on Windows. I've changed the link to the Windows 53 release.

------
bandrami
As long as they treat an untrusted certificate as worse than plaintext (when
in fact it's strictly better) this is all theater.

~~~
consto
Regardless of your views of the CA system, trusted certificate issued by a CA
are designed to offer _both_ security and authentication. An untrusted
certificate however provides only security. I expect the reason browsers treat
unsigned certificates as bad is for a few major reasons:

* Security without authentication (While slightly better than plain HTTP) is near useless in the real world. Without the authentication that CA trusted certificates provide, you have no guarantee that the host you are communicating with is the site and not a MitM attacker, all the certificate stops is passive eavesdropping.

* The SSH system of connecting to a host once and saving the certificate is unworkable on the larger web. You do not and can not know the certificate of any random site you visit, the CA system solves this problem.

* Browser vendors and CAs actively want websites to be using CA trusted certificates. If browsers accepted untrusted certificates a larger number of sites would use them, as opposed to CA trusted certificates.

* Unlike HTTP, a minuscule number of websites use unsigned certificates and as a result it is safe to penalise sites using them. The end game for browsers vendors is that every site uses a CA trusted certificate; this update to chrome further shows their intent to deprecate HTTP.

~~~
dlubarov
I agree that TLS has little value if you can't verify who you're talking to.
But at the very least, it's no _worse_ than unencrypted HTTP. So it doesn't
make sense to me that browsers are more stern about untrusted certs.

~~~
deadbunny
It's treated as worse because if people get used to clicking "accept" for self
signed then they'll do the same when they get MITM'd. Want an example? Any
error dialogue.

~~~
Dylan16807
So you think the current browser behavior, with a scary warning and an accept
button, is bad?

If they were treated like http there would be no dialogue.

------
fizzbatter
Hmm, i have a bunch of static sites on custom domains through things like
Github pages. Guess i need to get them figured out.

~~~
bobfunk
Have a look at Netlify ([https://www.netlify.com](https://www.netlify.com)) -
our free tier is like GitHub pages on steroids including HTTPS for custom
domains (and deploy previews, use any build tool not just Jekyll, redirect
rules, etc...).

~~~
wodenokoto
what do you mean when you say "not just jekyll"?

~~~
citruspi
GitHub Pages only supports building sites with Jekyll[0].

According to the Netlify documentation[1], it looks like they support any/most
tools, including Jekyll, Grunt, Middleman, Roots, Hugo, etc.

[0]: [https://help.github.com/articles/using-jekyll-as-a-static-
si...](https://help.github.com/articles/using-jekyll-as-a-static-site-
generator-with-github-pages/)

[1]: [https://www.netlify.com/docs/continuous-
deployment](https://www.netlify.com/docs/continuous-deployment)

------
vizitas
Worth migrating to HTTPS soon then. There's a couple tools here to help make
sure you don't end up with HTTPS mixed content issues:
[https://httpschecker.net/](https://httpschecker.net/) (Desktop & online.)

------
jalada
The article mentions free DV certs from Heroku alongside offerings from Let’s
Encrypt and CloudFlare. But Heroku don’t offer certificates for your domain
like LE / CloudFlare, only ones for *.herokuapp.com. You have to obtain a
certificate yourself.

------
tomjen3
Have lets encrypt committed themselves to issuing any valid certificate for
any site and never canceling it based on them not liking the content?

I don't want a future where we need companies permissions to post on the
internet. Especially not political stuff.

~~~
pfg
That's a fight you'll have to take up with various root programs and the CA/B
Forum. There are provisions that allow root program operators such as
Microsoft to force Let's Encrypt to revoke certificate, though as far as I'm
aware this should be limited to domains hosting phishing sites or malware.

I'd argue Let's Encrypt's policy is as good as it can be while still following
the policies required for root inclusion. Here's a relevant blog post[1].

[1]: [https://letsencrypt.org/2015/10/29/phishing-and-
malware.html](https://letsencrypt.org/2015/10/29/phishing-and-malware.html)

------
rpiwetz
After updating Chrome, I visit google.com and see the gray i due to "a weak
security configuration". If users are seeing this gray i everywhere, it will
just be ignored, right?

~~~
oneeyedpigeon
You're going to [http://www.google.com](http://www.google.com)? Is that even
possible? Can you post the full final URL that you are actually viewing?

~~~
nailer
Corporate office with a MITM proxy? Could be worth looking at who signed the
cert.

------
kels
EV certs don't look as cool as they used to. The green they use is to close to
black. I know Edge got rid of the green bar as well but the green they use
stands out.

~~~
deathanatos
I feel like I'm missing something here, as both you and the article heavily
imply that Chrome _displayed_ EV certs prior to 52. In my experience, Chrome
hasn't displayed EVs; here's an EV cert site for me under Chrome 51:
[https://i.imgur.com/azKdzPd.png](https://i.imgur.com/azKdzPd.png) — this is
the same presentation it gives DV certificates.

(The same site in Firefox:
[https://i.imgur.com/yrtypBZ.png](https://i.imgur.com/yrtypBZ.png) )

~~~
pfg
Here's a screenshot of the EV UI prior to this change: [https://ftt-
uploads.s3.amazonaws.com/browser-ssl-ui-comparis...](https://ftt-
uploads.s3.amazonaws.com/browser-ssl-ui-comparison.png)

It's possible that some sort of corporate MitM proxy is replacing the
certificate in your case, or it's CT-related, as mentioned in a sibling
comment.

~~~
deathanatos
I'd see a MitM in the cert chain if I manually inspect it, wouldn't I? (It'd
be signed by the corporate MitM CA cert, right?)

Interesting that it shows up in your screenshot though; BoA on both Chrome 51
(on OS X) and Chrome 51 on Linux doesn't display the EV for BoA, or GitHub.

(I doubt the MitM one, since the Linux machine is my home one. The OS X one is
my corp laptop, so corp MitM'ing is believable there.)

or is the screenshot incredibly outdated, since it says Chrome 8, and CT came
later?

~~~
pfg
> I'd see a MitM in the cert chain if I manually inspect it, wouldn't I? (It'd
> be signed by the corporate MitM CA cert, right?)

Yep, it should show up in the cert chain.

> Interesting that it shows up in your screenshot though; BoA on both Chrome
> 51 (on OS X) and Chrome 51 on Linux doesn't display the EV for BoA, or
> GitHub.

I'd guess for some reason Chrome doesn't think it has received a qualified SCT
for the certificate and is refusing EV treatment. Not sure which SCT delivery
methods Chrome supports, and why they might be failing here.

> or is the screenshot incredibly outdated, since it says Chrome 8, and CT
> came later?

It's definitely old, but I don't believe it's related. FWIW I'm getting the EV
UI on OS X with Chrome 54 when I visit
[https://www.bankofamerica.com/](https://www.bankofamerica.com/).

------
chris_wot
Anyone know wh wildcard SSL Certs only work on the first level of domain
names?

Case in point -
[http://www.pinterest.onelogin.com](http://www.pinterest.onelogin.com)

~~~
gnosek
All of them, AFAIK. I _think_ it's been like that since more or less IE7 days.

~~~
chris_wot
Yes, but why?

------
JBiserkov
I was delighted to find "Let's Encrypt SSL" in my cPanel.

Tip: Select example.com and www.example.com and press 'Issue Multiple' to get
1 certificate that covers both!

------
cjhanks
I find it sad that corporations have decided the internet should be
predominantly a private space.

Think of it, all of those brilliant [http://c2.org](http://c2.org) wiki's and
ASCII-doc sites are now marked "insecure".

Fundamentally -- some wonderful scientists and engineers created a paradise of
free exchange. Commercial enterprise introduced the concept of 'money'. A
bunch of thieves robbed them. And so we _all_ have to put up walls with locks
on them.

~~~
savanaly
It's not just about money, right? Even if it was just scientists writing
essays and sharing them with each other we would still need https to prevent,
say, providers from snooping on or altering page contents.

~~~
semi-extrinsic
Since I am the creator and maintainer of a scientific web app for molecular
dynamics (shameless plug:
[http://www.bottledsaft.org](http://www.bottledsaft.org)) which is not on
https (yet), I decided to check whether scientists browsing the net will
quickly learn to ignore this warning.

Finding so far: Yes, they will. No need to hurry, but I will go https
eventually. Of the sites I checked quickly, these are running non-https by
default:

[http://www.tandf.co.uk](http://www.tandf.co.uk) (Taylor & Francis, bunch of
engineering journals)

[http://www.aps.org](http://www.aps.org) (American Physical Society, i.e. all
the Phys. Rev. journals)

[http://journals.cambridge.org](http://journals.cambridge.org) (bunch of math
and physics journals)

[http://www.thomsonreuters.com](http://www.thomsonreuters.com)
(ManuscriptCentral, Scopus, the home of Impact Factor)

[http://www.sciencemag.org](http://www.sciencemag.org) (Science and other AIAA
journals)

[http://www.nature.com](http://www.nature.com) (Nature Publishing Group)

... and I couldn't be bothered to check more

~~~
JadeNB
While this is good evidence of what is actually happening, _please_ let's not
suggest, even implicitly, that publishers are a place to look for guides to
best practices [0]. I don't know about the sciences more generally, but, in
math, "because the publishers do it" is just about the best reason possible
_not_ to do it [1].

[0] Except maybe that they publish them. :-)

[1] Except the AMS, which, in my limited experience, seems to be populated by,
and perhaps even more important, in the charge of, people who Get It.

~~~
semi-extrinsic
I agree. As I said, I really should get https working. I also really should
finish a bunch of papers in various stages of completion and review, etc. This
lets me decide whether the new Chrome behaviour rearranges my priorities or
not.

------
dk8996
I love what Amazon did with ACM, free certificates that are really easy to
set-up but they don't support EV yet.

------
technion
Well this got me reading about CertSimple.

    
    
       Never requires a lawyer or an accountant to fill in paperwork. 
    

I have a lot of hate for the whole concept of EV. Not only because it's
theatre, but because I have to involve my accountant, and my legal team every
time I buy one from Comodo. It's like pulling teeth.

I'm going to give your team a try.

------
woliveirajr
Will this warning catch insecure pages which URL (or URI for pedantics,
whatever suits) begin with
[https://google.com/amp/..](https://google.com/amp/..). ? [1]

[1]
[https://news.ycombinator.com/item?id=12395092](https://news.ycombinator.com/item?id=12395092)

------
jeffehobbs
Article by "Mike MacCana, founder at CertSimple.". So, grain of salt.

~~~
nailer
Mike here. You can easily verify the current behavior by installing Chrome 53
on Windows or 52 on Mac.

Everything else is (eg, [https://www.chromium.org/Home/chromium-
security/marking-http...](https://www.chromium.org/Home/chromium-
security/marking-http-as-non-secure)) is directly linked in the post. There's
nothing you can't easily verify.

~~~
JadeNB
I think that jeffehobbs is suggesting that your call to action, rather than
the facts on which it is based, should be viewed with extra scrutiny because
of your affiliation.

------
davegoehrig
And I now refuse to support Chrome in all my apps and sites.

~~~
deadbunny
Something about cutting off your nose...

------
davegoehrig
I for one now refuse to support Chrome on all of my apps and sites. Their
browser is broken by design, and is working against a free and open web.

~~~
JoshTriplett
Working towards making all connections secure is "working against a free and
open web"? Insecure HTTP is "a free and open web"?

I for one look forward to insecure HTTP becoming extinct.

------
rebelde
I really prefer to do what is best for my users: fast loading simple pages for
users with slow connections on the other side of the world. (So, HTTP, not
HTTPS.) But there is no sense fighting the powers that be.

EDIT: Thanks for the down votes! Unpopular thoughts like mine should be
discouraged. Groupthink is best!

~~~
Walkman
[https://istlsfastyet.com/](https://istlsfastyet.com/)

~~~
kuschku
That applies to modern hardware and modern infrastructue – not to people in
third world countries on decade old cheap hardware with barely working
networks.

~~~
Dylan16807
Decade old hardware can do TLS fine. Barely working networks can do TLS just
as well as they can do non-TLS.

~~~
kuschku
Barely working networks tend to use custom caching systems where TLS accesses
often taken dozens of times longer.

~~~
Dylan16807
They can always make the proxy explicit.

