National Firearms Museum, NRA HQ. Fairfax, VA, USA. October 2, 2012. Security

For reasons of tinfoil hattery, and just for fun, I wanted to see how far I could take "security" features on a functioning website.

These are all the things I’ve enabled so far:

  • TLSv1.21
  • Certificate using Let’s Encrypt CA.
  • Ephemeral elliptic-curve diffie-hellman key exchange.
  • Signature validation using ECDSA.
  • A block cipher using AES-256 in Galois/Counter mode.
  • Message authentication using SHA-384.
  • OCSP “must-staple” extension on the certificate.
  • OCSP stapling (unless you can’t read this).
  • TLS extensions for certificate transparency.
  • DNSSEC implemented.
  • DANE/TLSA2 active.
  • DNS Certification Authority Authorization (CAA) record configured.
  • HTTP Strict Transport Security.
  • Non-permissive Content Security Policy set up.
  • Disabled MIME-sniffing.
  • Browser XSS protection enabled.
  • Frames only allowed with ‘SAMEORIGIN’ policy.
  • HTTP/23.
  • ALPN (like, obviously).
  • SSHFP enabled for maintenance.
  • 2FA for password-based SSH logins.
  • Expect-Staple (report only)
  • Expect-CT (enforced)

What I still want to do:

  • TLSv1.3; I either have to wait for its official release or compile nginx against libnss. Neither option is very appealing.
  • Figure out how to switch from P-384 to Koblitz or Curve255194.

I don’t have the illusion that any of the above will keep anything safe or secure, and neither should you. While the front-end may be safe there is no way to guarantee the (physical) security of the system running this, much less a way for me to prove that it’s secure.

It is, however, fun to see how far you can push these things without significantly breaking anything. Sure, you may not be able to read this site with Internet Explorer 6 but I’d consider that a feature more than anything else. There is no excuse to still be running terrible cipher suites (I’m looking at you, every government, financial, and medical institution).

Death to all TLSv1.0s!

  1. RFC5246, section 9 requires TLS_RSA_WITH_AES_128_CBC_SHA, which is not enabled here. 

  2. I never know what it’s called. Whatever RFC6698 describes. 

  3. Or anti-security, really. 

  4. Because reasons5

  5. Not that I really understand how it all works.