On Tuesday, 14 February 2017 17:55:18 UTC, Jakob Bohm wrote: > Unfortunately, for these not-quite-web-server things (printers, routers > etc.), automating use of the current ACME Let's encrypt protocol with > or without hardcoding the Let's Encrypt URL is a non-starter for anyone > using these things in a more secure network and/or beyond the firmware > renewal availability from the vendor.
Whilst I agree there are challenges, I think greater automation is both possible and necessary for these things. > On a simple network where public certs are acceptable, such devices > will often need to get renewed certificates long past the availability > of upstream firmware updates to adapt to ecosystem changes (such as > Let's Encrypt switching to an incompatible ACME version in the year > 2026 or WoSign free certs becoming a thing of the past in 2016). Ecosystem changes that make stuff stop working are much more likely to be algorithmic changes (Does your printer know SHA-3? Elliptic curve crypto? Will it work if we need quantum-resistant crypto?). > On a secure network, existence and address of each such device should > not be revealed to an outside entity (such as Let's encrypt admins), > let alone anyone who knows how to read CT logs. For such devices I > generally use an in-house CA which is trusted only in-house and uses > the validation procedure "The subject is known personally to the CA > admin and the transport of the CSR and cert have been secured by > out-of-band means" Like the manual verification of SSH host fingerprints, I fear such a system most often looks successful because it's not coming up against any serious adversaries rather than because it's actually implemented in a sound way. Unless everybody is very careful it easily becomes the Yale lock of PKIs, successfully keeping out small children and sufficient to show legally that you intended to forbid entry, but not exactly an impediment to organised criminals. Also it's weird that you mentioned transporting the CSR and certificate out of band. I can kind of get that if you take the CSR from the device to the CA issuer by hand then you feel as though you avoid MITM replacement of the CSR so it makes your reasoning about the Subject simpler. But why the certificate ? In this scenario (personal knowledge of subject's identity) I am currently fairly confident that something like SCEP is the right approach. As with your manual system I expect that SCEP will often be deployed in a fashion that does not resist attack, but in _principle_ it's possible to have this work well and unlike hordes of workers traipsing about with CSR files it might actually scale. > Similarly, it would be useful to have an easily findable tool/script > for doing ACME in a semi-offline way that doesn't presume that the ACME > client has any kind of direct control over the servers that will be > configured with the certificates. Such a tool could be installed once > by a site and then used to generate certs for the various "web-managed" > devices that need them. Probably for that type of environment you'd want to do DNS validation: That is, have your certificate-obtaining tool able to reach out to your DNS service and add TXT records for validation so that it can obtain a certificate for any name in the domains you control. Of course the parameters of how exactly this works will vary from one site to another, particularly depending on which DNS servers they use, and whether they're a Unix house or not. Also it matters whether you're going to have the devices create CSRs, or just inject a new private key when you give them a certificate. Here's an example of Steve, who hand-rolled such a solution, his approach also deploys the certificates via SSH but for the "web-managed" devices you mention that isn't an option and may need to remain manual for now. https://www.crc.id.au/using-centralised-management-with-lets-encrypt/ You'll also see people building on other Unix shell tools like: https://github.com/srvrco/getssl or https://acme.sh/ Inevitably an OpenBSD purist has written one in C that's split into a dozen privilege-separated components: https://kristaps.bsd.lv/acme-client/ And somebody who likes Python, but didn't fall in love with Certbot (the EFF's Python ACME implementation that was once the "official" client) wrote: https://github.com/plinss/acmebot _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
