However, https is more and more a thing and becoming so much the normal way of working (with browsers warning if not https even), so we are including it in the new FB2900, and the existing FB2500, FB2700, and FB6000 series as a free software upgrade.
In fact, working https, with an SSL Labs score of at least "A", is pretty much the reason for the current delay on the FB2900 launch. We have finally sorted the other issues which had added months and months to the launch of the FB2900, but as https is almost ready we are going to ensure the launch has https. It is literally a matter of days away - I have working https on my test FireBrick (SSL labs score "B") even now, thanks to hard work of my colleague Cliff.
We then follow on with ssh, and the plan is ACME support to use Let's Encrypt to make https really easy to install - point a domain/hostname at the brick's IP and bingo, it will be properly certified https. It will still have all of the access controls, but with caveats for ACME certificate renewals. The ACME Let's Encrypt certificates will help with IPsec configurations as well.
Sadly, one of the things we would have loved to do is impossible. We wanted a brick "out of the box" to work with https with no warnings. We could maybe include a cert for my.firebrick.uk or some variant to do this, but any means by which a FireBrick has a private key in the code would mean someone could get a FireBrick and JTAG or some such to extract it from the flash. It would allow that key to be extracted and misused. The only real answer will be for a FireBrick to have a unique key pair and obtain a signed certificate by ACME, or similar, and that can only happen after it has a public hostname and internet connection. So the initial set up will have to be over http or with a "security exception" to talk https. Typically this is literally a laptop connected to the FireBrick, so either is acceptable, but a shame no way to avoid that. It would be interesting to consider the ways embedded devices could solve that within an https and certificate framework one day (TTL 1 and tied to MAC address or something?).
So, FB2900 really close now... Many boxes on the shelves ready to ship... Watch this space!
P.S. I won't bore you with the days of work on the outer packaging shipping label featured in the image above. Lots of svg, barcodes, and postscript and stuff with UPCs and things. All very boring I am sure... :-)
P.P.S. We may forego the "A" rating at launch for the working on all main browsers and not add more delay.
P.P.P.S testers that can load "alpha" releases should hopefully have access to play with this in next day or so.
Could you include a tsig (for dns) key with the firebrick so it can automatically register [serialnumber].firebrick.uk and then obtain a cert with ACME? Though there could possibly be privacy and other technical issues with this, you may have to run a proxy for those whose initial connection is out via a nat gateway.
ReplyDeleteIf you have the system in place for DNS registration you could use the ACME DNS-01 validator and not require incoming connections to the Firebrick at all (so someone could plug it in behind an existing NAT gateway for configuration and not have to change their existing setup at all). Something like:
Delete- Plug in Firebrick WAN to a network with DHCP to provide Internet connectivity
- Have it register 000000.my.firebrick.uk publicly with an A record for the factory LAN IP address
- Use ACME with the DNS-01 validator to configure a TXT record for that hostname and get the certificate for it
- Either serve up the equivalent DNS record locally or allow the default LAN network to access a public DNS server
- Theoretically then anything plugged into the LAN port can also use the same serial-based hostname to get to the default HTTPS management IP
That idea does depend on the LAN port of a Firebrick being pre-configured with sensible DHCP settings such that you could just plug in a laptop and go - I don't know whether that's the case or not.
That scares me a little bit, because I think that would cause every firebrick DNS name to be recorded in Certificate Transparency logs. So, you could find out exactly how many FireBricks have been commissioned (or reset) by searching CT logs and building a list of *.my.firebrick.uk domains. Then you do a slow, randomized, distributed set of DNS lookups to get IPs.
DeleteThe way I imagine it working, the DNS record would point to a non-routable IP by default so is virtually useless (assuming the Firebrick devices follow a generic two-interface LAN/WAN separation with the LAN interface having a factory-set RFC1918 IP, and the WAN port being a DHCP client).
DeleteYou're right, it would allow enumeration of how many Firebricks had shipped - but is that particularly sensitive data? And if going to 000001.my.firebrick.uk simply resolves to "192.168.1.1" or any other RFC1918 address then it gives away nothing about the company who have actually deployed that Firebrick. If they have their Firebrick management IP set to a public IP then potentially there would be a way to map that particular unit to a particular company - agreed. But is that an acceptable trade-off for the convenience?
I know nothing about Firebricks or their customers so I don't know whether that would be a common use case - I am imagining that most people would have the management IP assigned on an internal interface/VLAN/however they choose to segregate such things.
Looks like an impressive gadget.
ReplyDeleteI noticed that there's a USB port. You could say something like this: On first boot (or first boot after a config reset), check if a USB is attached. If yes, look for a cert and key named (respectively) "serialnumber.cer" and "serialnumber.key". Allow the cert file to include multiple certs, so that the leaf and intermediates are in one file.
ReplyDeleteIf the files are present, copy the files into place and try to start the web server with HTTPS. If the web server fails to start, log an error, remove the key/cert files, and restart the server without HTTPS.
I agree it's annoying, but at least it gives the admin a workable option!
If you included an hsm the key could be in that
ReplyDeleteGenerate an initial keypair on build, print the public key on the label, selfsign the cert. If anybody is stupid enough to put a newly deployed device directly onto an untrusted network they can compare the public key on the self signed cert?
ReplyDeletePutting on label is interesting idea. We do key pair already but I’ll look in to that.
DeleteWould it need to be in a small font in case a hacker could read it (e.g. by looking through a window or seeing it behind someone on a web cam or taking a photo of the key if they manage to blag their way into the equipment room)? Also maybe slightly greyed out and on the underside/rear of the device?
DeleteAlso would the label need to be the sort where the text doesn't wear out/rub off easily?
The logo looks so cool btw
No, it would be a key fingerprint, something that you can publish and use to check the key used.
DeleteThank you... I think I need to learn more about how encryption works... :-)
Delete