OverEncrypt: going beyond LetsEncrypt's HTTPS security defaults | Hacker News Reader

OverEncrypt: going beyond LetsEncrypt's HTTPS security defaults

gist.github.com

126 pointsmapmeld15 comments

These HPKP instructions are rather dangerous (as in: more dangerous than they have to be).

The hash is for the ISRG root certificate, which is not widely trusted yet. While an ISRG-signed intermediate certificate is available, all clients currently default to the IdenTrust-signed intermediate, and even if you decide to use the other intermediate instead (or both, which most browsers can handle), that doesn't guarantee that browser build a trust path through that intermediate - it might have the other one cached from a different site. In other words, the second pin would almost never be satisfied, which means you're screwed once your private key is compromised or changes. Screwed as in your domain is bricked for up to 30 days with this max-age setting.

A slightly better approach would be to pin to both the ISRG and the IdenTrust root[1], plus your private key and a couple of backup keys that you keep offline. One or two backup pins to other CAs couldn't hurt either. Oh, and best run with Report-Only for a while.

[1]: https://www.identrust.com/certificates/trustid/root-download...

This is rather overly complicated and should only be used for test domains you do not care about.

Much easier and very effective is to use the apache2 or nginx config file options to manually disable sslv3, tls1.0 and tls 1.1. Permit only TLS 1.2. If you want to, manually specify the preferred order or crypto.

Any modern browser supports TLS 1.2 just fine. I've done this for every httpd I admin and it has had no effect on reachability.

How are you measuring the effect on reachability? My companies network filter can't seem to understand cloudflare certs with their 50+ other domain names in there, and so clients can't connect. If you have HSTS on you can't even fall back to http. So without a phone call to IT to our provider, people just aren't going to that site.

That kind of thing seems impossible to measure.

99.5%+ of browser user agents are something released in 2010 and later that understand TLS 1.2 just fine.

But what if it's not enabled? We see traffic from newish IE browsers that have TLS 1.1 and 1.2 turned off. We actually got user complaints that one of our sites stopped working when we turned off TLS 1.0.

I have no idea why they would be set up that way, but it's clearly out there.

Windows 7 does not default to TLS 1.1 and 1.2 enabled.

While this can enabled via GPO, I really wish MS would release a patch that forces these to be on. There is no reason not to at this point.

Maybe when it initially shipped, but unless somebody has been absolutely ignoring all the last 6 years of updates, the version of IE that comes with Win7 is very much TLS1.2 compatible.

Read my post again.

TLS 1.1 & 1.2 are not enabled by default therefore will not work regardless of compatibility. Try it.

Your best option is probably to read, understand, and use the configs at https://cipherli.st

Anyone else notice the SysV subtlety on the bottom?

The “service” command is not SysV specific; it’s general, and will work under any init system, including systemd.

How do I get it working on my arch setup? I think ubuntu provides something that still works with systemd, but is that true of all distros?

I don’t know anything about Arch. Ubuntu, as usual, probably got it straight from Debian. Upstream code is here: http://savannah.nongnu.org/projects/sysvinit

According to `pacman -Fys service`, Arch does not ship the service(8) forwarder script, so you can only use systemctl(8). I've seen service(8) on at least RHEL and SLES, though.

However, emulating it should be as easy as

  $ cat >> ~/.bashrc
  service() { systemctl $2 $1 }

The reason the 'service' command was introduced was to allow an abstraction between System V, systemd, upstart and all other service managers.

`/etc/init.d/nginx restart` is a System V sublety.

Reply on news.ycombinator.com