12 comments

[ 3.2 ms ] story [ 37.0 ms ] thread
I like TLS False Start and other, similar speculative algorithms. Speculative execution is especially interesting in circuit design!
SSL stapling can reduce the overhead as well, simple nginx config:

  http {
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/nginx/ssl/stapling.trusted.crt;
    resolver 8.8.4.4 8.8.8.8 valid=300s;
    resolver_timeout 15s;
  }
We https://commando.io use GoDaddy SSL (sigh, face-palm), so the contents of stapling.trusted.crt is:

   http://pastebin.com/0H0i09Pn
You really should use a local caching resolver, even if you set your upstream to google's resolvers.

Just install pdns-recursor and you're good to go.

Yes, and google will throttle you if you make too many requests.
If nginx caches for 300s and that's the only reason you are installing pdns-recursor, that's unnecessary technical debt in your production pipeline.
Agree, won't DNS do this caching automatically with valid=300s?
I believe that nginx will do the caching with valid=300s.

"DNS" does not let the client set the record TTL, and "DNS" in this case would be a round-trip request to the Google DNS servers listed in the config snippet - precisely what it was suggested be avoided.

On large deployments, every bastion (internet-facing host that handles traffic) should gets its own caching resolver and a copy of the internet-facing zones, pushed by puppet/chef. Helps a bunch w/ DDoS if the shop is too custom for CloudFlare || similar.
I added ocsp stapling to a new nginx based reverse proxy system at a shared hosting site. A few months later one of the sysadmins mentioned that it was now taking several minutes for nginx to restart and it was gradually getting slower.

Turns out whenever you restart nginx it fetches the ocsp information for each certificate one after the other. The system now had about 100-200 sites on it. I turned ocsp off and the problem was solved.

I still use it on Nginx systems that only have a couple of certs on though.