
Life Is About to Get Harder for Websites Without HTTPS - finnn
https://www.troyhunt.com/life-is-about-to-get-harder-for-websites-without-https/
======
userbinator
I'm most worried about the "long tail" of often very interesting, useful, and
rare content (a lot of it from a time when the Internet was far less
commercialised) that is unlikely to be hosted on HTTPS, and whose owner may
have even forgotten about or can't be bothered to do anything about, but still
serves a purpose for visitors. The "not secure" will drive a lot of visitors
away, and even lead to the death of many such sites.

Imagine someone who knew enough to set up a site on his own server a long time
ago and had left it alone ever since. Maybe he'd considered turning it off a
few times, but just couldn't be bothered to. Now he suddenly gets contacted by
a bunch of people telling him his site is "not secure". Keep in mind that he
and his visitors are largely not highly knowledgeable in exactly what that
means, or what to do about it. It could push him over the edge.

...and then there's things like
[http://www.homebrewcpu.com/](http://www.homebrewcpu.com/) which might never
have existed if HTTPS was strongly enforced all along.

I understand the security motivation, but I disagree _very very strongly_ with
these actions when it also means there's a high risk of destroying valuable
and unique, maybe even irreplaceable content. In general, I think that
security should not be the ultimate and only goal of society, contrary to what
seems the popular notion today. It somewhat reminds me of
[https://en.wikipedia.org/wiki/Slum_clearance](https://en.wikipedia.org/wiki/Slum_clearance)
.

(I also oppose the increased centralisation of authority/control that CAs and
enforced HTTPS will bring, but that's a rant for another time...)

~~~
Matt3o12_
Unfortunately, if the owner of the content is not interested in keeping this
site up, the content will be lost sooner or later anyways. He probably also
does not bother to install security updates and he will most likely stop
paying the bills at some point (domain name, hosting server, etc).

Installing LetsEncrypt is not much work and he might be motivated if a lot of
people ask him. If he is really not interested, it is probably best to archive
the website to a real archive and hope they make sure they content remains
available. Unfortunately this also means that the archive will no longer be
found on google or most other search engines. It is really a shame that there
is no work on google's side to make sure archived content can be found among
other search results.

~~~
mtberatwork
> Installing LetsEncrypt is not much work and he might be motivated if a lot
> of people ask him.

Assuming he has direct access to his server of course. If he's on a shared
host, he may not have the option to use LetsEncrypt, but may be forced to a
buy a certificate from the hosting company.

~~~
Matt3o12_
Many hosting companies already give out free LetsEncrypt certificates with the
ease of a checkbox. And those that don't will have plenty initiative to do so
because their customers will spam their support saying that their website is
not save anymore (and many will switch if the price for the certificate is
unreasonable).

~~~
tjoff
Vast majority of hosting companies don't offer LE.

------
y0ghur7_xxx
I hope lans are exluded? I'm scared that I will get security warnings
everywhere in my lan.

\- when I log in to my webcams it says the connection is not secure

\- when I log in on my nas it says the connection is not secure

\- when I log in on my router it says the connection is not secure

\- when I log in on the web interface of mythtv it says the connection is not
secure

\- when I log in on my self hosted gitea instance it says the connection is
not secure

\- when I log in to my self hosted nextcloud it says the connection is not
secure

\- when I log in to the configuration page of my toaster it says the
connection is not secure

All these things are on my lan, and on most things there is no way to install
a tls cert on them, nor would I want to do that.

Firefox already nags me that the connection is not secure when i enter a
username and a password in any of those sites.

~~~
dx034
I'd hope LAN is included because while you use some services at home, most
people will primarily use LAN services in public Wifis. It would be sensible
to have HTTPS used there. They'd have to come up with a new idea of login
pages (currently most systems MITM http requests) but otherwise it would make
sense if you get a warning when you access pages on your hotel/in-flight Wifi
without encryption.

~~~
y0ghur7_xxx
> most people will primarily use LAN services in public Wifis

[citation needed] - I would say most people will primarily use LAN services in
private home/corporate networks. But I don't have a citation either.

It's different use cases. Maybe one needs the warning, the other one not. But
putting the warning on everything and overload the user with them is not the
right solution.

Using a self signed CA is a pity, because installing it on every phone,
tablet, laptop, tv, pc, ... is cumbersome in a home network, and making all
hosts public and depending on an external CA for local resources to not get
scary warnings can not be the right solution either.

~~~
dx034
> [citation needed] - I would say most people will primarily use LAN services
> in private home/corporate networks. But I don't have a citation either.

Sorry I don't have a citation here. But looking at my coworkers and family,
none of them uses services in their home LAN. Most won't even know how to
access the router.

On the other hand it's very common to use Wifi in public transport (at least
here in London for the tube), airports, trains and hotels. Few people consider
security when using these hotspots, making sure that SSL is enabled for all
pages would be an improvement.

~~~
criddell
> none of them uses services in their home LAN

They don't have printers? They don't connect to a NAT router before their
cable modem? They never tether their computer to their phone? Their DVR
doesn't have an app to control it? None of them have their receiver connected
to their iTunes library?

~~~
jdboyd
While quite a few users will use services on their home lan, contrary to the
parent posters statement, I believe the majority of users don't use those
services via a web browser.

For instance (to draw from your examples): 1) Most people either install the
printer drivers from the manufacture's web site, or let Windows/OSX auto-
discover and auto configure the printer with out a web browser. 2) Most users
just use the wifi information provided by the cable/DSL provider when they
installed the modem, use the WPS button, or install the app that came with
their router rather than use a web browser to configure it. 3) Most users will
not tether their computer to their phone. 4) Most don't install a DVR app on
their phone. If they did, their phone probably communicates with their DVR via
some intermediate cloud service. 5) If their receiver auto-connects to their
itunes library, it probably won't complain about that itunes not having a
public certificate either.

------
eliben
Serious question: if I just run a simple blog with static HTML hosted with
Apache, do I really need HTTPS? Will I be penalized by not having it?

~~~
3pt14159
3% of routers in Canada and the US have some kind of malware in them, and
almost all other countries are worse off. _You_ might not need HTTPS, but I
need you to have it so I can trust downloading a PDF when I'm on your site. I
need it so I don't get MITM by some shitty black hat tracking company. I need
it so while I travel I don't have to worry about shitty governments tracking
what I'm reading or watching.

And if your answer is "sure, but there will be other websites that are HTTP"
my response is "yeah, but one day soon when enough of the web is secure I'm
going to disallow all HTTP connections from my browser". And eventually I'll
disallow all connections that aren't on HSTS preload lists. And eventually,
hopefully, I'll disallow websites that don't have HPKP with long expires.

~~~
pjmlp
Then let me tell you it is quite easy to MITM by any company owning part of
the connection.

Many moons ago I was using a proxy engine capable of unpacking/packing HTTPS
requests.

It was an in-house proxy taking advantage of Apache and IIS APIs for
certificate management and SSL connections.

We used it for debugging secure connections, but I can easily envision other
purposes.

Many years have passed since 2000, but I am quite sure it is still quite
possible to do it.

~~~
laumars
I won't comment on how you built your proxy but HTTPS has come a long way
since, eg TLS wasn't common back then and SSL has since been deprecated.

These days the only viable way to MITM HTTPS is to either attack the
connection while it's in plain text HTTP (ie before the browser redirects to
HTTPS:// (which is where the HSTS header comes in to play - it's cached by
browsers telling them to default to HTTPS and never attempt a plain text
connection) or to form your own HTTPS connection with your own CA signed
certificate for the target site. Which would mean you'd either need to
compromise a signing authority or have your own CA certs already installed on
the victims PC (the latter is what some bad ISPs reportedly do when they
inject ads).

Edit: I believe some corporate network proxies also work on the principal of
having their own CA certs on their business workstations - so maybe this was
how your proxy worked as well?

~~~
pjmlp
I can't disclose much, but can give a very basic idea regarding SSL.

That information eventually needs to be unpacked, so you get a replicate of
the destination site with the same certificates, which you can easily download
by pretending to be a browser, but running on your modified server, which then
unwraps, repackages and then forwards the request to the original server.

Since one owns the server, it is also relatively easy to disable whatever
validations the SSL algorithm requires at library level.

So I don't know TLS and since 2000 I don't mess with this kind of stuff, but I
don't think similar approaches aren't possible.

~~~
Freak_NL
You can't download the _private_ part of the TLS certificate by pretending to
be a browser. You can't publicly download it _at all_. Your browser comes with
a chain of _public_ certificates from reputable CA vendors, and you verify
that a site is who it claims to be by using their _public_ certificate (which
your browser downloads).

The only way they can succeed in proving who they are, is if their server has
access to the corresponding private key of the certificate, which is why you
can't spoof a properly secured site unless you either hack their server, crack
the encryption, or install your phony certificate on the client (which is what
corporations sometimes mandate). That's it.

It's been 17 years since 2000. Whatever security hole you may have used (if
any) has long since been patched. The weak cyphers used in some SSL versions
which you may have depended on are mostly gone (certainly from high profile
targets).

If what you state is true, now in 2017, then there would have to be a huge
conspiracy which involves all browser vendors (including Mozilla), as well as
all national governments and the EU that hides this fact from the people. All
software developers who do catch on (the relevant source code is open source
after all) would have to bribed or threatened into silence too.

You are either misinformed or consciously spreading misinformation.

~~~
laumars
> _It 's been 17 years since 2000. Whatever security hole you may have used
> (if any) has long since been patched. The weak cyphers used in some SSL
> versions which you may have depended on are mostly gone (certainly from high
> profile targets)._

I very much doubt he was even doing anything that clever. Since it was a
corporate network he probably just had their corporate CA certificate already
built as part of the company machine images / build scripts. He possibly might
not even have been aware this was happening if the IT department was large
enough that different coworkers managed the desktops from himself.

The " _I can 't disclose much_" argument on a 2 decade old hack is effectively
just saying " _I can 't remember the details_" or " _I wasn 't directly
involved in setting up the proxy_". Either way, while much has changed in the
last 17 years, the practice of some businesses installing their own CA
certificates on company assets has been a fairly standard way for corporate
proxies to intercept HTTPS traffic. And a great deal less trouble than relying
on SSL vulnerabilities since you already own and deploy the destination
hardware+software anyway.

~~~
pjmlp
Anyone can easily find me on the net and I don't need to have fun speaking
with lawyers.

Believe me or not, I don't care.

~~~
laumars
I don't really understand what lawyers have to do with the discussion but I
certainly do believe you that you had an in-house proxy that did MITM HTTPS
traffic. Lots of businesses do. The problem is you said _" let me tell you it
is quite easy to MITM by any company owning part of the connection"_ using
that as your example. While your anecdote may be true, the statement it is
trying to support simply isn't true and neither was your description of how
SSL works (eg the proxy server being able to disable the client libraries SSL
checks).

So it's not that I don't believe your anecdote - I'm sure that did happen in
some form or other - but the nature of the exploit either isn't how you
described or is so old and long since patched that it hasn't been exploitable
in more than a decade thus isn't relevant to the statement you were trying to
support.

------
cryo
HTTPS is pain in the neck and _currently_ I hate it from the bottom of my
heart.

TLTR: if you have a commercial service or device running in a local network
forget HTTPS and service workers, use HTTP and HTML5 appcache.

\-- RANT starts here --

It would be lovely when every website and webapp uses HTTPS. But for a
significant amount of them it's just not f..... possible without driving
_users_ completely insane.

If the HTTPS server doesn't (and never will) have a public domain forget about
encryption and security, forget about using service workers. The following
examples can't, by the love of god, ever provide HTTPS without completely
f..cking up user experience due self signed certificates warnings:

1) internal corporation services, websites and webapps.

2) services that run in a local private network like on a Raspberry Pi.

3) webapps which are served via public HTTPS website, but need to talk via
CORS to local unsecured services, like to a Philips hue bridge, or any other
IoT device which is in the local network but only provides HTTP. These will
enlight the users with a shiny mixed-content warning.

.... JUST use self-signed certificates, they said.

NO.

For normal users the UX of self-signed certificates is just non existent, it's
a complete mess! It will scare the sh't out of users and will almost always
look like your service is plain malware.

It _looks_ much more secure to serve a good'ol HTTP site with no encryption at
all.

~~~
bjpbakker
> 1) internal corporation services, websites and webapps

If not for hostname validation, how would you even /know/ that you're talking
to the "internal corporation service" rather than someones MITM proxy? And how
would you feel if people on the same LAN could see and modify all your
interactions with those services?

2) services that run in a local private network like on a Raspberry Pi

Depending on the type of service you may or may not want TLS. If you visit the
service by IP address and specific port anyway, you can easily add an
exception for your internal IP. This will never be used like so by non-tech-
savvy people.

3) webapps which are served via public HTTPS website, but need to talk via
CORS to local unsecured services

I cannot think of any reason to /not/ want to use HTTPS on this. It's horrible
how things like the Philips Hue bridge work and rely on insecure HTTP to
control your home lighting.

Don't blame browsers for warning people for their insecure systems and
appliances. Instead blame their creators or manufacturers as they're the ones
who can fix this situation.

 _edit: formatting_

~~~
cryo
> It's horrible how things like the Philips Hue bridge work and rely on
> insecure HTTP to control your home lighting.

The Philips hue bridge REST API is accessible in the local network like
[http://192.168.1.123/api/](http://192.168.1.123/api/) .... which is _great_
since apps/wepapps can talk to the bridge without a cloud or philips server
inbetween.

And this is the very problem, it's _not_ possible for Philips to add HTTPS
support to the hue bridge without some sort of cloud roundtrip to a Philips
server, keeping the very cool feature to talk only within the local network to
the bridge.

Because how could that be deployed without self-signed certificates and the
usual browser exceptions and warnings?

~~~
bjpbakker
> it's not possible for Philips to add HTTPS support to the hue bridge without
> some sort of cloud roundtrip to a Philips server

I don't see why not. The alternative is freedom. Philips doesn't have to lock
their devices. That's a choice they made, sadly the choice that most companies
make.

> Because how could that be deployed without self-signed certificates and the
> usual browser exceptions and warnings?

The fact that your browser warns you about insecure communication happening
from that web page, that's a good thing. Even iff you deliberately choose
accept that and believe that there's no other way for this particular
service/device.

The simple fact that you accept some insecure traffic, doesn't make it secure.

~~~
qb45
> > it's not possible for Philips to add HTTPS support to the hue bridge

> I don't see why not.

That's not a constructive argument. I don't see how they _could_ make it work?

Even if they somehow solve the problem of giving these devices domain names
and even if they generate separate private key for each unit, the key and cert
are going to be embedded in the firmware and a sufficiently sophisticated
attacker will just extract them and become able to impersonate _some_ Philips
device.

How the user of another device is going to tell whether he is connecting to
his device or to malicious neighbor impersonating neighbor's device to
establish Philips-signed HTTPS with the victim and then another connection to
victim's device and MITM the victim?

You would have to make all users install a trusted certificate authority tied
to their individual device. Which is a UX disaster in current browsers and
also a security disaster, because if this becomes a norm, sooner or later
somebody will sell you a toy device bundled with a CA crafted to give him the
ability to impersonate any website. And you'll trust this CA because you want
to play with the toy.

This _maybe_ could be made to work with some improvements in browser UI. Make
it easier to add new roots of trust. Make it easier to learn and/or limit what
websites these certs will be authorized to authenticate. But nothing like that
exists now.

> The fact that your browser warns you about insecure communication happening
> from that web page, that's a good thing. [...] The simple fact that you
> accept some insecure traffic, doesn't make it secure.

True. As somebody pointed out elsewhere in this thread, this warning will
become another EU cookie banner nothingburger.

~~~
bjpbakker
> > > it's not possible for Philips to add HTTPS support to the hue bridge

> > I don't see why not.

> That's not a constructive argument. I don't see how they could make it work?

Missing from your quote: The alternative is freedom. Philips doesn't have to
lock their devices.

If Philips (and other companies, obviously this doesn't relate to just
Philips) would provide a community access to their devices and software rather
than locking them out, I believe that this problem would not exist.

The original issue is that having a public website (used over TLS) that
interacts with local network devices without TLS shows warnings about insecure
communication. Again, the warning is shown because it /is/ insecure. There are
plenty alternatives of securely interacting with an IOT device. Plain HTTP
from a public website is just not one of them. For example, look at how
Apple's Homekit has implemented that. Homekit is not usable from a public web
page in a web browser. That's a good thing. (aside: I'm not a big fan of
Homekit but their security is not bad)

So if vendors are annoyed with browser warnings, it's because /they/ are doing
the wrong thing, not the browsers.

> sufficiently sophisticated attacker will just extract them and become able
> to impersonate some Philips device

Just like on any website. Just because something isn't 100% unbreakable,
doesn't mean it's a bad idea (you do lock your doors, don't you?)

~~~
cryo
> Missing from your quote: The alternative is freedom. Philips doesn't have to
> lock their devices. > If Philips (and other companies, obviously this
> doesn't relate to just Philips) would provide a community access to their
> devices and software rather than locking them out, I believe that this
> problem would not exist.

The problem is technical and won't be fixed by just opening the software.

> There are plenty alternatives of securely interacting with an IOT device.

Please name just one which works for webapps, beside HTTPS.

> So if vendors are annoyed with browser warnings, it's because /they/ are
> doing the wrong thing, not the browsers.

Homekit is nice but not available to webapps, apps of course can take
advantage of several security mechanisms.

My whole rant is about browsers and HTTPS in non public networks.

For webapps which want to talk to IoT devices there is _only_ HTTPS and there
is _no_ sane way to provide robust, local!, access to a LAN device via HTTPS.

Here are some requirements: (actually real, I'm working on a IoT'ish product)

* webapp must be served via HTTPS, either from the IoT device or vendor site

* it just works! if webapp served from IoT device, the user shall not be required to install certificate or set exception (because it then looks like scary as hell malware)

* the webapp must work offline (service worker or appcache) without internet connection * webapp must be able to talk directly to the device, no cloud or vendor server inbetween

* the IoT device which provides a secured REST API might be in in a LAN which is NOT connected to the internet -- so the '<random-stuff-id>.vendor.com DNS resolves to device IP with an Lets Encrypt CA' approach won't work here (otherwise nice hack)

To my knowledge it's technically not possible to build such a HTTPS secured
_webapp_ in a local network today without breaking the mentioned requirements.

~~~
bjpbakker
> The problem is technical and won't be fixed by just opening the software.

I strongly disagree. Main reason is that if Philips opened their firmware to
the public, it would have had different protocols by now than just HTTP with a
poor mans JSON API.

> Homekit is nice but not available to webapps, apps of course can take
> advantage of several security mechanisms.

That's why basically my point is to /not/ use a web app to control local
insecure IOT devices.

> Please name just one which works for webapps, beside HTTPS.

Use locally resolvable DNS names and wildcard certificates signed by commonly
trusted (public) CAs. It's been done before (Plex does something like this
IIRC).

* update: I just noticed another comment [1] that mentions Plex with a link to some technical details [2].

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

[2] [https://blog.filippo.io/how-plex-is-doing-https-for-all-
its-...](https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/)

~~~
qb45
> it would have had different protocols by now than just HTTP with a poor mans
> JSON API.

Sure, but now you can't control the gadget from the browser and the vendor
needs to write an application or something for whatever shitty OS you want to
use.

> Use locally resolvable DNS names and wildcard certificates signed by
> commonly trusted (public) CAs. It's been done before (Plex does something
> like this IIRC).

Not that simple. Public CAs will likely only give you certs for domains you
own (like plex.direct) and your users generally don't have nameservers
authoritative for such domains on their LANs (maybe you could pull it off if
you are a router vendor, but not with IoT light bulbs) so they have to query
your public nameserver and the system fails without Internet connection.

And there is no easy solution: if your light bulb could register an
xxx.philips.com domain via UPnP on your router or via SMB on your Windows box,
it would be very much unclear what exactly should prevent it from registering
philips.com as well.

------
vmp
Off-topic: If only IPv6 adaptation would have as much momentum as HTTPS.

~~~
cbhl
I suspect the big reason it hasn't happened yet is it would require ISPs to
replace tens of thousands of dollars of hardware and it would increase support
requests in the short term ("site XYZ is broken but it's fixed when I turn of
IPv6").

~~~
swift
Is the hardware you're talking about the network equipment controlled by the
ISP, or the routers and modems in customers' homes? I'd be surprised if the
former hadn't been IPv6-ready for many years now, but I can imagine many
customers are still using ancient hardware left over from when they first
signed up for service.

~~~
tsomctl
If you have cable, a number of providers have been making customers upgrade to
the newest modem. A single old modem that doesn't support docsis 3 will slow
down everyone in your neighborhood.

~~~
curiousGambler
Really? Interesting... can you elaborate/provide some reading?

I'm a software engineer with a smidge of basic networking experience so not
completely clueless, but definitely inexperienced with DOCSIS and this sort of
residential networking stuff.

------
sebcat
I wish people would stop equating "secure" with "HTTPS".

~~~
Aissen
That's not what's done. "No HTTPS" is equated with "non secure".

~~~
sebcat
He also claims that Quantas "secured their site" by adding HTTPS to their
login page, and that serving sites over HTTPS is "secure by default"

~~~
willstrafach
This is true. I can intercept your username/password during login by being in
close proximity to you if you are logging into their website over plaintext
HTTP. Not possible if it is protected by TLS (HTTPS).

------
makecheck
I hope they did some user testing to see how people _actually_ behave in the
presence of such warnings but in my experience it does nothing. Worse, it's in
an environment that is already rife with little messages in corners trying to
get your attention (ads) so users may be more "blind" when browsing than
usual.

The success of "Let's Encrypt" suggests that a key part of the problem wasn't
a lack of user complaints about security. Rather, it was a lack of a sane
model (both technically and economically) for setting up and _maintaining_
certificates. In the end, people maintaining sites already had 100 other
things to worry about and weren't going to get around to HTTPS with anything
less.

------
milankragujevic
With Cloudflare's first easy to use free SSL and later Lets Encrypt, I think
it there are no more excuses for not being secure.

~~~
thesmallestcat
Cloudflare's free SSL is not secure.

~~~
catshirt
is not? or was not? honest question. care to elaborate for a noob?

~~~
lambda
CloudFlare's "Flexible SSL"
([https://www.cloudflare.com/ssl/](https://www.cloudflare.com/ssl/)) offers
encryption/authentication from CloudFlare's server to the client, but none
from the origin server to CloudFlare's. Which means that is a vector by which
the content could be sniffed or modified in transit.

It's a "better than nothing" option, as there are a slightly higher number of
actively exploited attack vectors that apply to the client to CDN connection
than the CDN to origin server, such as "free" wifi that injects ads, malicious
ISP DNS, and the like. But it's not actually secure, as the origin server to
CDN connection could be tampered with, and just because there are fewer active
attacks that would be likely to affect that connection right now, doesn't mean
that someone won't come along later and hijack such a connection.

CloudFlare offers other TLS options that do include encryption and
authentication between the origin server and CDN, but they do require that you
set up a certificate on your server, so if all you're trying to do is enable
TLS (and don't care about the CDN), just installing a cert on the origin
server and using TLS is probably a simpler option that using CloudFlare.

~~~
prdonahue
We encourage users to use Strict mode which requests and validates a
certificate from the origin.

It's great that shared web hosting providers and others are starting to make
it easy to acquire and install a certificate, but that hasn't always been the
case.

EDIT: We also provide an API that will provision a free certificate for your
origin: [https://blog.cloudflare.com/cloudflare-ca-encryption-
origin/](https://blog.cloudflare.com/cloudflare-ca-encryption-origin/). The
certificate is optimized for communication with our edge (essentially just as
small a chain as possible, as we don't need the intermediate to walk to the
root). Either that or use certbot from EFF/Let's Encrypt.

------
wfunction
How is a gateway serving a configuration page at 192.168.1.1 to internal users
supposed to eventually get an HTTPS certificate for that address...?

~~~
lmm
It's not. It's supposed to use a publicly routable address. Private addresses
were an unfortunate hack that got massively overused when people would've been
much better off putting the same effort into using IPv6.

~~~
AlexandrB
Down this path lies the IoT security apocalypse. Imagine every cheap,
unupgradable IoT lightbulb with a publically routable IP address. If IPv6 was
widely adopted tomorrow, I'd still run my home LAN services behind a NAT.

~~~
lmm
Addressability != access. By all means firewall your devices (though I'd
strongly recommend something more granular than a perimeter firewall -
particularly in the days of insecure IoT devices, an attack could easily be
coming from inside the network), but they can still have proper addresses.

------
a_imho
I deploy ssl on all my sites, but imo the article is way overestimating the
importance of browser notifications.

~~~
anilgulecha
Users are tuned to seeing green icon, and secure as trustworthy. This is over
a decade of UX towards these. Suddenly seeing "Not secure" will definitely
have an impact on engagement. (I know we're both guessing -- we'll have to
wait for concrete numbers to make a call). I'd mark the engagement change at
around 10%, and 20% for any site that is login/payments related.

~~~
return0
they have been seeing that for months now ( i see it often too on sites that
are slow to change). I have not heard anyone complaining about loss of
traffic. It's becoming transparent to the users, imho, like the EU cookie
prompt.

~~~
anilgulecha
It's not red yet. It will look like this eventually.:
[https://www.wordfence.com/wp-content/uploads/2017/01/blog-
im...](https://www.wordfence.com/wp-content/uploads/2017/01/blog-image-2.png)
, which will be a stronger negative signal.

------
daxfohl
How about a warning in Chrome that says "You're about to use _Chrome_ to visit
this website, and thus send everything about yourself to Google to do whatever
they want with", for _all_ websites staring in Chrome ~67?

------
TekMol
How hard is it to provide HTTPS these days?

Say you have a plain Debian 8 install, running a typical LAMP stack serving a
single domain.

If you want to make it use a LetsEncrypt cert and serve the domain over HTTPS
- what would be the minimum number of steps on the command line to make it do
that?

~~~
ezequiel-garzon
Something like (assuming you've reviewed the terms of service):

    
    
        apt install letsencrypt
        letsencrypt certonly -d example.com -d www.example.com -m you@example.com --agree-tos
    

And then add a weekly cron job with:

    
    
        letsencrypt renew
    

You need to stop your server for these actions, though I'm sure there are ways
to avoid this.

~~~
TekMol
There is no package "letsencrypt" in the repos of a standard Debian 8
installation.

~~~
jws
It is "certbot" in Debian 9. Maybe 8 too.

------
epalmer
I have been anticipating this but have had better things to spend my limited
time on. I have more than 135 sites I need to convert to https and they are
load balanced. I don't think letsencrypt handles load balanced sites yet. My
management is against wildcard certs. This might push them over the edge in
favor of wildcard certs.

~~~
extra88
You can have a single cert with all 135 sites' domain names in it. A wildcard
cert may be preferable if the list of domain names frequently changes.

~~~
epalmer
Thanks. I hadn't yet considered this.

------
KevinEldon
HTTPS gives your ISP less of your information to collect, analyze and sell to
advertisers which in turn protects the value of Google's information about
you. I think the changes to Chrome are well-intentioned, but can't help but
smile at how this side-effect favors Google's business.

------
gator-io
Here's another take on how much of the web is HTTPS:

[https://truemarketshare.com/report?id=https](https://truemarketshare.com/report?id=https)

------
kylehotchkiss
Bleh. Wish I could use ssl on my GitHub pages site with custom domain.

~~~
unmole
I do exactly that with Cloudflare.

~~~
reustle
According to the comments above, it's not exactly secure

~~~
marksomnian
Please read [https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-
securi...](https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-security-
absolutism/) \- yes, it may not be 100% secure, but it almost never is in the
real world anyway

~~~
lmm
It's more like some endpoints are 95% secure whereas cloudflare flexible ssl
is 5% secure. Conflating those as "not 100%" is far more misleading than
rounding them off to "secure" and "not secure". If [https://](https://)
doesn't mean traffic is encrypted as it passes over the public internet then
it means nothing, and that's what happens when you use cloudflare.

------
fatzombi_
what about self signed certificates? wouldn't it be great if these swebsites
treated like http ones, without any security flags

~~~
electrum
Allowing transparent downgrades of self-signed certificates would be a big
security hole. For example, suppose I add the following to my website:

    
    
      <script src="https://cdn.example.com/awesome.js">
    

By doing so, I am requiring the script to be served securely. If we allow
self-signed certificates, anyone could generate a self-signed certificate for
example.com and serve a malicious script to my users.

~~~
pdkl95
> Allowing transparent downgrades of self-signed certificates would be a big
> security hole.

Automatically generated self-signed certificates should have replaced _all
plaintext HTTP_ 15-20 years ago. The big security hole was allowing passive
surveillance, ISP-level page injection vandalism[1]/attacks[2].

The web could have been almost completely protected from several _classes_ of
attack a decade ago, but this _stupid_ insistence on conflating protection
from 3rd part eavesdropping or corruption during transit with the
_authentication_ of the server. These are entirely separate problems that do
not need to be solved at the same time.

> I am requiring the script to be served securely

You're requiring it to be served over HTTPS, which doesn't necessarily mean
"secure", because "secure" covers several different goals. You're also
strongly trusting the PKI system. Do you trust all the certificate authorities
your browser includes by default?

Of course, because HTTP _still exists_ , the initial request for the HTML that
contains your <script> tag could be sent plaintext and thus modified during
transit in many different ways.

> serve a malicious script to my users.

That can still happen without proper pinning, or if the local browser
downgrades the request back to HTTP. Unfortunately this isn't particularly
uncommon with corporate/school proxy, in-flight wi-fi services that forge
certificates[3], and Superfish-style junk all removing _both_ the encryption
_and_ the authentication provided by TLS.

Regarding your specific example about loading Javascript referenced in an HTML
document's <script> tag, the solution is to validate the _data_ , not the
_server_. The valid server can still send incorrect data. If you include
hashes about a page's subresources[4], the browser can validate the integrity
of the file it received.

[1] [https://arstechnica.com/tech-policy/2014/09/why-comcasts-
jav...](https://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-
ad-injections-threaten-security-net-neutrality/)

[2] [https://citizenlab.ca/2015/04/chinas-great-
cannon/](https://citizenlab.ca/2015/04/chinas-great-cannon/)

[3] [https://arstechnica.com/information-
technology/2016/02/why-y...](https://arstechnica.com/information-
technology/2016/02/why-you-probably-shouldnt-be-doing-work-on-that-in-flight-
wi-fi/)

[4] [https://www.w3.org/TR/SRI/](https://www.w3.org/TR/SRI/)

~~~
BenjiWiebe
Of course, even with self signed certificates to replace plaintext http, ISP
injecting/vandalism would be really easy. ISP would terminate the TLS, inject
some annoying stuff, and then reencrypt with another auto generated
certificate. Without the verification by public CAs, the client could never
detect the MITMing.

~~~
pdkl95
> another auto generated certificate

The client can detect changing to a new certificate. Obviously self signed
certificates have problems. The main point is that it _does_ protect against
some attacks, and raises the complexity/cost. Running a MITM takes a lot more
time, effort, and resources compared to simple deep packet inspection on
plaintext packets.

> Without the verification by public CAs

While there isn't much support in current client software, verification
doesn't have to be from a CA. In an ideal world, your bank (or whomever) could
hand out some sort of dongle (or maybe as a QR (or similar) code on a card?)
that had a certificate that could be used for direct verification of their
internet services independent of any CA, or in combination with CA
verification.

~~~
solatic
> The client can detect changing to a new certificate

Not if the client has never visited the site before and doesn't have a known-
good self-signed certificate pinned locally to check against. And if the
client did have such a certificate pinned, revocation by the legitimate owner
of the self-signed certificate becomes impossible, since the client won't
trust the new self-signed certificate being presented to it, without out-of-
band communication of said intent to revoke and manual intervention on the
client side.

> dongle

Again, the problem is certificate revocation. Physical dongles cannot easily
be revoked. Corporate intranets deal with catastrophic compromise of their
internal CA certificates by re-imaging all corporate machines with new
certificates and restoring from off-site backups where needed - prescribing
that for customer machines is impossible.

PKI is like monitoring - it must rely on external services to be dependable
and effective.

~~~
pdkl95
> never visited the site before

I already said that self signed certs are not going to solve every problem.
They solve _some_ problems, which is better _plaintext_ HTTP that we should
have retired over a decade ago. Obviously you should validate the server -
probably through the usual PKI methods - whenever possible.

> revocation

Revocation would happen in the usual manner. The dongle is just a minor
example of another way to provide validation. Obviously each methods will have
their own benefits and limitations. I'm not saying we should replace PKI with
physical dongles; I'm suggesting that alternative (non-PKI) methods are
possible and they can not only coexist, they can also corroborate each other.

------
chillingeffect
Bit of a scare tactic. Page is an ad for Mr. Hunt's $299 course.

It's all true. However, I would make the case for Pat Q. Mainstream feeling
less alarmed by "Not Secure" messages than most HN readers.

Note the Twitter example is from Mr. Hunt, not a random internet user.

~~~
skeletonjelly
It's his MO. Every article of his is decently researched with lots of fluff,
always points to another article of his, and always ends in some kind of
conversion goal.

~~~
laughfactory
True, but a man's gotta eat, and security is more and more critical these
days. I don't begrudge him making a living while beating the drum of be-more-
security-aware.

~~~
skeletonjelly
True. He's well off already though.

The article that seems to stick in my head is him spruiking a wifi extender he
got for free so he can access wifi on his jetski at his jetty.

[https://www.troyhunt.com/how-i-finally-fixed-the-dodgy-
wifi-...](https://www.troyhunt.com/how-i-finally-fixed-the-dodgy-wifi-on-my-
jet-ski-with-ubiquitis-unifi-mesh/)

I can't bemoan how many times I've had poor wifi at my jetty ;)

