
Chrome 68 will mark all HTTP sites as “not secure” - el_duderino
https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html
======
jgowdy
The people who are pushing back against HTTPS really bug me to be honest. They
say silly things like “I don’t care if people see most of my web traffic like
when I’m browsing memes.”

That presumes that the ONLY goal of HTTPS is to hide the information
transferred. However, you have to recognize the fact that you run JITed code
from these sites. And we have active examples of third parties (ISPs, WiFi
providers) inject code into your web traffic. When browsing the web with HTTP
you are downloading remote code, JITing it, and running it on every site you
visit if you aren’t 100% noscript with no HTTP exceptions. You have no way of
knowing where that code actually came from.

Now consider that things like Meltdown and Spectre have JavaScript PoCs. How
is this controversial?

~~~
aurelian15
My primary concern are local servers ‒ which of course, are irrelevant if you
are a centralised service provider such as Google.

To provide some context, I'm currently working on a web application where the
server is intended to be running inside a home network (where the server
requires zero configuration by the user). As of now, some of the JS APIs I'm
using are only available if the site is running in a secure context, so the
server _has_ to serve the application using HTTPS, otherwise some
functionality won't be available. However, it is impossible to obtain a valid
TLS certificate for this local connection -- I don't even know the hostname of
my server, and IP based certificates aren't a thing. So basically, to get a
"green lock symbol" in the browser, the server would have to generate a random
CA and get the user to install it, which comes with its own severe security
risks and is not an option.

So my current plan is to have a dual-stack HTTP/HTTPS server, which on first
startup generates a random, self-issued certificate. When the server is first
accessed using HTTP, the client automatically tries to obtain some resources
via HTTPS. If this succeeds, the user is redirected to the HTTPS variant. If
it fails due to a certificate error, the user is presented with a friendly
screen telling her that upon clicking "next" an ugly error message will
appear, and that this is totally fine. Oh, and here's how to permanently store
an exception in your browser.

Still, the app will forever be marked as insecure. Although it isn't. It is
trivial for the user to verify that the connection _is_ secure by comparing
the certificate fingerprint with that displayed by the server program she just
started.

This sucks. It just seems that Google and co don't care about people running
their own decentralised infrastructure; and marking your own local servers as
"insecure" does definitively not help.

~~~
madez
You also could stop misusing the browser as an application frontend, and write
a proper frontend with a cross-platform toolkit, and distribute that.

I don't understand why developers so often choose the browser as a frontend.
Are there better rationales besides having at least some frontend for tyrant-
controlled devices like iOS'es, and just using the skills one already has?

For the first, just tell the people to get proper devices.

Because of the second, I see schooling efforts for JavaScript by the tech
giants so negatively. It leads to masses of people using JavaScript where it
shouldn't be.

~~~
mkohlmyr
> just tell the people to get proper devices

That seems like a great way to have no users.

An incredibly obvious reason would be that it is the largest application
delivery platform with the highest level of user familiarity and comfort.

If you compare two services where one of them offers you a direct login to the
app and the other offers you a 200MB download, most people will choose to log
in to a website. It's a better user experience. Especially for things that
will see infrequent use.

~~~
madez
If you _only_ care about the number of users, then I see a point. However, at
least for non-commercial programs, why care at all about the number of users?

The scenario you are drawing is not a proper comparison. There is no reason
why a native toolkit couldn't support rendering the program before it's fully
loaded, so I see no reason a native program would need more data transfer
upfront than a JavaScript one. Though I think too that being prompted to
download the program, then install it and find the way to run it can be
cumbersome, but the solution to this is to not do it this way. Why not
integrate with the native way to obtain applications and make it transparent
and convenient for the user?

After all, I think there might be fundamentally different goals when
developing a software, and that explains the difference. If one has accepted
advertisement-based financing of projects, then them and I would probably
disagree in many ways. I think users devices must only and exclusively work
for the user.

------
gmueckl
As long as this is just a non-obnoxious warning that translates http to
something in plain English I can sort of live with it. But as soon as browsers
start to inject security warnings, this is going to be very, very bad.

Our company manufactures devices for use in labs and industrial processes.
They need complex user interfaces and there is a push to move to HTTP, HTML
and JS to implement them with the device as the web server. The devices are
usually installed in a controlled, isolated internal networks.

Our clients run these devices for a long time. 20 or 30 years are not unheard
of. They also do not update them if there is no malfunction (they work and our
clients love it that way).

Now how the hell do we create a webserver that will work reliably for the next
30 years if we have to embed SSL certificates with built-in expiration dates
in the range of 1 to 3 years?

~~~
onion2k
_how the hell do we create a webserver that will work reliably for the next 30
years if we have to embed SSL certificates with built-in expiration dates in
the range of 1 to 3 years_

If there's a requirement that your code needs to run for 30 years without an
update then current web technology is probably the wrong choice.

~~~
bpizzi
Sadly it's more of a 'wrong' requirement from the customer. Today's entreprise
customers expect things to Just Work. They say 'just sell us a goddam
appliance, we'll point a browser at it and we'll call it a day!'. I'm quoting
real customers' documents here: 'it's should be as easy as Apple'. We've done
it to ourselves.

~~~
egwor
I expect things to just work and I expect them to work for a reasonable
lifespan. I often think that a piece of software ought to live as long as a
car, and for something commercially created (e.g. costs as much as a house)
then it ought to last at least a generation (30years).

I don't think I'm being unreasonable here. In a closed system this should be
doable.

edit: one of the reasons I think this is because we are supposed to be
engineers, and other engineering disciplines do it (and their disciplines
involve computes too). Consider jets and boats.

~~~
paublyrne
Jets, boats, and cars all require regular servicing. Parts need fixing and
updating and it isn't one and done. The allegory isn't exactly the same as
software updates but the allegory of software systems to cars isn't exact
either.

~~~
gmueckl
Our devices do not normally need servicing. They do age, but this is
compensated.

------
Klathmon
I'm glad this is happening, although I'm more excited for the day when they
start very obviously marking password input fields as "NOT SECURE" when they
are used on HTTP sites. Although I am genuinely surprised how much Google and
others like Mozilla have had to drag many site owners kicking and screaming
into HTTPS. I never would have imagined that end-to-end encryption by default
would be consitered "controversial".

Also, those HTTPS numbers are amazing!

* Over 68% of Chrome traffic on both Android and Windows is now protected

* Over 78% of Chrome traffic on both Chrome OS and Mac is now protected

* 81 of the top 100 sites on the web use HTTPS by default

~~~
m_eiman
Required maintenance for a simple, static http site: none.

Required maintenance for a simple, static https site: configure let’s encrypt
and keep the cron job running.

Big difference? Not for some, but it sure is something that offers very little
value for very many site owners. Even the top 100 sites are only at 80% https
by default, and they do it for a living!

~~~
ef4
If you are running your own webserver even a static simple site has required
maintenance. You need to keep the server and OS patched. So adding a
letsencrypt cron job is not any worse than configuring something like Debian's
unattended-upgrades.

But I don't think most site owners should be doing even that much. They should
just pay for static hosting, which is cheap and ensures somebody else will
keep the server, os, and cert all safe.

~~~
1wheel
I added https to my static site last year and it has been a huge waste of
time.

ubuntu + nginx worked fine for years without much maintenance, but I've spent
so much time reconfiguring things when something breaks (and it is really
clear when something a renewal fails... thanks HSTS).

Things that used to be simple, like putting setting up a subdomain (need to
get a new cert and reconfigure the cron job now) or pointing at a websocket
(can't point directly at node since that's not secure, needs to pass through
nginx now) consistently take hours to do now.

I mostly do data analysis and front end work; mucking around in nginx config
files is something I would have been happy never experiencing. It sucks that
it's harder to host your own website now.

[https://pastebin.com/N2sbvULA](https://pastebin.com/N2sbvULA)

~~~
kelnos
I have nginx fronting around 15 different (very low traffic) websites (most
static, a few python), all of which have Let's Encrypt certs. The required
additions to the nginx conf were minimal and easy. Adding a new subdomain is
trivial. Fetching the initial certificate from Let's Encrypt is a short, easy
command line. And "sudo certbot renew; sudo /etc/init.d/nginx reload" in a
cron job keeps the certs up to date (the "renew" command is smart enough to go
through the list of certs you have and renew them all).

It's really hard to imagine it getting much easier.

~~~
andrewaylett
Try `certbot renew --post-hook "/etc/init.d/nginx reload`, which will only
reload nginx if at least one certificate changed :).

------
kstrauser
Fine, as long as they don't eventually make it difficult or impossible to
ignore the warnings (as they've done with SSL sites with invalid certs). I
have numerous devices with web interfaces that are 100% internal to my network
and not reachable from the open Internet, but Chrome still refuses to let me
access them (side note: thanks, Firefox, for respecting my decision as a
user!). I can envision a near future where Chrome treats HTTP sites the same
way.

~~~
olympus
Can you self-sign a certificate from the internal server and install it as
trusted on the work computers? Or does Chrome only trust certificates that
Google trusts?

~~~
ams6110
Not sure about Chrome, but you can absolutely install a local CA into Firefox.

~~~
cheeze
You definitely can in Chrome. Tons of corporations need the ability to trust
their internal PKI.

------
baggachipz
One small annoyance/drawback with everything moving to https: I travel a fair
bit, and hotel wifi usually relies on users connecting to their AP and then
using a DNS-based redirect to send the user to the login page. That only
happens when on http, as https sites which are redirected get the MITM warning
from the browser. I used to be able to just type in "google.com" in the
address bar and be redirected accordingly; nowadays I struggle to remember a
site I use which isn't https. Looking up the gateway address is kind of a pain
too.

~~~
CiPHPerCoder
[http://neverssl.com/](http://neverssl.com/)

~~~
racer-v
I use the neverssl.com trick and I worry: if browsers stop supporting plan
HTTP, doesn't it mean this won't work anymore?

~~~
dx034
No, worst case you'll see a security warning. Or chrome will add an exception
for such a site. This is a well known problem that I'm sure will be addressed.
But with the current state of the web (~20% unencrypted) it's not really an
issue yet.

~~~
gpvos
If it were addressed in a way that would break captive portals forever, so
much the better.

------
cryo
This _totally sucks_ for web based services and sites which don't have a (user
friendly) chance to use HTTPS.

Think of LAN only IoT devices which aren't proxy through a external company
site, have no domain, are accessed through (local area network IP) and maybe
run in non internet environment.

I wish there was a solution for web based encryption for this application
domain and browser vendors start to think out of their internet only box. ...
same goes for service workers.

~~~
stouset
Unfortunately, this is a problem that will never go away, no matter how slowly
and gracefully we transition. There is no alternative that allows these
devices to continue to operate without friction that doesn’t _also_ enable
current device manufacturers to kick the can down the road by releasing new
HTTP-only devices.

If we want to keep making the web a safer place, these kinds of cutoffs have
to happen. Infinite backward compatibility simply holds everyone back for the
sake of decreasingly-relevant devices and irresponsible manufacturers of new
hardware and the customers who purchase their products.

The sooner we get to universal HTTPS the better.

~~~
notatoad
so the solution to the warning is to make your offline IoT devices secure, but
how do you actually do that? i have an IoT product that runs a web server and
needs to be accessible by users when the internet connection isn't available.
how do I enable HTTPS on it? (this is not a hypothetical. it's a problem i
actually need to solve)

as far as i can tell, my options are:

\- install a self-signed cert on the device and force my users to click
through all the warnings chrome throws up about untrusted certs

\- create my own CA cert and sign the cert with that, and convince the user to
install my CA cert as a trusted cert (which is not possible on iOS)

\- get a cert signed by a trusted authority, and get the user to add an entry
to their /etc/hosts file that maps the domain the cert is valid for whatever
address the device is assigned

\- distrubute a native (electron?) app that interfaces with my device and
trusts my cert, and disallow direct browser access.

\- find some sketchy SSL issuer who is willing to issue certs for *.local
domains and run an mDNS resolver on my device

\- Use HTTP instead of HTTPS and the only downside is a little badge in the
address bar saying "not secure"

I'd love to have HTTPS everywhere, but i honestly don't know how to make it
happen.

~~~
namelost
> \- distrubute a native (electron?) app that interfaces with my device and
> trusts my cert, and disallow direct browser access.

This is the most secure choice, using something like websockets to transfer
data only.

Unless your product is completely offline and _never_ connected to the
internet, I don't think an IoT device that runs a web server is ever a good
idea. All it takes is one successful remote attack, and soon your users could
be installing ransomware at the device's direction!

Don't serve HTML/JS from a device that you can't physically pull the plug on.

~~~
quickthrower2
> Don't serve HTML/JS from a device that you can't physically pull the plug
> on.

Or virtually pull the plug, in the case of cloud hosted sites.

------
jasonkester
Terrible news.

So much work for so many people to update so many old websites that will see
absolutely zero benefit from serving content via ssl.

I have an old travel blogging site with a few hundred thousand posts in read
only mode. Thinking about how much work it was to upgrade my other sites to
https, chase down and work around every http request in the code base,
purchase and install certs for silly things like cloudfront that you wouldn't
think would suck away two days of your life.

I'll probably just let the site die in July. It doesn't make money, so it's
going to be a tough decision whether to dump thousands of dollars of otherwise
billable time into upgrading it to accommodate google's silly whim.

~~~
ancarda
It makes me a bit sad to hear you are distressed from this news. Would you
like some help setting up SSL? We could go over Certbot & Let's Encrypt, as
well as provide some advice on things like HSTS, Mixed Content, etc...

My email address is in my profile. I'm happy to help you however I can. I may
not be able to make any code-level changes, but there may not be much work
that needs to be done.

Edit: I just saw your comment
[https://news.ycombinator.com/item?id=16338576](https://news.ycombinator.com/item?id=16338576)
\-- I understand there's potentially a lot of one-time work, but it could be
done very gradually, and with this announcement, I think CDNs and widget
makers would adopt SSL as well. Once the site does support SSL, you can make
SSL-related upgrades (like disabling old ciphers or protocol versions) without
much disruption.

~~~
staticelf
Let's encrypt doesn't really work for all hosting solutions. So a lot of sites
still have to purchase an expensive cert.

~~~
ancarda
Could you help me understand scenarios where Let's Encrypt and CloudFlare SSL
won't suffice? They have, e.g. added wildcard support now, so that's another
angle covered.

~~~
staticelf
I have sites on Azure and I could add CloudFlare SSL, but it's some work to
make that happen and I will have to do it now for all my static sites that
absolutely do not need TLS (no forms, no cookies, no javascript).

Or else I have to pay for a cert, a cert is still like $10-$20 per year, per
site so that is a lot of money if you have a lot of static sites compared to
what the site costs to host (which is near-to-nothing).

And for other shared hosting solutions I'm not really sure if it's possible to
implement CloudFlare SSL (I have never implemented it so I'm not really sure
what's required)? Why I don't want Cloudflare is because that is adding a
third party just because google said I must or I will get punished for it.

~~~
ancarda
Hopefully Azure will implement some solution to provide SSL for free. I
suspect with this announcement, free SSL may get more attention on hosting
providers. There's already several tickets open on the Azure feedback website:
[https://feedback.azure.com/forums/170024-additional-
services...](https://feedback.azure.com/forums/170024-additional-
services/suggestions/16957756-add-integration-with-let-s-encrypt) \-- this
problem may go away mostly by itself if it continues to get easier every year.

Google isn't making you do anything, merely notifying users that the
connection to your website is not secure.

~~~
staticelf
Yes it may, but it can still take a lot of time before it's one click. These
tickets have existed since Let's Encrypt was released.

Well they are indirect forcing me through their domination over the web, which
I don't like.

------
lsc36
Firefox will eventually follow up as well:

"To continue to promote the use of HTTPS and properly convey the risks to
users, Firefox will eventually display the struck-through lock icon for all
pages that don’t use HTTPS, to make clear that they are not secure." [1]

[1]
[https://blog.mozilla.org/security/2017/01/20/communicating-t...](https://blog.mozilla.org/security/2017/01/20/communicating-
the-dangers-of-non-secure-http/)

------
styfle
> Over 68% of Chrome traffic on both Android and Windows is now protected

> Over 78% of Chrome traffic on both Chrome OS and Mac is now protected

This is an interesting way to report HTTPS usage.

Why are Android and Windows grouped together and why are Chrome OS and Mac OS
grouped together?

~~~
fooey
claiming 68% of traffic is https is far different from claiming 68% of sites
are https too

I suspect the vast majority of sites are still not https, but the big sites
are which skews that number

~~~
dingo_bat
That's ok but what the OP was getting at is the strange OS grouping.

------
megous
I predict "Not secure" will lose meaning for many people. There's just too
many non-https websites. Traffic is not a relevant metric for this. Tell me
how many of the websites that a user visits are http.

It's easy:

sqlite3 places.sqlite 'select url from moz_places' | cut -d / -f 1,3 | sort |
uniq | cut -d : -f 1 | sort | uniq -c

    
    
       4915 http
       4227 https

~~~
Ajedi32
According to Google's own statistics, even Android users now spend 70% of
their time on HTTPS sites:
[https://transparencyreport.google.com/https/overview](https://transparencyreport.google.com/https/overview)

For Windows users, it's more like 80%, and 85% for Mac users. And those
numbers went up ~10% over just the last year.

~~~
megous
That matches my personal numbers for page views too, but TLS is site specific
and not page specific, and it is deployed on small minority of websites on the
internet (20-25% of top 1mil.), so my point still holds.

I may spend 80% of my time (whatever that means) on a few HTTPS websites, but
I also spend 20% of my time browsing much larger proportion of non-https
websites.

So the warning will be popping out a lot and will soon become a thing to
ignore.

------
turrini
It's very simple: with HTTP, ISPs can see your traffic and direct target ads
to you. If everything is under HTTPS, they will need to resort to Google for
ads since almost everyone uses Google Search Engine and it's products.

~~~
cup-of-tea
Yep. This is about Google maintaining their monopoly on your data and nothing
else.

------
csjr
If I understand correctly, Chrome shows that "Secure" label on sites using
HTTPS.

What bothers me is that non technical users will start to trust the same
"Secure" label.

On phishing, what stops someone from registering a shady domain and securing
it w/ Lets Encrypt?

~~~
Something1234
Chrome should have 3 levels of security.

* HTTP (Red Box and Complaining)

* HTTPS w/ Let's Encrypt (No compliants, but no true secure lock.)

* HTTPS w/ a paid certificate (True magical green box)

In fact I think this should apply to all browsers. This might not deal with
all of the issues, but it would be a good start. Feel free to point out where
I'm wrong.

~~~
firloop
What makes Let's Encrypt less secure than a paid certificate? Or do you mean
EV certs for the "magical green box"?

~~~
cheeze
Even EV certs don't really matter. Case in point:
[https://stripe.ian.sh/](https://stripe.ian.sh/)

Let's Encrypt isn't the problem here. Expecting all CAs to properly verify
what is and isn't a phishing website is unreasonable IMO. It just won't
happen. Smaller CAs have hundreds of thousands of certs... it's just not
possible.

The real issue is that a cert only says "Your communication between this site
is encrypted, and you're speaking to the owner of this certificate" (Assuming
it hadn't been compromised.) Certs don't make any guarantee that the person
you are talking to is a good guy, nor that they aren't trying to trick you
into giving your password to them.

------
ad_hominem
Predicting a noticeable bump in Cloudflare users around July when people need
a quick way to make their sites "secure"

~~~
josefresco
Thankfully this is an option, and one we may have to take for our clients
hosted with companies that do not make this process easy (or cheap)

------
hcurtiss
It occurs to me that Google has some incentive to do this. Ad blocking is much
more difficult with https and requires an ordinary user inject a certificate
of dubious origin/security.

~~~
craftyguy
> Ad blocking is much more difficult with https and requires an ordinary user
> inject a certificate of dubious origin/security.

What do you mean? I can see how this might apply if you're trying to MITM your
https requests and ad block them that way, but a browser (or its plugin) can
simply choose not to display an element on the page without doing that..
right?

~~~
kuschku
On Android, since 8.0, users can not override the CAs that applications use
anymore.

With SSL everywhere, you can't use a VPN to intercept anymore, as you can't
get your own CA into the truststore.

This means ad blocking in apps is now impossible.

Okay, because everyone just downvotes this without reason, here's Google's
official Android Dev blog stating exactly the same I just did:
[https://android-developers.googleblog.com/2016/07/changes-
to...](https://android-developers.googleblog.com/2016/07/changes-to-trusted-
certificate.html)

~~~
craftyguy
Um, you can still import custom SSL certs into Android 8.0's trust store. I do
this for connecting to my OpenVPN instance.

~~~
kuschku
You can import into the User CA store, not into the system CA store.

Since 8.0 these are separate, apps have to explicitly opt in to using user CA
certs as well.

For example, Google's News app doesn't, and as result you can't ad block on
the articles it shows.

~~~
craftyguy
I see. Thanks for the clarification.

------
LoSboccacc
Now that we're done conflating encryption with certificates and cheapened the
meaning of certificate trust, what are we going to use to establish which
entity actually controls the domain name we are pointed to?

------
makecheck
Generally I hate these warnings because they are extremely stubborn while not
really telling the user what could fix the problem. They also don’t explain
why the error might show up today when everything was fine yesterday.

I’d much prefer a message like: “There is no way to verify that this site
really is who it claims to be (possibly due to an expiration date, as sites
must periodically renew their validations). The owner of the real site can
resolve this error by using certification services such as LetsEncrypt. A
secure connection is not possible until the site renews its validation.”.

~~~
tptacek
The user in this case is a random web browser piloted by a non-technical
person. It doesn't make any sense to try to arm them with technical solutions
to the problem; that's the site owner's job.

~~~
CiPHPerCoder
I foresee site owners complaining, and then this bit of history being
repeated: [https://arstechnica.com/information-
technology/2017/03/firef...](https://arstechnica.com/information-
technology/2017/03/firefox-gets-complaint-for-labeling-unencrypted-login-page-
insecure/)

~~~
ancarda
What I find really interesting is the website in question,
oilandgasinternational.com, now has SSL on by default now; it'll redirect you
from any page if accessed over HTTP. Given that, perhaps we should just let
them complain? It seems to raise awareness over the need for SSL.

------
AnabeeKnox
Ironically, the thing stopping me moving my website to HTTPS is Google
themselves!

There is no clear and unambiguous way to move my website from HTTP to HTTPS
without GUARANTEEING that my search index rankings will not fall in the Google
search index. This is because Google treat the HTTP and HTTPS versions of the
same resource as separate pages.

Until they fix this, I'm sticking with HTTP. A drop in our search rankings
would be a catastrophe.

~~~
setr
Couldn't you have both, and wait till the https version starts to approach
parity with the original? I'm imagining google would favor https over http in
ranking, so over time it should rise

~~~
AnabeeKnox
2 separate pages with the same content is penalised by Google. They are quite
clear about that. I will switch on HTTPS tomorrow if Google make it so that a
protocol change does not affect search indexing. My business depends on this.
Do a Google search and see all the people whose websites have been demolished
by dropping out of the Google rankings after implementing HTTPS. Absurd!

~~~
Confiks
There are a few well documented methods to counter that penalty:
[https://support.google.com/webmasters/answer/139066?hl=en](https://support.google.com/webmasters/answer/139066?hl=en).
The easiest method is probably to configure your webserver to start sending
'rel=canonical' in a Link HTTP header, but it can also be done with a meta-
tag.

------
alangpierce
Note that Chrome already describes HTTP sites as "not secure", this change
just makes it more prominent.

If you click the little circled "i" on any HTTP site, it shows this messsage:

> Your connection to this site is not secure

> You should not enter any sensitive information on this site (for example,
> passwords or credit cards), because it could be stolen by attackers.

------
msie
While were at it: why not define a new Javascript with just the "Good Parts"
and then refuse to run old Javascript?

~~~
bastawhiz
In a way, that's already happening with wasm. I can't wait for a major
language VM to be compiled to WASM and hosted on a common CDN (so it's likely
to be cached). It's not such a pipe dream to imagine running high performance
Python 3 or Java without the overhead of asm.js on the interpreter, but with
the ease of running old fashioned JS.

------
karmakaze
This will reduce the diversity of information exchanged, as does ranking
secure sites higher in search results. Privacy and security are worthy goals,
but I do feel for those who are attempting to publish free information on
personally run sites. The easiest thing to do is put Cloudflare in front of
them which also has other benefits.

~~~
karmakaze
Downvoted without comment. I suppose certain topics on HN are only accepted to
have a one-sided view.

------
Waterluvian
I have only ever made internal web apps that don't live on the internet. Where
do I begin for an idiot's guide to switching to HTTPS? I want the shortest
path to switching nginx over and getting an SSL cert. I think that's all I
need to worry about?

~~~
ReverseCold
[https://www.digitalocean.com/community/tutorials/how-to-
secu...](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-
with-let-s-encrypt-on-ubuntu-16-04)

This is the easiest tutorial I've found. It's 99% copy/paste with sane
defaults.

~~~
Waterluvian
Wonderful! Thank you for taking the time to share.

------
cocktailpeanuts
Probably will be a very unpopular opinion, but while I appreciate that HTTPS
encrypts traffic, I do think a mandatory HTTPS usage comes with a cost, not so
much mentioned in this thread. Here's what I think:

I think the mandatory usage of HTTPS centralizes the already centralized web
even further. HTTPS itself is secure theoretically, but at the same time it
relies on:

1\. Trust in browser vendors: Basically the way HTTPS works currently is that
all browsers have "trusted certificate sources" hardcoded. And there aren't
that many browsers out there with meaningful market share--Chrome, Firefox,
Edge, Safari, and that's about it (One may even say it's pretty much Chrome
all the way, with rest of them trailing far back)

2\. Trust in the certificate authorities: The way HTTPS works relies on
"trusted certificate sources", like verisign. This was already way too
centralized, but it will become even more so. I'm guessing eventually
companies like Google or Apple will start acting as generic certificate
authorities (as a verisign competitor) unless regulators cut in.

If you think about the implication of all this, the more we move towards an
"HTTPS first world", the more power these entities will have and the more
damage it will cause when one of them gets compromised.

Note that the web has never been forced to use HTTPS throughout its entire
history, so we have no idea how this will play out and I'm just speculating
based on my knowledge. HTTPS itself is secure, but as a lot of you know, most
dangerous hacks come not from exploiting tech flaws, but by exploiting the
weakest link in the value chain--the human factor. And when things become this
centralized, the "human factor risk" becomes larger and larger. We have never
before had a world where HTTPS was forced, so it's not easy to just visualize
this or predict what will happen, but I can imagine there can be many ways the
"The entire web can go down one day" because of the extreme centralization,
and when I say "the entire web" I mean it literally. One day, some hacker will
take advantage of the extremely centralized landscape of the web and probably
be able to compromise the ENTIRE web, and you won't be able to browse the web
all day, until Apple, Mozilla, or Google releases a security update. This will
be way worse than what we've experienced with S3 going down, because it will
obsolete security measures of ALL web browsers in one fell swoop.

Another thing I don't like about this "forced HTTPS" is that mandatory HTTPS
makes it difficult to publish stuff to the web. You must either deploy your
own Letsencrypt to run your website, or if it's too much of a hassle (which
would be the case for most people, even developers), just run your website on
a service provider that already has HTTPS.

This means people will rather publish their blogs on sites like medium.com
rather than running their own wordpress server, or even a ghost blog.

And when this happens, where do you think people will flock to? Most people
will flock to platforms that are most stable and have high reputation, such as
Google, Facebook, etc., which will centralize the web even further.

I may sound like a tin foil hat conspiracy theory guy but I just wanted to
share my thought since everyone seems to think "You must be fucking crazy
moron to think that there can be some drawbacks with a forced HTTPS future".
Google does have every interest to move the web this direction because they
already own the "centralized web", and the more centralized it becomes the
more they benefit.

Just to reiterate, I do think HTTPS is great, and user privacy should be
respected. I am just providing an alternative opinion.

~~~
bfred_it
You trust browser vendors pretty hard already since you're routing ALL of your
information through them.

> probably be able to compromise the ENTIRE web

I don't buy it. HTTPS reduces what you can do, not increase it. At most it can
give a false sense of security but that's about it.

~~~
cocktailpeanuts
> You trust browser vendors pretty hard already since you're routing ALL of
> your information through them.

Yes, but just because we already do doesn't mean I shouldn't have rights to
hate the reality even more.

> I don't buy it. HTTPS reduces what you can do, not increase it. At most it
> can give a false sense of security but that's about it.

That's true. I wasn't arguing about what HTTPS can or cannot do, I was arguing
about how HTTPS is centralized. No matter how safe a piece of technology is,
the attack vector increases the more it gets centralized. I've never been a
fan of the reality we live in--where the core protocol is elegantly
decentralized yet we still end up with a centralized trust to be safe.

I think it's ridiculous that every existing website in the world needs to have
a certificate authorized by a small number of entities.

Also another point I'm making is that people look at this move by Google and
think "wow Google is really advancing the web!" but don't see their motivation
behind it.

1\. Google owns the "open web".

2\. Enforcing HTTPS will make sure things become more centralized, which will
make it easier for google to keep controlling the "open web".

3\. Google profits.

I know this sounds like a conspiracy theory, but I'm just stating the facts. I
can't think of any other scenario when HTTPS gets more and more traction. It's
important to distinguish this problem from the actual problem HTTPS is
solving, because I do think HTTPS itself is great.

------
donarb
I can see GoDaddy now rubbing their hands with glee as they ponder the
prospect of selling overpriced server certificates to unaware website owners.
No way they'll push a Let's Encrypt solution.

~~~
josefresco
This. I already have clients purchasing SSL certificates from GoDaddy due to
their aggressive FUD-marketing. To make matters even worse, GD does not in any
way assist in the installation, or "activated" of the SSL cert.

~~~
LambdaComplex
I just checked GoDaddy's prices, out of curiosity. "Plans starting at
$59.99/yr". For comparison, you can get a Comodo PositiveSSL cert for about
$10/yr.

------
ridiculous_fish
What is the modern simple and cheap way to set up a static HTTPS site with a
custom domain? With HTTP this was doable with S3 for pennies a month; is
S3+CloudFlare now the current price leader?

~~~
ridiculous_fish
Replying to myself. It's distressing how many of the options assume command
line competence.

It used to be that graphic designers, photographers, families, etc. could set
up a simple site with a shared host, an FTP client, and a bit of HTML. Now
requiring HTTPS will push this further out of reach.

This content is now funneled into either managed platforms, either free ones
that monetize it (Medium, Flickr, Facebook, etc.) or more expensive higher-
touch services (SquareSpace, Wix, etc). The de-democratization of the web
continues.

~~~
jacobparker
Whatever company offering you FTP access and hosting those files for you over
HTTP should be setting up HTTPS for you automatically without any extra input
from you. That’s why all the instructions assume command-line competence:
designers are not the target audience; sys-admins are.

If your host hasn’t caught up with the times yet it’s very straight-forward to
get this for free (along with other benefits) from cloudflare with a few
clicks.

This is misinformed FUD.

------
to3m
Is there a good reason to require https for localhost?

~~~
valleyer
Yes: the browser is not in control of resolving "localhost" to 127.0.0.1, nor
is it in control of resolving 127.0.0.1 to the loopback interface. These are
details the OS is in charge of, not the browser. So the browser can't know
that [http://localhost/](http://localhost/) is "secure".

------
nannePOPI
Looks like defamation to me. Just because a website doesn't have https doesn't
mean it not secure. It's not secure for some activities, and if the browser
marks the whole page as not secure, it's defamation.

I don't care if the web would be better with all site having https. Chrome is
saying something defamatory about websites without https.

------
staticelf
I do not like this. I host a website on my dads shop which is not TLS-secured.
Why? It's just a one page static site with some info about his store.

There is simply no need to encrypt that. I do not store cookies or host any
fishy javascript.

Now I basically have to buy a certificate for that small site that has like 60
visitors a week? Not really nice.

------
siteshwar
This is going to be interesting. I believe instead of pushing everyone to use
https this will cause an average user to start ignoring the security warning.
I see the security warning as a way to reflect what's insecure and not a
catalyst to move to more secure methods.

------
Pxtl
Maybe Android Chrome could be worked on to not poop the bed quite so
thoroughly when faced with a captive portal, then, if they're trying to get
everybody onto https. Because the interaction between https, Android, and
captive portals is just not a good scene.

------
dawnerd
As long as it doesn't break local development again like their forcing of
https on *.dev even when locally hostfiled. Funny enough they suggest using
.test which is fine, except you cant use .test as a callback url when setting
up googles oauth... fail!

------
thinkloop
> and it unlocks performance improvements

I thought https added performance overhead, where does it improve it?

~~~
CiPHPerCoder
Nope.

[http://www.httpvshttps.com](http://www.httpvshttps.com)

[https://www.httpvshttps.com](https://www.httpvshttps.com)

See also: [https://istlsfastyet.com](https://istlsfastyet.com)

~~~
tptacek
This is a pretty bogus comparison; it's HTTP/2 versus HTTP/1.1.

~~~
CiPHPerCoder
It's HTTP/2 over TLS versus HTTP/1.1 without TLS.

~~~
tptacek
Yes. The performance benefit isn't really TLS.

~~~
CiPHPerCoder
Given that "currently no browser supports HTTP/2 unencrypted" they're
inseparable in the real world.

[https://http2.github.io/faq/#does-http2-require-
encryption](https://http2.github.io/faq/#does-http2-require-encryption)

~~~
tptacek
Right, but enabling TLS on an HTTP/1.1 site isn't going to generate that
performance improvement. It's a bogus comparison.

~~~
CiPHPerCoder
Oh, I see what you mean. The relationship doesn't work both ways, and the
benchmark might lead one to believe it does.

~~~
tokenizerrr
So it's a http2 vs http1 benchmark. Not a http vs https benchmark?

~~~
CiPHPerCoder
Right. HTTP/2 is only available with TLS, due to browser policies, so it
necessarily requires TLS.

This means you need HTTPS if you want the performance wins of HTTP/2.

This doesn't mean that HTTPS is a performance win if you're still using
HTTP/1.1. However, the "performance overhead" for TLS is negligible in
practice.

------
tokenizerrr
I don't understand what is insecure about
[http://example.com](http://example.com)? It's a simple static site which does
not allow user input.

~~~
quotheth
I'll assume you intended to write 'insecure'.

I'd say the main issue is that anyone between you and that website can inject
scripts into the site in order to phish/ exploit you.

~~~
tokenizerrr
That's not a security issue if the site doesn't ask for user input, though.

~~~
Ajedi32
Since the other examples don't appear to have convinced you, how about this
one: [https://samy.pl/poisontap/](https://samy.pl/poisontap/)

Visit a single HTTP page while that's plugged in and it'll trigger an exploit
that siphons all non-secure-flagged cookies off of every popular site that
doesn't use HSTS (including the config pages of insecure routers on your LAN),
and installs a persistent backdoor in them so the attacker can continue
accessing data on those sites even after you're no longer being MITM'd. And
that's not even using any zero-days; it's just exploiting the inherent
vulnerabilities in non-secure HTTP.

(Note that while the site I linked talks about a USB device the same attack
can be carried out by any MITM, like a WiFi router or upstream ISP; it's not
exclusive to local attackers.)

~~~
gmueckl
Wait. This is a DHCP exploit on steroids. The MITM stuff is just possible
because operating systems accept bonkers DHCP replies.

~~~
Ajedi32
Yeah, the DHCP trick is what allows this particular method of conducting MITM
via USB.

All the stuff it does _after_ becoming a MITM though are things that any MITM
could do, regardless of how they became a MITM in the first place. (ARP
spoofing, operating or compromising a Wi-Fi access point, etc.)

------
yesenadam
Maybe someone could answer this for me, this discussion made me curious:

I have an old (2005) Mac, and my fav browser on it can't show https sites at
all 90%+ of the time - "Cannot Load, Secure Connection Failed". (like the
usual https sites linked to in HN stories) But it works fine with some https
sites, e.g. github https, youtube, this page.

What is it about those 'working' https sites that makes them different?
Hopefully that's enough info to answer that.

~~~
will_hughes
Probably because they support older SSL/TLS versions and/or cryptographic
ciphers.

~~~
yesenadam
Ohh thanks guys. Yeah, I had a vague feeling my SSL (whatever that is) was
outdated. So those sites just are more backwards-compatible. (Although github
isn't backwards-compatible enough to actually make an account. I tried.)

------
imhelpingu
How about I just give Google an SSH cert for my router and then they can
proactively monitor my entire network to make sure I'm not being MITM'ed.

------
imhelpingu
In ten years: "To further protect our passengers, Alphabet OS cars will no
longer be manually navigable down unmarked roads either."

------
atomicnumber1
I've a simple text blog hosted on GitHub pages. Github Pages doesn't allow
https for custom domains. Am I screwed?

~~~
pornel
No, GitHub is, because their product will become less attractive. Presumably
they'll fix it before the deadline.

------
usermac
I hate this. I too do a lot of off-line, never connected to the Internet
devices and I don't want the god Google telling my users they're "not secure".
My users _know_ they're on a self contained network.

------
bernardino
What are the best services out there today to translate a website from HTTP to
HTTPS? Particularly for a static website. I have previously used Cloudfare's
One-Click SSL free service, and I wasn't a big fan.

~~~
andscoop
Netlify free tier makes this as simple as it gets. (As long as your static
site generator is supported.)

------
nautilus12
What about simple static sites like blogs that dont have forms? Do we really
need to scare people away from our blogs and do we have to get an SSL cert for
them unecessarily?

~~~
SquareWheel
This has already been answered many times in this thread. Static sites are
still vulnerable to MITM attacks and snooping over the network. Using HTTPS
prevents this.

------
bartl
It's insane. I can't even access the web interface of my own printer any more,
because it's not https.

~~~
pas
No, it's not.

Yes, you can. Or if you can't, it's not because this change.

------
collyw
Google.es was on http until pretty recently. They change the rules now that
the finally put it on https.

------
greendestiny_re
I don't appreciate Google leveraging its market share to affect the mindset of
Chrome users.

~~~
dredmorbius
I bitch plenty about Google.

I'm happy with them trying to swing the needle to the side of good every once
in a while.

------
lousken
So the next thing is to disable all javascript loaded without https I hope.

------
amgin3
This is a really stupid move. There are plenty of instances where websites do
not need to use HTTPS, like simple static websites for small businesses that
do not collect personal user information. This is going to cause a lot of
confusion and outrage when it is implemented.

~~~
orangecat
_There are plenty of instances where websites do not need to use HTTPS_

No there aren't.

 _like simple static websites for small businesses that do not collect
personal user information_

Until the connection gets MITMed to return a fake login page.

~~~
gmueckl
What login page? Your typical company website just has a few pages of text
without any active elements. Forcing those to buy SSL certificates creates
just another artificial barrier to entry.

~~~
dredmorbius
Whatever login page the attacker wants to present. They're betting
percentages.

Google. Amazon. sac.mil. fed.gov. Whatevs.

------
krishani
I feel its a good thing. Sites can be made HTTPS with letsencrypt.

~~~
mmphosis
[https://letsencrypt.org/getting-started/](https://letsencrypt.org/getting-
started/)

With Shell Access and automatic renewal, what could possibly go wrong?

What happens to all the web sites if the Let's Encrypt certificates, one day,
expire?

~~~
dredmorbius
One of the things about well-known SPOFs is you try really, _really,_ REALLY
hard to make sure they don't F.

------
pleasecalllater
So suddenly people will see lots of websites as insecure. This way they will
stop paying attention to this warning, and when they will find a really
insecure website, they will just use it.

------
zerostar07
excessive. people will learn to ignore it

------
daveheq
Great, way to unnecessarily scare the undereducated masses. Even if they
learn, it's pointless, you can already see if it's secure.

------
vectorEQ
dick move. not all sites require https. it's easy to analyse in browser if a
site needs https and flag that as insecure, which they already do... :s

------
krick
Oh, if only there was an alternative to Google Chrome...

~~~
Something1234
There is. Firefox quantum is better than Chrome. The only thing is pushbullet
doesn't quite show popus correctly. It works with all the major streaming
services, and just feels better. Now if only client side window decoration
would come sooner, I want to ridded of that ugly title bar. I miss fedora's
firefox 57 build.

~~~
gmueckl
Has alsa support returned in the Linux build? Unless that is the case, Firefox
is absolutely useless to me.

~~~
richjdsmith
FF Quantum is in the latest Linux build, if that's what you mean. So I'm
assuming support has returned?

------
thresh
Welcome to the world where ad company tells you which sites you should look
at.

~~~
IncRnd
Welcome to the world that used to say not to talk to strangers and not to get
in stranger's cars.

Welcome to the brave new world where kids now summon strangers over the
internet in order to be driven in the stranger's car.

------
mroy_q

       the most interesting thing is that i know some Organ, not only inject code , may catch all Data !! if the web is not use a save version SSL, - .-

------
marknadal
HTTPS helps secure traffic between two parties, but that has nothing to do
with whether that end party (ahem, Google, or Equifax, ahem) is secure.

If we want real security we need to put cryptographic keys in P2P identities,
so users control end-to-end everything they do. No middleman can tamper with
it.

Obviously, I'm opinionated because we're working on solving this, and creating
a truly SECURE and DECENTRALIZED web: [http://hackernoon.com/so-you-want-to-
build-a-p2p-twitter-wit...](http://hackernoon.com/so-you-want-to-build-
a-p2p-twitter-with-e2e-encryption-f90505b2ff8) !

------
standardcitizen
I believe most people are seeing this wrong, there a few issues here.

1) Google is defining standards

This isn’t a drive for web masters and users, it’s our brother Google telling
us what’s good and what is bad. While they often fail on their own standards.
But hey, they can’t fail to pass, but you cant.. no expections besides big G.

2) We’re focusing on SSL

This isn’t about SSL, but’s about point one.

3) misleading

Reading some basic website that is just a random one page html site, doesn’t
care about it at all. This gives basic users( the ones we’re thinking are too
dumb to demand ssl) the idea this site is not safe.

Real users think two things;

Safe or not safe.. they don’t understand the gray and now we’re saying Not
Secure. A lot of people will think this is not safe, no one is around telling
them why this appears as no one in the real world reads this blog besides us.

