On 14/02/2017 22:03, Nick Lamb wrote:
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?).
Broken algorithms can still be used on closed networks where the
encryption is secondary to the perimeter protection. Biggest problem
would be Browsers aggressively removing algorithms by (once again)
failing to consider the intranet use cases.
The real world equivalent is the use of ultra-primitive locks on the
inside doors of a house, while using high quality locks on outside
doors (public servers).
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 ?
Cert transport is important only for the devices where PKCS#12
transport is the norm. Not every embedded CPU has a high quality RNG.
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.
Who said anything about hordes of workers? The process is centralized
with a small number of people completing the whole process. Process
would be different if the IoT devices did not pass through the central
office before deployment or if a huge number of devices needed to be
set up on an assembly line.
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
Thanks for the tips, this was really just a side-jab at the Let's
Encrypt homepage for not grouping ACME clients be their features, only
by their origin.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
