
OverEncrypt: going beyond LetsEncrypt's HTTPS security defaults - mapmeld
https://gist.github.com/mapmeld/a9bcac46d1f486f81664814a799e5897
======
pfg
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...](https://www.identrust.com/certificates/trustid/root-
download-x3.html)

------
walrus01
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.

~~~
Already__Taken
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.

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

~~~
brainfire
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.

~~~
newman314
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.

~~~
walrus01
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.

~~~
newman314
Read my post again.

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

------
l-p
Your best option is probably to read, understand, and use the configs at
[https://cipherli.st](https://cipherli.st)

------
mangix
Anyone else notice the SysV subtlety on the bottom?

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

~~~
captn3m0
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?

~~~
majewsky
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 }

