Hacker News Reader

Comment by StavrosK | Hacker News Reader

> It is clear that the cost and bureaucracy of obtaining certificates was forcing many websites to continue with the insecure HTTP protocol

I never realized this so clearly, but it's true. The biggest hindrance to security until LE was that certs were expensive and hard to install. I don't think it was so much the former as the latter. I'd gladly pay 10% more for my cert if it meant my server could renew automatically without me touching it at all.

Then again, for small things, like my home computer that I want to access some stuff on but don't want to pay $10 for, self-signed was fine, so I guess the price was a problem, to a degree.

View on HN

> I never realized this so clearly, but it's true. The biggest hindrance to security until LE was that certs were expensive and hard to install. I don't think it was so much the former as the latter. I'd gladly pay 10% more for my cert if it meant my server could renew automatically without me touching it at all.

Absolutely! Every time I had to create a CSR and install an SSL certificate on a server (having done it before in the past), I felt repeatedly terribly painful the process was.

I've wondered if this issue could have been solved a long time ago by commercial companies (the way LetsEncrypt solves it or similar), it just wasn't as good business :-)

Heh. If the CAs had done this ages ago the cost of certs would have collapsed. I can't help but think that collusion between the CAs was a regular thing to prevent something like LE from happening in order to prevent the business model from souring.

SSLMate has been doing that for a while.

I'd imagine so. I also like the approach that Amazon has taken with its recently launched AWS Certificate Manager. You can create as many SSL certificates as you like free of cost, even wild-card ones (which if I am correct Let's Encrypt does not support yet), and the AWS Certificate Manager takes care of the rest. The only restrictions, off the top of what I've read, are: 1) You have to be using the AWS infrastructure; b) You'd have to use their load balancer or CDN solutions, against which the certificates are placed.

Certsimple does autorenewal.

https://certsimple.com/

I personally find the hassle of installing, configuring and, crucially, testing, both LetsEncrypts scripts, and an accompanying cronjob, much more work and worry than a static nginx ssl config.

What are you talking about? My nginx ssl config is static as well. It looks at a specific path for my certs, which just happens to be a symlink managed my by letsencrypt tooling.

You're going to have to renew anyway. Previously you would have to remember to do that once a year, or maybe once every two years. Now let's ignore the security implications of having certificates that are valid for a year for a moment, and just focus on the actual work. Every year, you have to request a new certificate, wait for your certificate authority, upload the new certificate to the server, reload your webserver, check if everything works.

With LE, you do all of that once. You set up the tooling and the cronjob once. You make sure it works once. And you're done. No more hassle.

"Once" assuming nothing randomly breaks while you're not looking. What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date? What if one of the (Python?) dependencies has a bug or breaks? What if LEs servers are being DDoS'd? Can you enumerate and account for all the failure scenarios? I've already botched things with acme-tiny&LE in several different ways.

I'm not claiming these risks are that significant, but given that LE takes just as much time and effort for initial set-up as a standard multi-year cert, if not more, I think the mantra "some risk of failure is more risk of failure than no risk of failure" is something worth baring in mind.

And I'm not convinced having 90 day certs is a huge security win. Not only can someone do a lot of damage in 90 days, but your private key (the important bit) can't be rolled every 90 days anyway without integrating your rollover scripts with your HPKP config. If you botch that then your visitors can't come back to your website until the pin expires. Scary. Site ending scary. And if you're not using HPKP then i'm not even going to debate the security pros and cons.

On remembering to renew certs... there are many many services out there to send you reminders. Pick 2 or 3 and use them all. Or use a CA that sends reminders.

I'm glad LetsEncrypt exists, but let's not treat it like the be-all-and-end-all.

  given that LE takes just as much time and effort for
  initial set-up as a standard multi-year cert

I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH - i.e. every server will configure itself right on first launch and keep itself that way.

It's just going to take a long time to get there :)

> I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH

It already is. Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception. That's the security model of SSH, and has the same assurances. It's just a terrible comparison. We can do better.

A better comparison would be with DNSSEC...

The way to simplify TLS deployment, while getting a better level security as DV CAs, would have been DANE. DNSSEC has an unfortunate reputation as being hard to setup ("pdnssec secure-zone mydomain" is not hard), but it also has exactly the same X day rollover key problem to solve as LE. Solving it once instead of twice would have made a lot of sense.

The symmetries between DNSSEC and LetsEncrypt are striking. Your account key is your KSK. Your cert is your ZSK... but instead of your webserver (in DNSSEC, your DNS server) doing rollover for you, you're depending on a pile of scripts, leaning on an already insecure DNS, and setting it up is still, comparatively, a pita.

> Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception.

Don't do this. If you have to ask your users to add an SSL exception you're doing it very wrong.

He was comparing the tls equivalent of how SSH works. First time you connect to an ssh server, you have to accept the host key, which most people do not (and in most situations, can not) verify.

As the Caddy server linked in another comment shows, nothing in LE requires you to depend on a "pile of scripts" to do roll-over for you, it's just early days.

Yes, there will be products to make this simpler, but the point is, unless you are willing to grant LetsEncrypt a DV cert monopoly, to the exclusion of all others (or at least those not compatible with their API), then, in general, it can never be as easy as just turning it on.

DNSSEC puts the CA monopoly in the DNS. There is no API for a hypothetical web server using DANE, because there's no need for periodic domain validation. Of course, DNSSEC is a disaster, so it's a non-starter... but I'm still going to lament the fact that everything is terrible.

Since LetsEncrypt's API protocol is being standardized through the IETF (https://tools.ietf.org/html/draft-ietf-acme-acme), there's no reason any new competing free certificate providers can't be compatible with it. In the long term, if more show up (and I wouldn't be surprised if some existing CAs refocus their business on EV and start offering free DV certs through ACME), I see no problem with software giving the protocol a "monopoly", in the sense of building in auto-configuration support for it.

> What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date?

That's why I renew them a week in advance. I set up Nagios checks which alert me when a certificate is not renewed. Those were already in place before LetEncrypt since human error is just as likely as a script breaking.

I renew every month and have not hit their rate limits. That way, even if the cron job doesn’t fire and I don’t notice, there is another chance a month later.

Let's Encrypt renews certificates after 60 days by default, giving you a 30-day grace period for outages, etc. Use a daily cronjob and monitor your certificates. Setup alerts if your certificates are closer than, say, 25 days to expiration. This should cover temporary outages, bugs, etc. - and the monitoring bit is no different from what you should already have even with manual renewal.

run it @weekly

it's what I do

> What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date? What if one of the (Python?) dependencies has a bug or breaks? What if LEs servers are being DDoS'd? Can you enumerate and account for all the failure scenarios?

I run my cron job[1] every hour. It checks for the expiry of my existing set of certificates and has a configurable parameter as to how soon before expiry to renew them.

[1] https://github.com/frutiger/concorde

Nagios will tell me when my certificate is a month within expiring. This is a standard nagios plugin. The cronjob runs nightly, checks if renewal is necessary (once a month, certificates valid for 3 months, so will renew when 2 months are still left) and then does its thing.

I think you are underestimating the cognitive burden this added complexity puts on your ops person (maybe yourself)

I know for me, it was a choice between farting around with lets-encrypt for hours, or a $40 wildcard cert. so I went with the $40/year cert instead.

There are just too many choices for lets-encrypt with no super-simple how-to for people who don't know this stuff (like myself).

I thought the same, until I actually took it upon myself to actually try LE. 15 minutes later, I had all my sites on LE, automatic renewal configured. I'm looking forward not having to sign in to some website, cut'n'paste certificates around, convert to/from PEM, figuring out what the correct chain is this time, etc.

I guess I'm stupid then, because I spent more than an hour trying to figure an easy way to add these to my auto-provisioned servers before giving up and using the static cert instead.

Can you update the certificate without taking down your nginx server? I assume you need port 443 for LE to verify your domain, right? Can you use a different port?

sure - run the renewal from a different server

You can do it on the same server without downtime by using the "webroot" method of the LE client.

Yes, use the "webroot" method of the official Let's Encrypt client.

I see, thanks. I use the docker container "version", so I assume I have to somehow mount a volume to the container, that's also accessible from my nginx ( or whatever ) container, so it can serve the static file LE creates. Is there something more to it?

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

I'm in the same boat - especially because I need wildcard certificates (or just lots of certs).

I'm thinking the only thing that would really fix this is an nginx module that would automatically fetch certificates for domains when they're first requested via SNI. First hit takes some time, then it's cached and refreshed once a month or something... it would effectively mean 0 configuration SSL for all new domains.

Wouldn't work, sadly you're limited to 5 requests per apex per week.

If you can use OpenResty (nginx+Lua), then that's exactly the approach I've taken for a plugin I've been developing recently (SNI, on-demand, and caching): https://github.com/GUI/lua-resty-auto-ssl There's still a couple loose ends to tie up, but we've been using it on production for a few weeks now, and it's been refreshingly nice to not worry about SSL for new domains.

Regarding the 5 requests per week, I believe that's only for repeated re-issuances of the same domain. As long as you cache the certs, then this shouldn't be an issue. Registering new certificates for new domains is limited to 500 per 3 hours: https://community.letsencrypt.org/t/rate-limits-for-lets-enc...

that has to be one of the dumbest things I've read all year.

this is too hard: https://antipaucity.com/2016/02/26/automated-lets-encrypt-ss... ?

You're right, even with Let's Encrypt HTTPS is still more work than speaking insecure HTTP. But it's a brand new project, and we're working to ensure the amount of effort involved is monotonically decreasing.

In the next few months we'll be shipping an Nginx installer plugin and model renewal scripts for operating systems to provide native automated renewal with their packages of the client. Both of those should help to reduce the amount of work for your use case!

> I'd gladly pay 10% more for my cert if it meant my server could renew automatically without me touching it at all.

I wrote a server that does this. Would be happy to have your feedback sometime: https://caddyserver.com - here's how it works with regards to Let's Encrypt certs: https://www.youtube.com/watch?v=OE5UhQGg_Fo&t=32m

Found this tutorial yesterday about how to do it with letsencrypt https://www.digitalocean.com/community/tutorials/how-to-secu...

I use simp_le for that. I more meant "I'd have paid a CA 10% more for automation", but that ship has sailed now that LE has launched. I'm probably not going to be using anything else any time soon.

Oh, I've downloaded Caddy and used it a few times, I love it but haven't switched anything to it yet.

To me, the killer feature right now is that I can just drop it in my /usr/bin directory and have a performant HTTP server in the current dir with just one command. I don't use the LE integration (even though I love the feature) because I haven't deployed it in anything outward-facing.

One small nit would be that I'm not very clear on how the LE fetching is done (where all the files are placed). The docs do mention this, but I left with a feeling that I was still not very clear on where the files go after reading it. Other than that, great job on Caddy!

Yeah. I was really against SPDY/HTTP2 only supporting encrypted websites until Let's Encrypt came along, as it would have "forced" all the small sites to keep using HTTP 1.1 forever. Now I don't mind the requirement at all.

https://news.ycombinator.com/item?id=6724292

From what I got, it forces opportunistic encryption only. If there is no special signed cert available, it just generates one randomly and uses that. Unsafe against people who can modify your connection, but it protects against passive eavesdropping.

All major browser vendors decided not to implement opportunistic encryption in HTTP/2.

So they force either a valid cert or nothing? Not even unencrypted http/2? Because that would be quite awesome.

Edit: are there statements where they say they don't intend to implement it ever, or is it just not supported yet and e.g. Microsoft might still implement it later to please some enterprise stakeholder?

According to this[1], that's a permanent decision. Given that both Google and Mozilla have discussed plans that would eventually mark http:// as unsafe in the UI, I don't think that decision is going to change.

[1]: https://daniel.haxx.se/blog/2015/03/06/tls-in-http2/

Well there is a difference between unsigned encrypted and unencrypted, I'm not saying marking http:// as unsafe implies that they'll always regard unsigned encrypted as completely unprotected, especially with closed source browsers (or browsers where development is a closed process).

Thanks for all the information though! :)

From the point of view of an active MITM attack there is no difference between unsigned encrypted and unencrypted.

I tried to get SSL cert for my fathers company and different kinds of certificates just scared me. Do you know there is a kind of cert where you need to go in person with your ID and register yourself? I'm currently using LE for 6 domains, 2 of them joined as first 100 LE domains, before LE was supported by Ubuntu.

However, imho, he biggest reason to ever use self signed is that you can set expiry @2099 and it won't degrade anything.

1. You'd have install the custom CA in all devices. Ever tried it on Android? The "network may be monitored" warning doesn't go away.

2. If the certificate is ever compromised, you'll have to keep it in the revocation list forever, or replace the entire CA.

(And I hope your CA contains a DNS name restriction.)

>1. You'd have install the custom CA in all devices. Ever tried it on Android? The "network may be monitored" warning doesn't go away.

This is the most annoying part of using certs for Radius authentication with Android. Either you self-sign a cert and forever get these warnings, or you let someone else sign your cert and then that CA can issue device certs for your domain.

At least modern Android version support setting the CA certificate in the wifi settings.

(And then there's the university way of things: just run your own trusted (!) CA ;-) (e.g. in Germany: signed by DFN)

And hosting companies selling certs are incentivised to not provide HTTPS by default.

The number of not https wordpress admin pages and plain text ftp logins still in regular use is chilling and directly attributable to this misaligned incentive.

There's an oft-neglected issue with this. From experience, when a hosting company supplies an SSL certificate to a customer, here's the usual process. The first thing that happens is the site totally breaks because browsers won't render mixed content.

So the customer calls their developer and their developer calls the host and insists it's a server problem and someone spends an hour or more explaining what mixed content is to a developer and how to fix it.

Then someone runs it through the SSLLabs test and decides they don't like seeing RC4 supported. So you provide some warnings regarding it, confirm, and then oblige, but then you get angry, aggressive emails because their entire office uses Windows XP and their website doesn't work.

A company can burn hours on every individual SSL deployment. There's plenty of unfortunate incentives against hosting companies.

Reply on news.ycombinator.com