1. 12
  1.  

  2. 2

    How does plex do their ip address based certs? Is it just totally incecure over the internet?

    1. 2

      The proposal outlined seems hugely over complicated for what is - as the commentary suggests - almost a complete non-issue. I’m surprised it’s generating so much discussion, unless I’m missing something important.

      1. 3

        It seems like a real issue to me. How are people supposed to connect to devices on their local network?

        The past solution has been to use their desktop’s, laptop’s, or smartphone’s web browser to make an HTTP connection, via mDNS or to the device’s IP address. This had the great advantages of being simple , universal, and non-expiring. Unfortunately, browsers are increasingly restricting HTTP. Currently, many browsers will show scary warnings every time you try to make such a connection. This is annoying to people who know what’s going on, and a total deterrence to people who don’t. In the near future, browsers may disallow HTTP altogether.

        I know of 3 other solutions which are compatible with current and near-future browser security requirements:

        1. Devices can create self-signed certificates, but those are going the same way as HTTP – scary warnings in the web browser, which may soon become total stonewalls. It also requires more software and hardware than plain HTTP, and might one day become obsolete when browsers stop trusting the device’s SSL version.

        2. The connection can go through infrastructure on the internet, which allows for servers with real domain names to obtain real, normal SSL certificates and connect to the user’s computer and to their network gadget. This has the downside of requiring that the networked gadget be permanently connected (exposed) to the internet, and that someone has to maintain infrastructure in order for the devices to work. In order to avoid creating a botnet or a pile of e-waste, someone has to own and maintain the software for the devices and the central server, and keep the update mechanism working nearly perfectly.

        3. Network-gadget creators (including open-source communities) can produce special-purpose software for connecting to the device, and require users to download and run that. This may or may not actually be secure, but it can be made to work (on supported devices with supported operating systems that the user has permission to install/run software on) without having to jump through hoops like messing with DNS settings or installing certificates.

        OpenWRT mailing list user abnoeh has proposed a new, hybrid solution. The OpenWRT organization would be granted limited Certificate Authority from a sponsoring Authority, like Let’s Encrypt. The scheme takes advantage of the fact that many (most?) OpenWRT devices are home routers: connected to the internet, and located in between the open internet and the user who probably want to connect to/configure their router. The OpenWRT router is authentifiably assigned a certificate for a specific subdomain of openwrt.org, and intercepts and responds to outgoing DNS and HTTP(S) requests to that domain, basically acting as an authorized Man-In-The-Middle attack on openwrt.org.

        This scheme has the upsides of being currently technically possible, and working on many user’s devices without tweaking settings, installing custom software, or clicking through secutiry scarewalls. It has the major downsides that it needs support from a certificate authority, that it or the browser vendors could invalidate the whole scheme at any time, and that openwrt.org needs to take on the responsibilities of a certificate authority. It is also not a general solution to the problem of interacting with devices on the local network, many of which also run OpenWRT. As the world is being populated by more and more local devices, it would be great if there was an agreed-upon solution that wasn’t “connect to a central server on the internet”.

        1. 1

          Devices can create self-signed certificates…scary warnings…

          People might be doing this wrong. The way I’ve found to make this work is to:

          1. Create your own cert authority.
          2. Create a cert with the CA and another key.
          3. Add your CA to your keychain or certificates directory.
          4. Add the cert and key to your server.
          5. Add ip address of the device to your /etc/hosts/ of all your devices or do some dns stuff

          There is no scary warning when you do it this way rather than doing a self signed cert. Please note des3 is deprecated but works so look into openssl if you’re not going to use this for development purposes.

          Here are some things you can use:

          root_certificate_authority_creation.sh

          #!/usr/bin/env bash
          mkdir ~/ssl/
          openssl genrsa -des3 -out root.key 2048
          openssl req -x509 -new -nodes -key root.key -sha256 -days 1024 -out rootCA.pem
          

          create_root_self_signed_certificate.sh

          #!/usr/bin/env bash
          openssl req -new -sha256 -nodes -out coolbox.local.csr -newkey rsa:2048 -keyout coolbox.local.key -config <( cat coolbox.local.cnf )
          
          openssl x509 -req -in coolbox.local.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out coolbox.local.crt -days 500 -sha256 -extfile v3.ext
          

          coolbox.local.cnf

          [req]
          default_bits = 2048
          prompt = no
          default_md = sha256
          distinguished_name = dn
          
          [dn]
          C=US
          ST=California
          L=SF
          O=End Point
          OU=Testing Domain
          emailAddress=admin@coolboxbro.com
          CN = coolbox.local
          

          v3.ext

          authorityKeyIdentifier=keyid,issuer
          basicConstraints=CA:FALSE
          keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
          subjectAltName = @alt_names
          
          [alt_names]
          DNS.1 = coolbox.local
          DNS.2 = *.coolbox.local
          

          add_root_to_KeyChain.sh

          #!/usr/bin/env bash 
          # Uncomment the one you need and check the internet to make sure it's somewhat right
          # MacOS
          #security add-trusted-cert -k /Library/Keychains/System.keychain -d rootCA.pem
          #Debian
          #sudo cp foo.crt /usr/local/share/ca-certificates/foo.crt
          #sudo update-ca-certificates
          #windows, i think this works but I'm not on windows anymore.
          #certutil -addstore -f "ROOT" new-root-certificate.crt
          
          1. 4

            If I gave this list to my non-programmer friends, they would simply walk away, because this doesn’t mean anything to them.

            Next step, once you get the CA going, is to generate a request, generate a certificate, then install said certificate on the IoT device you have, so you can then manage it via a web browser …

            Look, I have set up my own CA to play around with this stuff. And so far, I have 8 scripts (totaling over 250 lines) to maintain it, and I don’t think I have it fully right.

            1. 1

              Seconding spc476’s comment: even with something like smallstep to streamline a local CA, it’s going to be beyond most non-programmers. And that’s before trying to roll it out to off-the-shelf IoT devices: see the Plex link in this thread.

            2. 1

              Your solution 1, the current situation, really isn’t a bad one in my opinion. Having to affirm that you trust a connection the first time you connect to a machine is a perfectly okay flow.

              It would be nice if HTTPS didn’t tightly couple authentication and integrity. In this particular situation, where we’re probably navigating directly to a local IP address, we want the later much more than the former but nevertheless have to drag in the whole CA system.