I haven't found any documentation that answers my question, so I'll ask here...
I read about LuCI now working over HTTPS. But everything I know means that it'll trigger a warning for an unsigned certificate...
I also have heard about hooking up with Let's Encrypt, but that implies that the router must be visible to the outside world (in order for the Let's Encrypt servers to issue the certificate).
I also read about WoflSSL using a Let's Encrypt certificate.
My questions:
If LuCI can use https/SSL certificate, what provisions/advice do we provide to people who get a self-signed certificate warning?
How would OpenWrt use a Let's Encrypt certificate?
How do all these interrelate?
I realize these are vague questions that are barely connected. But I would appreciate any insight (or links to existing documentation). Thanks.
Newcomers to OpenWrt. I don't worry about experienced people - they can "push through" and find answers. But I strongly feel the need to provide explicit answer to people who're coming fresh to OpenWrt.
OK. Is this documented anywhere? (Again, I teach a lot of novices. I tell them that when they see a "certificate error", they should definitely hit the Back button and leave the site. So our OpenWrt documentation needs to say that it's OK in this case...)
OK. That could be...
Yes, that was a little vague. Let me try again: How (where?) does OpenWrt use a Let's Encrypt certificate?
By default, not at all. At least not on the routers themselves. We do use Let’s Encrypt certificates on our servers but I suppose this is not what you meant.
People often refer to Let’s Encrypt as solution to the self signed certificate issue but as you’ve correctly pointed out already that requires a whole lot of prerequisites in order to work, like a publicly reachable router and a domain for ACME HTTP verification or access to a domain and it’s zone configuration for ACME DNS verification. Both far from trivial for newcomers and almost impossible to automate unless OpenWrt somehow serves as intermediate for cert bootstrapping (e.g. by providing automatic DynDNS, HTTP reverse proxy for CGN users etc.) which raises privacy and integrity concerns and would make OpenWrt installations dependent on OpenWrt infrastructure which will be a no-go for many deployment scenarios.
In short, there is no solution to this, which is why more and more vendors resort to cloud based management or mobile phone applications where they can do their own HTTPS cert independent crypto schemes between the cpe and the management app/server.
Here's an idea, and sorry in advance if it sounds confrontational: Instead of indiscriminately teaching them "certificate error = bad, danger, run", teach them what the error actually means, what certificates actually do? I know it's novices we are talking about, but "certificate error = go back" is akin to "check engine error light is on = throw away car".
A missing or broken certificate is not a sign of a fraudulent or dangerous site. Certificate errors happen all the time, to the best of websites. (Note: I'm not advocating that you should teach them to ignore it and continue as usual, of course it's a warning that something is not quite correct, and one should proceed with caution.)
But even more importantly: a valid certificate is not a sign of a trustworthy and safe site.
No, not confrontational at all. I appreciate the discussion. But I'm going to disagree with you.
It all depends - when I stand up HTTPS on OpenWrt, or my Raspberry Pi, I know that the server is fine, and that I can accept the self-signed certificate. It's true for any server that someone refers me to - if I know that the server's authentic/legitimate/etc. then it's OK to accept.
But for novice novice users (my neighbors, my family - where I'm the "tech support guy"), they should never run into a situation where they see a certificate error.
That's the group I'm training to "Run Away!" Caution isn't warranted for the kinds of sites they're likely to encounter. They should just stay away because there's nothing they could do to make things better.
In my opinion, self-signed certificate errors are nearly never an indication of something bad happening, so I personally question how much this statement is really true and how much we need to be afraid of teaching "wrong habits". Irrespective of my personal opinion that someone that can't just be trained to understand the context so they can decide when this error is ok or not will also be unable to change device settings on their own anyway.
In my experience, the only things that ever show cert errors are internal businness stuff and of course most embedded/networking equipment that is using HTTPS. Or sites that just fail to renew their certs and then you need to override or push through to use them, until the owner wakes up and renewes it.
Pretty much all websites that I've seen that got hacked and are modified to serve malware or to have a page that looks like Facebook/bank/whatever to be used as part of a phishing attack (yes I read my spam and I actually went to many of the links from an isolated system, because I'm curious) are all 100% perfectly fine with a "trusted" HTTPS (using the same pre-existing https certificate of the site which is paid by the original owner) so just checking that HTTPS is there and the cert is "trusted" doesn't really add a whole lot of security agains this kind of attack (which is what most such "novices" or more appropriately non-tech-savyy people will fall for).
What you must check is the domain name and link, because you can't spoof that (for a system on the Internet) by just hacking a server.
I think the only way forward if we want to use HTTPS is to put instructions like this https://peacocksoftware.com/blog/make-chrome-auto-accept-your-self-signed-certificate so that the user will import the self-signed cert as part of the first setup instructions and will then have a "trusted" certificate in the PC or device he will later use to connect again to the router
And say that first setup must be done with only the PC and the router alone connected with a ethernet cable so you can be sure there is no other device on that network.
If you succeed in learning a noob (big time noob) how to differentiate between self signed and officially signed cert, then we can start learning the noobs not to run every time and only sometimes instead.
I already told you. First-time configuration that must be done anyway to enable the wifi, done with only the PC and the router and nothing else, you know there is nothing else on the network. Then you import the cert in the browser following the steps as mentioned above.
Then the browser won't show the error again unless someone is actually spoofing your router. DONE. (applause in the distance)
Even "big time noob" understand the concept of "pairing" because that's how bluetoooth and many other devices function. First time you use them, there is a pairing sequence to follow.
This is very different from "just click on the error every time", this is a ONE-TIME pairing sequence.
Because I said that too, people that can't follow instructions won't be able to install OpenWrt either, so do we really need to cater to them too? (Can we? Is there even a way to?)