Life Is About to Get Harder for Websites Without HTTPS

https://www.troyhunt.com/life-is-about-to-get-harder-for-websites-without-https/

by finnn • 9 years ago

286 335 9 years ago

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• 9 years ago

Cloudflare's free SSL is not secure.

catshirt2• 9 years ago

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

milankragujevic2• 9 years ago

Well it kind of is if you setup a self-signed SSL cert on your server and use Full SSL (not strict).

LarryMade22• 9 years ago

Extra cost of a static IP hosting (needed for domain registration) is a big factor, doubles the costs of my small website hosting.

finnn• 9 years ago

Domain registration? That certainly doesn't require a static IP... nor does any other part of deploying TLS.

throwaway20483• 9 years ago

https://en.wikipedia.org/wiki/Server_Name_Indication

Any host that still requires a dedicated IP for https is woefully out of date.

grecy• 9 years ago

I'm running Varnish in front of wordpress and mediawiki.... sure I can make it all work with HTTPS, but it's going to be a PITA.

chrsstrm• 9 years ago

Not really. You put nginx in front of Varnish and terminate your TLS there. It's not that much more work. Hint: make sure you have an X-Forwarded-For entry in your nginx config. Your root location would look something like:

    location / {
     proxy_pass http://localhost:8082;
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header X-Forwarded-Port 443;
     proxy_set_header X-Forwarded-Proto $scheme;
   }

Assuming your Varnish setup was serving on 8082.

LunaSea2• 9 years ago

Let's Encrypt's short expiration times make them too cumbersome to use.

SquareWheel2• 9 years ago

The point is to automate. If you're manually renewing them every thee months, then you're very much doing it wrong and it should be cumbersome.

chillingeffect3• 9 years ago

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.

Operyl• 9 years ago

How is it a scare tactic? It's the reality, there's not much more room for an unencrypted web nowadays. Troy can feel free to advertise whatever he wants, and what he says is still true.

peteretep• 9 years ago

    > Page is an ad for Mr. Hunt's
    > $299 course

I read it and at the end was unaware he had a course, so I don't think this is true.

chillingeffect3• 9 years ago

"a few months ago I published a new Pluralsight course on What Every Developer Must Know About HTTPS "

skeletonjelly2• 9 years ago

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• 9 years ago

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.

jwilk• 9 years ago

What's MO?

vmp• 9 years ago

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

cbhl• 9 years ago

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• 9 years ago

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.

derefr• 9 years ago

That, and—unlike TLS—there isn't any class of business-destroying vulnerability whose easy solution is IPv6.

lima2• 9 years ago

ISPs love IPv6 because they lack IPv4 addresses.

Here in Germany, you no longer get IPv4 addresses from Unitymedia.

djsumdog3• 9 years ago

For real. I've seen it more these days. A friend in a po-dunk town in Northern California I visited had IPv6 from Comcast. I was kinda shocked since my fiber Gigabit ISP in Seattle didn't have IPv6 rolled out to residential customers yet.

It seems more important than ever to roll out IPv6, since, at some point, IPv4 is going to become incredibly scares. Imagine a permanent/reserved IPv4 address on DigitalOcean/AWS/Vultr going from the few dollars a month to $70/month or $100/month. Forget network neutrality, regular people won't even be able to host their own content in a way everyone else can reach.

IanCal2• 9 years ago

It's already a bit of a pain, as at a dollar or a few dollars a month it's approaching or over the cost of some servers I want to run.

But I expect things will continue slowly being replaced, as more switch over the stress on IPV4 lowers.

dx0344• 9 years ago

There's a real and immediate value for users if HTTPS is used. I don't see the immediate value for end users when IPv6 is used. Worst case, the lack of NATs makes tracking easier.

IPv6 is certainly necessary but nothing users have to worry about.

lostboys67• 9 years ago

Https has googles bully pulpit behind it and even though https has its issues it pales into insignificance compared to ipv6's "problematic" design choices

fatzombi_• 9 years ago

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

electrum• 9 years ago

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.

pdkl954• 9 years ago

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...

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

[3] https://arstechnica.com/information-technology/2016/02/why-y...

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

JoshTriplett• 9 years ago

what about self signed certificates? wouldn't it be great if these swebsites treated like http ones

In the not too distant future, they will be, though perhaps not in the way you had in mind: HTTP sites will start showing similar indications of insecurity, just like sites with broken HTTPS.

eliben• 9 years ago

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?

saagarjha• 9 years ago

It doesn't look like it right now:

all websites with form fields served over HTTP will show a "Not secure" warning to the user

As long as you don't have a form field, you should be fine.

marksomnian2• 9 years ago

I believe the Chrome team has (or at least had) long term plans to mark all HTTP sites as actively dangerous, form fields or not. So, you'll be fine for now, but there will come a point when you will need to implement HTTPS.

JonRB• 9 years ago

My understanding is that you will already be ranked lower on search engines.

My main concern with this happening is that browsers are going to get a reputation for being 'alarmist', so when something really goes wrong, they won't be able to communicate it effectively.

jaas• 9 years ago

You won't have confidence that your visitors see the content you serve as you intend because it can be modified in transit. Your visitors will be broadcasting at least the exact address of the pages they read on your blog, and are vulnerable to anything that gets injected into your traffic in transit (e.g. malicious script).

Every website should use HTTPS. It's the right thing to do. It's not hard to do these days.

reustle2• 9 years ago

Every website should use HTTPS. It's the right thing to do. It's not hard to do these days.

Unless you use simple tools like GitHub pages. I have a bunch of tiny JS heavy static projects on Pages that I can't easily add HTTPS to.

djsumdog3• 9 years ago

Exactly. I remember viewing my website over a mobile connection in the UK and getting an ISP banner at the top of the page! Injected right into my HTML!

3pt141592• 9 years ago

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.

pjmlp5• 9 years ago

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.

xfer• 9 years ago

The question was about static HTML pages, so the government can track what you are reading or watching.

will_hughes2• 9 years ago

I need it so while I travel I don't have to worry about shitty governments tracking what I'm reading or watching.

For this reason I used a VPN while travelling overseas. Most places have wifi of varying quality. To my dismay/horror, I found that Hilton charge EUR15/day for the privelege of using a VPN.

blfr2• 9 years ago

eventually, hopefully, I'll disallow websites that don't have HPKP with long expires

I doubt HPKP will ever see wide adoption. At least not in the form it has now. It's just too damn easy to bork the config and take your entire site offline with no way to remedy that error.

tonyarkles2• 9 years ago

3%?! Do you have a link where I can read more? That's horrifying!

mholt• 9 years ago

Answer: https://doesmysiteneedhttps.com

Yes, search engines will penalize you. ISPs will intercept traffic and change it. Your site will load slower. The problems with plain HTTP go on and on.

kylehotchkiss• 9 years ago

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

unmole• 9 years ago

I do exactly that with Cloudflare.

reustle2• 9 years ago

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

y0ghur7_xxx8• 9 years ago

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.

dx0344• 9 years ago

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_xxx8• 9 years ago

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.

hartator• 9 years ago

Can we do SSL locally though?

tajen4• 9 years ago

...but those services, served over HTTP, are not secured and can be spied upon by your insecure Chinese webcam or by the 3% of routers that have a malware, isn't that correct? So the browser should display so, it's up to you to ignore the warning.

y0ghur7_xxx8• 9 years ago

Well it's my lan, and I can decide what I trust and what not. For example in my home network I have different vlans: one for things i reasonably trust, and one for the chinese webcams and iot lightbulbs. If my router has malware, even if i talk to it over https I'm screwed anyway, I don't think that is something I can fix with https.

bjpbakker9• 9 years ago

LANs should be included. It's just as bad as using most websites without TLS.

Maybe this helps forcing companies of IOT-like devices finally take security a bit more serious.

AlexandrB4• 9 years ago

LANs should be included. It's just as bad as using most websites without TLS.

Why? What's the threat model, that your employer/colleagues can see your traffic?

tonyarkles2• 9 years ago

I would really love to see some kind of LAN TLS solution that doesn't rely on requiring you to have your own CA. I've thought a fair bit about the problem, but haven't come up with any solutions that I like.

Browsers, rightfully so, don't accept self-signed certificates. Active Directory and Group Policies can push out a trusted self-signed root CA certificate and generate certs that endpoints can use, but that's a pain in the ass and usually requires central IT to manage.

Please someone come up with something I haven't thought of yet that doesn't break the internet but gets useful certs onto my LAN!

StavrosK• 9 years ago

Why not just give them a domain name? I gave them a subdomain of my personal domain and Caddy handles TLS for all of them automatically.

frik3• 9 years ago

Some browser vendors have an agenda. But why now? Amazon.com worked fine with HTTPS from 1995 to 2006 - only the login page used HTTPS.

Now a small group tries to break the web and enforce HTTPS, but why? Is it to de-anonymize the web users?

cryo6• 9 years ago

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.

sgift• 9 years ago

1) internal corporation services, websites and webapps.

For this use case companies usually provide an internal CA, which signs their certificates and is trusted by all company machines. We have various customers which do this and it works just fine.

jakobbuis• 9 years ago

This fails utterly when you can't control your clients. My student society for example ran into this problem. Students bring their own laptops and installing our root certificate on all of them is infeasible (if they even would allow us to do so). As a consequence, we need to expose critical internal services on the public internet, some of which contain private user data.

wfunction14• 9 years ago

And why would I trust a company I work at to be able to sign certificates for every single website on the internet? Especially if I need to install that root certificate on a personal device?

15thandwhatever• 9 years ago

Large companies do this.

Small companies/small groups of developers have no idea how to implement and manage this, but think that it should be easy.

I've recently been approached by a group of developers to enable SSL on their internal sites. When I mentioned that this would take some time, the response was "why can't you just use LetsEncrypt?"

I replied that LE only works on external facing sites, not internal sites. The next response was "fine, why don't we make it all external facing?"

I'm still trying to explain that their CI server (Jenkins, with its history of remotely exploitable vulnerabilities), and their internal OAuth2 server should not be public facing.

ewanm895• 9 years ago

I even do this on my own private network. Installing root certificates is not hard.

solatic3• 9 years ago

If you're in a corporate intranet environment, you ought to have an intranet CA, as well as the means to distribute the CA's certificates securely to all deployed machines within the intranet.

tempay• 9 years ago

That's okay unless you allow users to bring there own devices, then you have users which are taught to bypass certificate errors on a daily basis.

tajen4• 9 years ago

I dislike intranet CAs because they allow your company to intercept and play MITM with every other website you visit (except for certificate-pinned websites)...

I'd prefer that Chrome write "insecure" if there's a non-public CA in your chain.

jcassee• 9 years ago

Would just creating (public) DNS records for those private addresses be a solution for 1 and 2?

JumpCrisscross• 9 years ago

FYI, I recently watched a potential portfolio company fail dilgence for having "insecure network practices". The diligence item? Is the lockbox green.

Do I agree with this signal? Not entirely. But the company was forced into restart and into new management. Guess what colour their lockboxes were?

The default has shifted; if your best retort is "it's hard," I'm not sure what to tell you. Yet government, maybe?

sschueller• 9 years ago

Yes.

Also why do I get a certificate warning that looks the same for an IP (https://192.168.1.1) which you can not buy certificates? What about 10.x.x.x or even 127.0.0.1? As far as I know you can also no longer purchase a certificate for public IPs.

Just watch how consumer router manufactures are going to work around this by either re-educating their users to ignore the red warnings or only selling cloud managed and locked devices which sucks for everyone.

ewanm895• 9 years ago

Assign a fqdn, I log into my router with a domain name, most routers actually have a domain name for them.

Configure the LAN setting of RT-AC68U. Device Name: ghandi

bjpbakker9• 9 years ago

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

cryo6• 9 years ago

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/ .... 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?

Xcelerate3• 9 years ago

If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy?

Because a crap ton of Linux software comes with its own set of bundled root CAs instead of using the system defaults. Welcome to the configuration nightmare that is setting up Anaconda, npm, AWS CLI, Python (Requests library), Git, etc. for working with something like Zscaler.

syrrim• 9 years ago

If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy?

If you control physical hardware, and you control all the users on it (as a corporate network), then you can know that nothing is amiss.

And how would you feel if people on the same LAN could see and modify all your interactions with those services?

The fact that they physically can doesn't mean they will.

For 2 & 3:

https has two modes: self signed, and certified. Certified requires that you have a public facing domain name, such as "news.ycombinator.com". Devices on private networks can't have public domain names. Consumer devices on public networks could have domain names, but this would be very difficult to configure. Without a domain name, https must be done as self signed.

With self signed, when you first interact with the server, it could be anyone. Self signed https only gives you the guarantee that any further interaction besides this first one are with the same server as the first one. It should be clear that you can still be MITMed under this mode, so long as the attacker can intersect the first message you send after a reboot. If you're scared of network ninjas sneaking into your house in the middle of the night and intersecting your packets, self signed https is no better than http.

Lazare2• 9 years ago

If the HTTPS server doesn't (and never will) have a public domain

Then give it a public domain, keep it on a private network, and use a real certificate?

macns• 9 years ago

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

Not for long it won't: Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS.

Taken from Google security blog[1] back in Sept 2016: https://security.googleblog.com/2016/09/moving-towards-more-...

NKCSS2• 9 years ago

You can solve this with DNS if you'd want...

Have every local machine get something that is internet-routable to a public machine that allows you to get a certificate, then on your corporate DNS, just serve the local machine it's supposed to go to and you can use that cert.

You could use Let's Encrypt for this and have free certs.

greggman3• 9 years ago

no, limit 5 certs per domain

geogriffin• 9 years ago

Western Digital solves #2 and #3 for the MyCloud EX4 by somehow issuing real browser-trusted certs to each device for the domain device<mac_address>.wd2go.com using their intermediate CA "Western Digital Technologies Certification Authority" (https://www.censys.io/certificates/eb94f8e2c8d0c8338bb8ba40e...), which is in turn issued by COMODO. Now, not everyone has an intermediate CA locked to their own domain, but maybe that's the issue? X.509 has the ability to restrict CAs to particular domains (e.g. see the "path constraint" on WD's CA in the info link above), so if it was easy to be issued a CA cert for your own domain, couldn't that be a potential solution to this problem?

Sir_Substance• 9 years ago

1) internal corporation services, websites and webapps.

If this is an internal corporation service, why don't you bake your own self-signed root certificate into every computer in your network? Then you can generate as many certificates from your own root as you like, and they'll all magically be valid on corporate computers.

ewanm895• 9 years ago

1) internal company webapps just install company root cert and create properly signed certs under corporate internal CA. Installing the certificate across network is easily automatable on windows, OSX and Linux. The only issue is Firefox as it uses its own trust store. Any senior admin who can't figure it out with the resources available (plenty of information available online) should be replaced days it is not that hard.

2) with regards to raspberry pi, will anyone who can write code can learn to also create their own CA the only difference is probably no automation of adding to the trust store likely however it is only a 2-3 click install in most cases.

felipelemos2• 9 years ago

You are assuming that you control all client machines. Unfortunately it is not always possible and far from the admin technical decision. The admin usually can't fire the upper management.

jcrites• 9 years ago

1) internal corporation services, websites and webapps.

That one's straightforward. Set up a corporate CA and use it for your internal certificates. Or, operate your corporate services on your real domain name, and use real publicly-trusted certificates - whichever is easier.

Xcelerate3• 9 years ago

Set up a corporate CA and use it for your internal certificates.

Good luck with Docker containers running any Unix software that bundles the "default" root CAs along with it.

bryanlarsen• 9 years ago

You can get a certificate for a local IP address. If you own foo.com, you can get a cert for local.foo.com from letsencrypt that points to 192.168.1.5. Obviously you can't use HTTP verification, but you can use DNS verification, point _acme-challenge.local.foo.com to a public server and run certsling or another acme client on that server.

abrkn• 9 years ago

Just buy a .com domain for your internal service and serve DNS over VPN

raverbashing• 9 years ago

Self sign from an internal CA and add that to client keychains

(but yeah your points are valid, which is deeply unfortunate)

xena• 9 years ago

let's encrypt is free, you have no excuse.

fundabulousrIII• 9 years ago

This is complete nonsense.

pampa• 9 years ago

1) internal corporation services, websites and webapps.

When firefox started throwing warnings on my intranet sites that are accessed via OpenVPN i did this:

1) move all internal sites to valid FQDN 2) push dns settings over openvpn so that clients resolve the names with the internal dns service and dont leak names. Names withing the vpn resolve to internal ip addresses. 3) set up a catch-all website, point the wildcard *.company.name domain to it and mada letsencrypt certs for the internail domains/ 4) copy the valid certs to the intranet webserver. Done. Everything working ok.

sebcat3• 9 years ago

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

Aissen• 9 years ago

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

sebcat3• 9 years ago

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"

ko27• 9 years ago

Well that's what the S in HTTPS stands for. I am pretty sure that anybody who knows the difference between HTTP and HTTPS also knows that "security" is not binary.

sebcat3• 9 years ago

Since this guy is equating "secure" with "HTTPS" in some of his statements, would you say that he does not understand that security is not binary?

TekMol2• 9 years ago

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-garzon2• 9 years ago

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.

TekMol2• 9 years ago

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

jefozabuss• 9 years ago

https://www.digitalocean.com/community/tutorials/how-to-secu...

tajen4• 9 years ago

A dozen in non-interactive mode; less than half in interactive:

Non-interactive: install Certbot, copy the config file, run certbot, add a crontab for renewals, configure your nginx to see the certificate.

roebk• 9 years ago

The company I work for have 3000+ websites served from a single application. Whilst we offer everyone HTTPS when they log in (everything's on a subdomain at this point, so a wildcard cert does the trick), we don't have HTTPS enabled for general access to their websites.

I've pushed for the 3000+ websites to be served over HTTPS but there's serious reluctance from the sys admins about creating and managing such volumes of certificates. So I'm guessing it's easy if you only have a handful of services, but at volume it becomes a little tricker. If there's a easy way to solve this problem, I'd love to hear it.

corford• 9 years ago

I'm a fan of https://github.com/Neilpang/acme.sh You should be up and running in minutes with it.

pbhjpbhj• 9 years ago

Looks like 5 lines using "Certbot", https://certbot.eff.org/#debianjessie-apache.

a_imho• 9 years ago

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

anilgulecha4• 9 years ago

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• 9 years ago

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.

wfunction14• 9 years ago

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...?

teddyh• 9 years ago

Easy. Get a certificate for some name, say foo.example.com. Point foo.example.com, in your internal network's resolver, to 192.168.1.1. Use foo.example.com in the browser instead of 192.168.1.1. Done.

wfunction14• 9 years ago

Who is supposed to do this exactly? Me the consumer who buys a router, or me the manufacturer of said router? (router/access point/whatever it's called...)

pornel• 9 years ago

All CAs explicitly forbid manufacturers from doing so and will revoke all certificates used this way.

This is because the device would have to ship with the private key.

lmm13• 9 years ago

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.

wfunction14• 9 years ago

How is it supposed to get a publicly routable address when it's not necessarily connected to the internet?

coding123• 9 years ago

Every router that ever existed will need to be able to connect to the internet before it is configured?

AlexandrB4• 9 years ago

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.

KevinEldon• 9 years ago

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.

epalmer3• 9 years ago

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.

laurencei• 9 years ago

I use LetsEncrypt on a load balancer without issue.

epalmer3• 9 years ago

DO you have a url for documentation that shows how to set up the certs? Our certs are on each web server and not in the load balancer. I suppose we can also put the certs into the load balancer but I don't have control over that.

Edit: typo

extra882• 9 years ago

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.

epalmer3• 9 years ago

Thanks. I hadn't yet considered this.

userbinator• 9 years ago

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/ 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 .

(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_2• 9 years ago

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• 9 years ago

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.

empyrical• 9 years ago

Such at-risk sites should be archived in case they do go down. This excellent site has info/tools on doing just that:

http://archiveteam.org/index.php?title=Main_Page

skybrian• 9 years ago

I suspect people who commonly look at the older or weirder parts of the Internet will get used to the "not secure" warning. If you don't care enough to fix it, you probably don't care much about growing a mainstream audience anyway.

"Not secure" doesn't mean you have to shut it down, it just means it's not secure.

This is part of a trend of gradually increasing production values for mainstream sites; it makes the less polished stuff look dated, but in a way that's just going back to the old days when the Internet was an obscure place with a small audience.

davemel37• 9 years ago

I completely agree...this will just dilute the impact of not secure and after a bunch of safe interactions to not secure sites, it might actually make not secure meaningless to the masses.

That being said, I think the owners of sites will still feel the sting in their gut seeing or hearing their site is insecure or that browsers are scaring visitors away...so I think it will speed up adoption even further and I do agree that https will become the default.

Panino• 9 years ago

People who have created and then abandoned such sites are very unlikely to self-host on their own hardware or VPS. Their web hosts will simply get certs through Let's Encrypt or other and things will continue working fine.

mustacheemperor• 9 years ago

Interesting you link to homebrewcpu.com, since one of the links on that page directs to a blog where all the images on the homepage have been broken by Photobucket's recent policy change. I feel like in the future people will be mystified at how much of the early internet just gradually vaporized.

softawre• 9 years ago

I feel that way today. Most of the web pages I used as a teenager are just gone now.

Old myspace pages? Geocities? Old BBS boards?

frik3• 9 years ago

How can one view the HTTPS certificate nowadays???

The feature got removed recently from Chrome and Firefox - why?

In older FF, Chrome and still available in IE11 you just click on the "secure" icon next to the address bar.

I am really the only one who misses this feature?

hx87• 9 years ago

In Chrome, right click -> Inspect -> Security -> View Certificate

gator-io• 9 years ago

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

https://truemarketshare.com/report?id=https

makecheck• 9 years ago

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.

daxfohl• 9 years ago

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?

Life Is About to Get Harder for Websites Without HTTPS

Related Stories