We have a really good system for setting up the FireBrick with a proper hostname on the internet and https using ACME and Let's Encrypt, but we have to take a step back here...
This is a problem for everything from WiFi APs, switches, routers, firewalls, and indeed any network devices, is how to get started, and is an issue that is going to be really hard to solve.
Most such devices need some sort of initial set up, and the way to do that is a web page. So how does that work?
http
The simplest is just http, so you may, for example, connect a FireBrick to a laptop and access http://10.0.0.1/ to talk to it. That works, but is insecure http.
Now, http works, and is a simple protocol and works when connected directly to the FireBrick via cable with no security issues. But it is something browsers are increasingly saying is BAD BAD BAD in red letters!
So not good. What would be better if a way to do https, somehow...
https
Using https is way better, it stops the browser getting upset. The problem is that there is no way to get a certificate for https://10.0.0.1/ for obvious reasons.
So what do people do - and to be honest, I am interested in feedback here.
What I have seen is devices that provide a certificate for their domain, some-ap.com. It will not match 10.0.0.1, but you can override on the browser to carry on. Oddly I see many that go for a non standard port as well like 8443 instead of 443 - why is that?
But nothing you do can actually guarantees the security, but you want the warnings to be minimal.
FireBrick
What we are planning to do is make a simple self signed cert to match the request, i.e. one for 10.0.0.1 if that is what you used. It means a warning, as you would expect, but you can then access the FireBrick via https, and avoid passive snooping. That is a step more than just using http.
The future?
We do need something!
Maybe some flag in the self signed cert? Maybe something that means browsers are less fussy if the connected device is local subnet, TTL 1 TCP working, and the cert confirms the MAC address, or something. I think even that could use spoofed MAC to divert a switch, but harder to do.
What we need is some way to say to a browser, yes, warn this is not that secure, but don't go all alarm bells ringing because clearly it is locally directly connected somehow (e.g. TTL 1, MAC in cert). So that embedded s/w in network appliances have some way to allow that initial and direct config to work via https. Maybe we need CAs that are MAC OUI level somehow?
I can't think of a clean way to do this to be honest. It has to have warnings, but can there be a standard way to do this that minimises the scary warnings somehow?
Something to ponder.
P.S. Interesting, some browsers send the IP as the SNI, e.g. 10.0.0.1, but some send no SNI if an IP address. All adds to the fun. Latest FireBrick alpha has the self signing code for testing now.
This would be in situations where the fb is the main internet route and not online in any form?
ReplyDeleteNot really, but before configuring anything, it will not usually be "on-line".
DeleteCould you do what large printer companies do and supply it with a DVD full of applications written in flash that are about 2.5GB and only run in Windows Vista and launch about 5 things in your system tray in startup (and which need you to download about 500MB of frameworks like .net and Silverlight and Shockwave), then have the user configure it from there.
ReplyDeleteCynic!! :-)
DeleteCould use a self-signed certificate for a "special" DNS name?
ReplyDeleteTo be fair, surely the target market for a FireBrick are savvy enough to know that getting the warning on a newly purchased piece of networking equipment is normal?
ReplyDeleteLike you said, register a domain like some-ap.com. Then get the firebrick to use ACME to register a temporary domain of something like serial_no.some-ap.com and tell the user to go to that address.
ReplyDeleteThen as they go through the setup wizard, collect all the information required, and re-ACME using a proper DNS domain they want to use.
In all honesty though, browsers will allow an unsigned certificate to a local IP address along with the warnings etc, but not to a FQDN.
That can only work if that host name points to the brick available via external public IP. On the bench that is not the case.
DeleteYou could use the dns-01 challenge instead of the http based challenge then as long as the firebrick is able to reach a server under firebricks control it could send the required dns updates for its own serial number, this would however reveal the number of firebricks and where they are deployed.
DeleteAgain, no good if off-line in initial set up.
DeleteHow about doing initial setup with a LE certificate as part of the manufacturing/QA process ?
DeleteIf the DNS-01 method was used, it would only require outbound access for this. The only issue might be how the DNS credentials are secured.
Or, if the private key can be secured, how about purchasing (so it doesn't expire in 90 days) a single name certificate for 10.1.1.1.firbrick.co.uk and installing that as part of the manufacturing process, and having an A record for the hostname pointing at 10.0.0.1 (other IP addresses and names are available. Yes the same certificate would be installed on all firebricks, but as the hostname would only be accessible on RFC1918 networks...
We looked at lots of ideas like those already and they all end up as insecure as a self signed one to be honest. We’re still fine tuning it now though.
DeleteWith the proviso that I am by no means an expert, I don't see anything in the CAB requirements that prohibits getting publicly trusted certificates for fe80:: addresses (certainly not in the same way that there are for RFC1918 addresses).
ReplyDeleteIt seems to me that you (Firebrick) can prove ownership (at the time of issue) because you own the OUI. I'm not sure what would happen if you asked a CA to issue for one though! It might be that the CAB would then ban it.
If you've already thought of this and it's a no go I'd be interested in where my logic has gone wrong!
As an aside, why did you use internal IPv4 addresses in your example in the post above? I've found one of the single most useful things about IPv6 is the link local address. Put it on a sticker on the switch / router / AP etc. and you can ALWAYS use it by plugging a laptop in, regardless of if your DHCP / SLAAC is up, down, not yet configured, screwed up, etc. To my mind, fe80 addresses are the ultimate in "it just works" for networking kit.