1. 37
  1.  

  2. 21

    FWIW, Plex had an interesting workaround for the issue.

    1. 2

      I am curious how much they pay Digicert to get a wildcard certificate per user. At $DAYJOB we tried to negociate something similar and it ended up being prohibitively expensive.

      1. 1

        It looks like Digicert has signed a CA-cert for them. If you have the dough, CAs will let you have one.

        1. 1

          Ah, yes, I don’t think we meet all the requirements yet but that’s probably the way to go.

    2. 5

      Happy to see the issue getting public attention. It’s a grim reality known to device vendors: HTTPS is effectively unusable in private network applications, while there is tremendous market pressure to provide Web configuration interfaces. Ends up in tons of insecure systems shipped for no good reason whatsoever (and practical standards dysfunction is not a good reason).

      1. 3

        This is freaking brilliant, but now I’m curious: could HTTPS Anywhere do something similar, but generically? I can imagine ACME being altered to allow local host certificates based on MAC with very short TTLs, for example.

        1. 2

          I’m generally sympathetic to Mahmoud Al-Qudsi’s position here but there appears to be several alternatives that I think are very reasonable.

          1. D-link and others register a domain name that resolves to 192.168.1.1 or equivalent. For the general user this is probably a big user experience win anyway.
          2. Corporate networks install their own trusted root certificates.
          1. 4

            D-link and others register a domain name that resolves to 192.168.1.1 or equivalent. For the general user this is probably a big user experience win anyway.

            If they register a single domain name, doesn’t it means the device on your local network has the private key for the corresponding certificate, which means it is compromised?

            1. [Comment removed by author]

              1. 1

                They could generate a new cert for every device they sell, each for their “gateway” hostname, so that there isn’t one global key for all Linksys routers. You’re still always going to have to have a private key on the router, though.

                1. 1

                  Yes but don’t worry … those router admin pages are generally not behind SSL :-)

                  1. 1

                    If I read it right it is for a name that includes a device fingerprint as well as the IP address, so they can’t be reused.

                  2. 1

                    From a generic vendor POV, none of that is very reasonable.

                    1. Some places have no guaranteed Internet access. On some of them it is even prohibited (e.g. industrial applications) and considered a vulnerability.

                    2. The typical procurement/delivery/service subcontracting structure in large industrial projects (think oil rigs, power plants, mines, tunnels) makes maintaining your own DNS/CA ineffective and impractical. It requires getting everyone, from e.g. government subcontractors drafting requirements for the bidding round through foreign contractors hired 4 levels down in the bigcorp management hierarchy to actual device vendors to understand, implement and maintain this infrastructure. Typically it’s thousands of configurable devices sourced from dozens of vendors, with vastly different configuration/provisioning implementations - and most of them don’t have elaborate setup options like say Cisco IOS systems do. How do you provision your cert to an arbitrary vendor’s PLC or industrial endpoint switch? What if you have two thousands of them? The setup would take longer than configuring them in the first place, and further maintenance (these certs should expire, don’t they?) is a nightmare. So inevitably, solutions for these projects converge to lowest common denominator, which is more often than not is simple airgapped L3/L2 network split into a bunch of subnets and no trust chain whatsoever.