A proposal of https certificate assignment system for luci

[Sam Kuper]

On Mon, Oct 05, 2020 at 12:34:14PM -0400, Michael Richardson wrote:
> Stefan Lippers-Hollmann <s.l-h at gmx.de> wrote:
>> On 2020-10-04, abnoeh wrote:
>>> Few months ago there was some debate for how we handle certificate
>>> for luci page: make user to click though certificate warning is not
>>> that great for security so here is a  proposal for autometically
>>> assign a worldwide unique subdomain and how to make valid
>>> certificate for it, and make sure we and connect to the device he is
>>> expecting.

It's a nice idea.  Would be great to make it (or something like it)
workable.

The difficulties it raises are typical IoT security issues for which the
world is only starting (& often still failing) to create solutions.[0]


>> The elephant in the room remains, how do you propose to deal with
>> firstboot conditions? Not every internet connection can be
>> auto-detected [..]
>>
>> For these, the user will have to accept a self-signed certificate at
>> least once for doing the initial configuration - at which point they
>> can just stick to the already accepted self-signed certificate as
>> well.
> 
> There are really three use cases.

I count four (see below).


> 1) hardware that comes with openwrt.  There is a manufacturer
>    controlled first boot.  (This is relatively easy, and I have
>    running code) if we can build that subordinate CA that issues for
>    longer than the 90 days that the device is likely going to be in a
>    box (in a warehouse).

The 90-day limitation (presumably referring to the validity duration of
Let's Encrypt certificates) is a very good point.

As of September 2020, maximum HTTPS certificate validity duration is
currently 1 year, (well, 397 or 398 days).[1]  Would even this be long
enough?  Maybe some pre-flashed routers end up being stored for >398
days before being shipped to customers.[2]


> 2) hardware that didn't come with (this version) of openwrt, but is
>    first flashed.  This probably a common case for most readers of
>    this list, and yes, we are probably smart enough to deal with
>    self-signed certificate the first time.
>    But, we are a small group.

Exactly.

If a user is flashing OpenWRT for the first time, & either doesn't
understand the certificate warning &/or is following installation
instructions don't mention it, they might think something has gone
wrong, & might then either give up or waste time troubleshooting.  It's
extra usuability friction.


> 3) [..]

4)   hardware that is not connected to the Internet.  Any
     security-conscious user, setting up a router for the first time, is
     likely to keep it disconnected from the Internet (either
     physically, or firewalled/blocked by an upstream device) until sure
     it has been configured to their requirements.  Also, routers used
     in some local networks should not have or need an Internet gateway.

This use-case (4) is probably the hardest one to solve, from an SSL/TLS
certificate validity perspective.

Sam

[0]:
https://dev.to/danielkun/where-is-https-for-iot-49ao
https://neosmart.net/blog/2017/lets-stop-punishing-iot-devices-that-embrace-https-shall-we/
https://medium.com/@flynam/securing-your-iot-device-using-ssl-4643110ab901
https://www.ssl.com/article/securing-the-internet-of-things-iot-with-ssl-tls/
https://comodosslstore.com/resources/iot-ssl-certificates-for-connected-device-security-all-you-need-to-know/

[1]:
https://www.globalsign.com/en/blog/maximum-ssltls-certificate-validity-now-one-year
https://news.gandi.net/en/2020/07/the-maximum-duration-of-ssl-certificates-soon-to-be-reduced-to-1-year/

[2]:
https://www.techrepublic.com/article/expiring-security-certificates-may-start-shutting-down-iot-devices/

-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?

()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.