Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Encrypt and Nginx – State of the art secure web deployment

letsecure.me

Post reply on HN
Print view View original

71–80 of 85 posts

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#71

Post by tokenizerrr »

click170 wrote: post #49
schoen wrote: post #25

It scared me to see that the author recommended running curl http://nginx.org/keys/nginx_signing.key | sudo apt-key add - (This adds a key or keys downloaded over an unauthenticated http connection to one's Debian keyring, allowing whatever keys the network sends back to authenticate any future package updates.) I wrote to the author with a note expressing my concern.

What bugs me is how prevalent that has become. I'm looking at you Jenkins![0] [0] https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenki...

Jenkins at least serves the key over HTTPS. Would you instead prefer they did not offer packages for your package manager at all? I sure wouldn't, I really appreciate those packages for easy upgrades.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#72

Post by lorenzhs »

alexpeattie wrote: post #68

You can create a more hardened setup by using a 4096 bit RSA key: /opt/letsencrypt/letsencrypt-auto certonly --rsa-key-size 4096 --server https://acme-v01.api.letsencrypt.org/directory -a webroot --webroot-path=$DIR -d $DOMAINS ...and using the secp384r1 curve for ECDHE key exchange: # in your nginx.conf ssl_ecdh_curve secp384r1; Arguably, the real state of the art is to use an ECDSA certificate. Let's Encrypt recent…

4096 bit RSA keys offer very little additional security (2048 is plenty for at least the next few years, and with a certificate that's valid for 90 days, there's practically no risk - you can rotate the key rather easily if something bad comes along), but has a fairly big impact on performance and battery life, especially on mobile devices.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#73

Post by realusername »

Here is also my config if anyone is interested (also A+ on ssllabs.com): https://gist.github.com/alex-min/158f35f604b24e163ae9, feel free to copy it. (or suggest improvements !)

I also recommand https://sslcatch.com which sends you a warning email if your certificate is about to expire. I have a crontab to renew it but this can be also helpful just in case.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#74

Post by e12e »

schoen wrote: post #25

It scared me to see that the author recommended running curl http://nginx.org/keys/nginx_signing.key | sudo apt-key add - (This adds a key or keys downloaded over an unauthenticated http connection to one's Debian keyring, allowing whatever keys the network sends back to authenticate any future package updates.) I wrote to the author with a note expressing my concern.

Also, while apt-key might handle random input fine, I'm concerned with anything that goes "curl http://example.com | sudo ...". In this special case, "apt-key add -" should avoid most problems - but I'd still prefer verifying the (possibly untrusted) gpg-key as a normal user, and then elevating to add what appears to be the correct key, and a valid gpg-key via apt-key add.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#75

Post by doublerebel »

pfg wrote: post #48
doublerebel wrote: post #47

Earlier quoted context omitted.

Yes, the API documentation is lacking especially with what we've gotten used to from Swagger markup and Stripe's API doc style. I have scoured for such an easy breakdown and found none. As a result I actually just implemented a new, clear, client for LetsEncrypt and have been documenting as I go. It's made me think we should have a Swagger or API Blueprint of the spec on github that everyone can keep up to date. What…

Are you referring to the server-side API the client is communicating with, or the internal API the client exposes? The former is documented in the ACME specification[1], currently being worked on by the IETF. There are many low-level ACME libraries for basically every language[2], and a pretty decent guide on writing your own client as well[3]. [1]: https://ietf-wg-acme.github.io/acme/ [2]: https://github.com/letsenc…

Thank you very much for these links. 3) is the closest to what I'm looking for, and really good! but is still an implementation and not a spec. 1) is fine for a spec for an internet committee who has to delve into every detail for standardization. But if a client can be written in 150 lines of code, there should be a much shorter version of the spec (only a couple pages) in a standard format. I should be able to easily write a client from a 3-page spec without looking at all the implementations.

All due respect to the client authors, but only a few clients are good. Many are very poorly written, which I do not trust for security. I believe the cause is not having a clear, short, standard modern spec.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#76

Post by smithclay »

mikewhy wrote: post #59
smithclay wrote: post #51

Recently went through a similar setup, but used Docker and some existing h2-friendly images. Think it's a nice way forward for deploying to production environments. Wrote about the process here: https://clay.fail/posts/hip-http2-using-docker/

I recently built docker-gen-letsencrypt[1]. It's the same concept as what you're using, but fully automated for getting certs. [1]: https://github.com/mikew/docker-gen-letsencrypt

That's awesome, will be updating the site to use your image this weekend. Like the support for docker-compose and the staging servers, too.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#77

Post by rlpb »

icebraining wrote: post #40
rlpb wrote: post #39

Earlier quoted context omitted.

Stick it on a keyserver, and then ask gpg to fetch it from that keyserver with the full fingerprint. Assuming that your instructions that include the fingerprint are secure (which they have to be, else the instructions could root your box anyway), then that should be reasonable. This does assume that gpg verifies that the key retrieved matches the ID requested, which I assume it does. Otherwise that'd be quite a seri…

The question is how to ensure you're getting the right fingerprint. If you have that, you can just as easily fetch the key using HTTP and verify it.

I covered that when I talked of the security of the instructions. The real question is how to ensure you're getting the right instructions, since they could direct you to download a different source entirely.

If you have ensured that you're getting the right instructions, and those instructions supply the right fingerprint, then you can be sure that you have the right fingerprint.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#78

Post by ivansavz »

matt4077 wrote: post #62
ivansavz wrote: post #54

Earlier quoted context omitted.

A dynamic script is handling all requests, so there is no "webroot" directory where you can put stuff for them to appear under /

You could quite easily add a location /.well-known rule to the server, right?

Oh yeah, I didn't know about this option. A static dir for /.well-known is a much more elegant solution than shutting down nginx... Thx for the pointer.

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#79

Post by nickpsecurity »

It's a nice tutorial. The title tripped me out, though: a common webserver + HTTPS + free certificate on Windows/Linux is "state of the art secure web deployment?" I'd hate to see what passes for average or (shudders) ancient.

In my mind, I'm seeing "state of the art" being more like a combo of Ur/Web for apps, robust implementation of OP2 web browser for client, lighttpd rewritten in Haskell, HTTPS component written in SPARK or Rust, all running on GenodeOS or CheriBSD in isolated partitions, C parts compiled with CompCert extended with Softbound + CETS, anti-fuse FPGA doing I/O offloading/mediation, and hardware done in Bluespec. That is state of the art with probably badass results. This submission is... more run of the mill. Immediately useful, though. :)

Re: Let's Encrypt and Nginx – State of the art secure web deployment

#80

Post by nickpsecurity »

toomuchtodo wrote: post #19
jcrawfordor wrote: post #15

Earlier quoted context omitted.

Without judgment intended, as a Linux sysadmin you should absolutely be monitoring mail to root. That is the standard place to deliver error output from unattended processes. You can easily /etc/alias it to something else if that's more convenient.

Sysadmin/Devops here. I send all root mail to Graylog.

That does look nice. Thanks for Graylog reference.
Post reply on HN