One of the challenges we have is how we have a network appliance like the FireBrick and https from the start...
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?
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...
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.
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.
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.
I wanted to improve our doorbell... Yes, that is dull. But the main change is not the bell (a nice, old style bell in the kitchen, which is ...
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us...
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo...
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...