HTTPS is Easy | Hacker News Reader

HTTPS is Easy

troyhunt.com

62 pointsjgrahamc31 comments

Troy is not suggesting people implement HTTPS. He's suggesting they use pre-rolled services made by companies which just happens to deliver HTTPS. Using a product may be easy, but implementing HTTPS is not.

I mean, come on. Who honestly thinks "openssl pkcs12 -export -inkey httpsiseasy.key -in httpsiseasy.pem -name httpsiseasy -out httpsiseasy.pfx" looks easy? What the hell is pkcs12? What does export mean? what's a key, pem, and pfx? What the hell is going on here? Anyone can copy and paste random commands on a command-line, but that doesn't mean you have any idea what's going on, and when you have problems, you're totally lost.

I could tell people "programming is easy!", but it would be a misleading, stupid thing to say. Writing code may be easy, but actually making a well-written, well-supported, bug-free program that works reliably outside my own computer is damn hard.

If I want more people to feel comfortable programming, I'm not going to lie to them and tell them it's easy. I'm going to tell them the truth: that it's difficult, but that there are ways to ease into it and become more comfortable with it over time, and here are the ways to do that.

Please don't lie to people to push your agenda. It sucks for the people who then assume you're telling the truth, and try to do X, and then run into problems, and curse the people who misled them. I have been in this situation many times and it always sucks. If something is hard, just say so.

This command line turns the two files everybody on the rest of the Internet cares about into the single file that Microsoft, in its unvarying quest to be different for no reason, has decided is the right choice for their software.

Specifically you've got a Private Key (which your servers need, but you mustn't show to anybody and so must be very careful to protect) and a Certificate (which is a public signed document and it's fine to show it to anybody, if you lose it you can just get another copy). Completely different security profiles so it makes sense to keep them separate even though you need both...

And then Microsoft says OK, let's use RSA's (the company not the algorithm) PKCS #12 to bundle these two items together into a PFX file. Now we've got a file that we'll call a "certificate" but in fact must be kept private at all times and not shown to anybody.

The worst thing about PFX / PKCS #12 is that as here you're usually going to see it because somebody skipped the vital step that actually makes any of Public Key security worth having. The Subject / Applicant should always generate their own keys. If you let the Certificate Issuer make the keys, the whole enterprise is basically a charade because instead of just acting as an Authority, now they're proxying for you entirely, if they want to impersonate you they can trivially do so at any time. Security goes out the window.

One of the great things about Let's Encrypt is that they illustrated that you can do this right (Let's Encrypt never sees your private keys, indeed if you mistakenly present them they'll revoke your certificate on the rationale that now the keys are revealed and the cert is worthless) without making the end user jump through technical hoops like typing in OpenSSL commands they don't understand. Your keys are made on your machine, but unless you care you don't need to know about it.

It was a rhetorical question. The fact that you needed 5 paragraphs to explain what is going on only proves the point being made — that it is not easy for anyone who doesn’t already have an intimate knowledge of PKI.

Sure, but this file and the command to produce it aren't anything to do with HTTPS really, they're artefacts of the Microsoft corporation's long-standing belief that refusing to interoperate helps you lock people into your ecosystem.

Troy wouldn't need this file, and thus this command, except that (as HN readers sometimes forget) he's a Microsoft MVP and so even when it's clearly the wrong choice he has to pimp the Microsoft approach if possible.

A better use of Troy's time as an MVP in _my_ opinion would have been to lobby Microsoft's IIS team to get ACME integration patched into recent releases ASAP‡. If this news item was "Troy's new video demos previously unannounced ACME integration for IIS 10" then it'd actually make an impact which this (unpaid) advertisement for Cloudflare does not.

‡ Bonus points since IIS is a commercial product, cut a deal to get your paying customers one free cert from a commercial CA using the new integration.

To use an analogy, this is like saying your two choices are: scrub and force your clothes through a mangle at home, or take them to the laundromat to use a machine.

I don't see why HTTPS can't be both simple and in-house, examples like Caddy come to mind (not that I've used or am promoting that specific program).

If I say "cleaning your clothes is easy", that's half true. Some clothes are easy to clean. Some require permanent-press slow-cycle cleaning and a low-heat gentle dryer cycle. Some require starching and ironing on various settings. Some require you to pay a service to do it for you (dry cleaning and steam pressing). As a young adult who had to learn by trial and error how to clean their clothes properly, I can tell you it ain't always easy.

If I say "HTTPS is easy", that's just false. There's no way for an average person to just figure out how to implement HTTPS by themselves. You need a special set of tools to be used in a certain way and you need to follow a guide with several steps, based on your unique use case. Or you can pay for a service to do it for you. Caddy may make things easy for some people, but some people won't be able to use it, and then HTTPS is hard again.

Can you learn how to do HTTPS, so that once you've done it a few times, it's easy for you? Sure! But the same goes for cleaning your clothes, writing a program, or even playing a piano. Do it enough times and it'll feel easy. That doesn't mean anyone can do it.

In this case, we're talking about having an automated service (Cloudflare) manage your HTTPS, not paying a human to carry out a manual HTTPS set-up. We're talking about a self-service laundromat, not a specialist dry-cleaning service. Just like I'm able to have an automatic washing machine in my home, I see no good reason why that automated HTTPS service can't be self-hosted, with no loss of ergonomics.

"Let's Encrypt doesn't help people redirect to HTTPS, add HSTS, configure the versions of TLS they support or fix HTTP references in otherwise secure pages."

So, this is only true if you squint at the problem. In one sense Let's Encrypt is ISRG's Certificate Authority project, and it doesn't dice vegetables OR pick up dog hair. But the wider Let's Encrypt ecosystem does help you with lots of this:

* If you use Certbot (the hugely popular EFF maintained "reference" client for Let's Encrypt) with popular servers like Apache you get options to switch on HSTS and CSP: upgrade-insecure-requests

* If you use a bulk host, as a great many of Troy's target audience do, they either already have a single button push (easier than Cloudflare) "Get me free SSL" or they could but they've chosen for commercial reasons not to enable it (in the very popular CPanel a hosting company has to go out of their way to ensure this is disabled if they want to instead upsell customers to paid certs and squeeze a little more cash out). "Go to Cloudflare" and thereby centralise things even further is definitely the wrong choice in this scenario.

So it's easy as long as you use Cloudflare, otherwise you still have to fight with private keys, csrs, permissions, hsts, http->https redirects and what happens when it expires or otherwise goes wrong.

Thanks Troy!

I wonder how highly you must think of yourself to adopt such a snarky tone when talking about someone who contributed so much to internet security.

"Thanks lbriner!"

Edit: Downvoters have spoken, and apparently the parent comment is the kind of content you guys want to see on this site. What a world.

Well the advice pretty much boils down to "HTTPS is Easy (when you pay someone else to manage it for you)!" And maybe that's good advice but at least be upfront about the actual statement.

"Web development is easy! (when you pay Squarespace)"

"Payment processing is easy! (when you pay Stripe)"

"Email is easy! (when you pay FastMail)"

The snark is well deserved. The article's title is condescending and wrong, setting up TLS isn't "easy," and claiming otherwise is unproductive.

This is nothing but a glorified ad for CloudFlare, and doesn't prove that HTTPS is "easy" but rather using CloudFlare's package offering is easier.

I like Troy Hunt, but this isn't one of his best.

> setting up TLS isn't "easy," and claiming otherwise is unproductive.

Well... it is if you use Cloudflare. But yeah, it should be httpsiseasyIFusingcloudflare.com or something.

> This is nothing but a glorified ad for CloudFlare

It's technically not though. He says they didn't even know he was making this. It's just a nice little free resource for anyone using Cloudflare or looking for a relatively easy path to https. For him, it'll drive some traffic back to his other site and build his brand a bit more.

It'll probably result in a bunch of Cloudflare sites beefing up their security a bit and capture some who haven't previously tackled https at all. Isn't that a good thing?

For what it’s worth, whenever someone seems arrogant on the internet, it’s easier to just ignore them than call them out. After all, they could be right.

Don't forget he still mostly recommends the configuration where you send your traffic unencrypted across the public internet from Cloudflare to you, breaking all your security guarantees and rendering the whole exercise pointless.

The fourth video in the series explains how to encrypt traffic between Cloudflare and the host server.

Also, the article kinda covers this already:

> And before anyone loses their minds over the entire network not being encrypted or Cloudflare being able to MitM the traffic, have a read of CloudFlare, SSL and unhealthy security absolutism.

https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-securi...

I wouldn't say it "covers it," more "glosses over it rapidly."

"Perfect is the enemy of good" is a legit problem we should avoid (i.e. not using HTTPS at all because CloudFlare isn't perfect) but the benefits and drawbacks should at least be discussed.

For example I think an insecure back-channel between your personal blog and CloudFlare is likely fine, but your eCommerce business, perhaps not.

ACME clients like Certbot can and do handle a lot of that for you as well.

Certbot isn't as universal as Cloudflare though, since you can't run it on a lot of shared hosting sites. It also requires a basic level of proficiency with the command line, which is unfortunately a bar a little too high for some users.

For shared hosting sites the answer is even easier: use a shared hosting provider that provides you with HTTPS.

> It also requires a basic level of proficiency with the command line

Sorry but when you lack all basic computer skills, you should _not_ be setting up TLS for a web server. No matter if you use Cloudflare or something else, have someone else do it.

Certbot definitely makes HTTPS easier. That doesn't necessarily mean the situation has improved enough to be called easy with a straight face, though.

IMO this is dangerously harmful advice. Even if you do the Full SSL (Strict) version, you are trusting CloudFlare with all data. It's probably fine if you are just doing a static site or something, but the fact that CloudFlare has access to users' passwords gives me the creeps.

(You are also trusting CloudFlare to generate the private key of your web server, which is no big deal if you are already using their services between you and the user, but might be more complicated if you decide to trust that cert for internal use.)

Ultimately I only recommend this if you want a fast fix to prevent public wifi operators from injecting stuff into your HTTP content. Any other use and you'll not be able to sleep at night wondering what kind of data CloudFlare has stored.

Ultimately Cloudflare is just another provider you have to trust if you decide to rely on them, just like your web host and anything else you use. For any non-trivial site you should do a risk assessment of the service providers, external javascript and other software you are using to determine whether the benefits outweigh the risks, and for the most sensitive use cases they should be kept to an absolute minimum. As you say, for a static site HTTPS terminated by Cloudflare is more secure than plain HTTP so it makes the most sense in that situation.

Hmm I guess you are right, I was just thinking of the simple case (run on your own metal, no external JS, etc...). I am just uncomfortable with the amount of data that passes through Cloudflare and especially the idea of depending on them just to gain HTTPS support (which you could do almost as easily in other ways). Cloudflare as proxy seems at odds with a decentralized view of the web.

Interestingly, the certificate Cloudflare attaches to the domain seems to contain all (or at least some subset of) the Cloudflare user's other domains in the Certificate Subject Alternative Name field. Managed to find he also owns https://troyhuntsucks.com this way.

Depending on your deal with Cloudflare (ie how much you're paying them):

1. You may share a Cloudflare issued (deal with Comodo) cert with arbitrary other Cloudflare customers. This illustrates that only Cloudflare is ensuring your data isn't muddled with data from those other customers. But to be fair in reality this is true in all cases because of how Cloudflare actually works.

2. Your sites may get their own cert, only your names appear in the cert but it's still issued by Cloudflare using Comodo and isn't really "yours" in any sense.

3. You sort out certificates and Cloudflare uses the ones you provide for your sites.

If it was easy, you wouldn't need a webpage with a configuration video tutorial series to convince people of the fact.

I wonder the percent of HTTPS websites on Cloudflare that are using browser <=HTTPS=> CF <=HTTP=> webserver.

It's also made easier by awesome tools like Mozilla's config generator: https://mozilla.github.io/server-side-tls/ssl-config-generat...

Strange, my browser reports that https://httpsiseasy.com/ is not secure (both Firefox and Chrome). Maybe its because I'm accessing it behind a corporate firewall but https works properly with other sites.

No it is not easy at all. I have had a very bad experience with trying to support https on my simple golang server that just needs to serve a couple of jsons. I gave up and switched the whole thing back to http (because mixed is apparently worse than no https for some reason known only to Google and Mozilla).

Reply on news.ycombinator.com