The “Happy Path” to HTTPS

While he's talking about cloudbleed that affair does raise questions as to their reliability. A spur of the moment decision like that doesn't give much confidence in their integrity. It's fully understandable of course (they're Nazis) but it was still a decision to terminate service with no warning. You're probably safe from such things if you're not a Nazi, but it's not 100% safe.

I think you should at least take a good look at how they handled that one catastrophic failure, and also consider whether it was the result of an unfortunate accident or a momentary lapse, rather than just the first of many failures-waiting-to-happen that actually happened.

I would totally agree with you had they not blown their chance to handle this responsibly. The finger pointing and downplaying of what had happened totally destroyed my will to give them the benefit of the doubt in that respect.

I see CF as a step backwards at this point. I'm sure they have learned their lesson but their response was absolutely terrible and that makes me wonder about their leadership. As long as that doesn't change there is a good chance that there will be a repeat at some point and so I'm not comfortable with placing that much trust in them.

Fortunately I don't need them, if you are in a position where a CDN is a must then that is a decision you're going to have to live with (or find another one than CF).

I’m fairly confident the full SSL option is free.

MITM is a lot more work for a lot less payoff. Say you found a small ISP that allows DNS cache poisoning. Once you succeed you get X users over a day or two. It's still a fraction of users of a small ISP. With a botnet, they can collect hundreds of thousands to millions of users, and all they have to do is own one site. Or they can send spam all day and not have to own anything.

Of course MITM is a concern, it's just not the biggest concern, IMO.

Lets Encrypt works fine for personal sites, etc. but it absolutely crushes the use case of being a large scale service needing to support thousands of individual sites, each with their own SSL cert.

Heroku, Hubspot, Shopify, etc. all have implemented LetsEncrypt and UX wise, is now pretty much just the default.

Don't forget the 90 day bot generated event to update your cert

Yeah for $9 a year they are getting the service where when their cert expires they have to manually go through all the process again. Making sure to manually create a signing request and keeping keys secure.

For $0 a year with letsencrypt you can have it autorenew and not need any support.

Also what support would a https provider provide other then here are the commands to generate a csr?

We had a lengthy discussion today in the SignalK project (http://signalk.org/) about exactly that.

The best approach I've seen so far is the way Plex has done it: https://en.wikipedia.org/wiki/Plex_(software)#SSL

I've never found a good, single document that covers self-signed certificates well. Googling for guidance results in a lot of different ways to do it, and if you don't find one that does exactly what you want, trying to combine that one with a different one that does the things missing from the first might not work because they are using different approaches.

I did manage to glean enough to make a pair of simple scripts that seemed to work for my needs, but have no idea if they are actually right, or if putting together things from different guides messed things up.

Here's the script I use for my root certificate (makeroot.sh):

  #!/bin/bash
  NAME=${1:?Must specify name for root}
  CN=${CN:-My Little Certificate Authority}
  O=${O:-My Home Network}
  C=${C:-US}
  DAYS=${DAYS:-365}
  PW=${PW:--aes256}
  SUBJ="/CN=$CN/O=$O/C=$C"
  openssl genrsa $PW -out $NAME.key 2048
  openssl req -x509 -new -subj "$SUBJ" -nodes -key $NAME.key -sha256 -days $DAYS -out $NAME.pem

So suppose I'm setting up a private certificate authority for my iot devices. I would do:

  $ ./makeroot.sh iot

That will make iot.key and iot.pem.

To make a certificate signed with the iot certificate I use this script (makecert.sh):

  #!/bin/bash
  NAME=${1:?Must specify name for cert}
  ROOT=${2:?Must specify name for root}
  CA="-CA $ROOT.pem -CAkey $ROOT.key -CAcreateserial"
  O=${O:-My Home Network}
  C=${C:-US}
  DAYS=${DAYS:-365}
  SUBJ="/CN=$NAME/O=$O/C=$C"
  openssl genrsa -out $NAME.key 2048
  openssl req -new -key $NAME.key -subj "$SUBJ" -out $NAME.csr
  openssl x509 -req -in $NAME.csr $CA -out $NAME.crt -days $DAYS -sha256
  rm $NAME.csr
 

E.g., to make a key for an iot doorbell:

  $ ./makecert.sh doorbell iot

That makes doorbell.crt and doorbell.key.

That worked well until the need arose to make an SNI certificate. I had expected that it would just be a matter of slightly tweaking makecert.sh, add a few more arguments.

But all I could find in the way of examples took a different approach, where most of the information is passed in a config file, and some of the guides I read indicated that you cannot pass the names on the command line to openssl when doing SNI. Anyway, this is the script I came up with (makesni.sh):

  #!/bin/bash
  function makeconf {
      CN=$1
      DIR='$dir'
      shift
      cat > tmp.conf <<HERE
  [ req ]
  distinguished_name = dn
  req_extensions = req_ext
  unique_subject  = no
  prompt = no
  
  [ ca ]
  default_ca = tzs_ca
  
  [ tzs_ca ]
  dir = ca-files
  private_key	= $DIR/iot.key
  certificate     = $DIR/iot.pem
  new_certs_dir   = $DIR
  database	= $DIR/index.txt	# database index file.
  unique_subject  = no
  default_md	= sha256		# use public key default MD
  serial		= $DIR/iot.srl 		# The current serial number
  email_in_dn     = tzs@mouse-potato.com
  default_days    = 365
  
   
  [ dn ]
  CN = $CN
  O = My Home Network
  C = US
  
  [ policy_anything ]
  countryName		= optional
  stateOrProvinceName	= optional
  localityName		= optional
  organizationName	= optional
  organizationalUnitName	= optional
  commonName		= supplied
  emailAddress		= optional
  
  [req_ext]
  HERE
  
      if [ -n "$1" ]
      then
          cat >> tmp.conf <<HERE
  subjectAltName = @alts
  
  [ alts ]
  DNS.1 = $1
  HERE
          shift
      fi
      POS=2
      while [ -n "$1" ]
      do
          echo "DNS.$POS = $1" >> tmp.conf
          shift
          POS=$((POS + 1))
      done
  }
  
  NAME=${1:?Must specify name for cert}
  makeconf $*
  openssl genrsa -out out/$NAME.key 2048
  openssl req -new -key out/$NAME.key -config tmp.conf -out out/$NAME.csr
  openssl ca -policy policy_anything -out out/$NAME.crt -config tmp.conf -extensions  req_ext -infiles out/$NAME.csr
  rm out/$NAME.csr tmp.conf
  

This assumes a directory, ca_files, that contains iot.key and iot.pem, and also an empty file named index.txt. Also it assumes in out directory.

To make an SNI certificate for a device that has three hosts, named fridge, freezer, and icemaker:

  $ ./makesni.sh fridge freezer icemaker

That will make fridge.crt and fridge.key in the out directory, and that will have fridge as the CN and freezer and icemaker as subject alternate names.

OK, so now I can put doorbell.crt and doorbell.key on the doorbell device, and fridge.crt and fridge.key on the device that has the fridge, freezer, and icemaker sites, and all is well, right?

Well...I also need to give my browsers iot.pem so they will recognize those other certificates. I'd also like curl and Perl and Python to recognize them, so that I can write scripts that do fancy iot things.

I didn't find any good guide to installing the CA certificate. From a bunch of Googling I came up with:

• On Debian Linux, copy iot.pem to /usr/local/share/ca-certificates, and change the extension to .crt.

Run update-ca-certificates.

That should make it available to Perl, Python, and curl.

For Chrome and Firefox, find their certificate management dialogs and use them to add the certificate.

• On OS X, double-click iot.pem. That should open Keychain Access. Let it import the certificate. Set it to be trusted for SSL. That will make it work in Chrome and Safari.

For Firefox, same as Linux.

For Perl, do one of:

1. Set environment variable PERL_LWP_SSL_CA_PATH or HTTPS_CA_DIR to point to a directory containing iot.pem, or

2. Set the environment variable PERL_LWP_SSL_CA_FILE of HTTPS_CA_FILE to point to iot.pem, or

The first requires that the directory contain symbolic links of the form hash.N where hash is a hash of the certificate and N is a sequence number. You need two of these, because there apparently is an old hash and a new hash. 'openssl x509 -subject_hash -noout -in iot.pem' to get the new hash, and 'openssl x509 -subject_hash_old -noout -in iot.pem' to get the old hash. Or just go to the cert directory and run 'c_rehash .' and 'c_rehash -old .' and those will make all the symlinks for you.

For Python3, similar to Perl but with SSL_CERT_DIR and SSL_CERT_FILE as the environment variable. Same hash symlinks as Perl (although I think you only need the new hash).

For curl, "--cacert iot.pem" or "--capath <dir>" where <dir> is a directory with the certificate. Same symlink considerations as Python3. Or set CURL_CA_BUNDLE env variable to point to a bundle that contains iot.pem. A bundle is just a bunch of certificate fills concatenated.

• Windows, I have no idea.

The problem is browsers are deprecating feature if not https so those devices can’t use the features without https but there is no solution for them to use https

Thanks for the clarification. I did not realize that `upgrade-insecure-requests` applies cross origin. If you do not load any insecure content is setting HSTS and `block-all-mixed-content` the best strategy?