A proposal of https certificate assignment system for luci
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.
Openwrt as project get a CA certificate with name constrained to only
able to sign subdomains of [luci.openwrt.org]. this makes we Technically
Constrained Subordinate CA, (from let's encrypt or digicert), let's call
it the Openwrt CA here (CA ) this makes we don't create too much load to
normal CA like let's encrypt, and as we have complete control of this
zone we can give subdomains as we want like, and don't need full audit
like fully pledged CA and handled like a wildcard cert for them, but the
CA system can be hosted by us and request won't offloaded to upper CA's
server. (except OCSP request, but it can be cashed)
and assignment of a subdomain and it's certificate happens this way :
{everything below will be done on https or otherwise encrypted channel}
1. on first boot, router want to get it's luci certificate send its ssh
host key to Openwrt CA reserve subdomain base32(hash of public
key).luci.openwrt.org (like onion v3 addressed does)
2. Openwrt CA sends nonce to our router
3. router signs nonce+timestamp+[hash of CSR] with sent ssh host key,
and send back to openwrt CA send this signed message with CSR
4. Openwrt CA verify other end controls host key match with hash and
confirmed the CSR, sign the certificate with (key from CSR/SAN with
domain we derived from host key) and sent back to router
5. router now has valid cerfiticate, redirect 192.168.1.1 or openwrt lan
to https version of signed subdomain
now user only have to check :
1. page has valid certificate
2. the subdomain is match with device's ssh host key
and this verify it's the device we wanted.
--- some consideration
A. how authoritative DNS server reply on public dns lookup those
luci.openwrt.org? act like an dDNS with same verification for DNS
update, or just not answer?
B. router itself need to catches it's on subdomain lookup and answers
it's own address on LAN side.
C. this idea doesn't have real way to ratelimit the certificate request
other them by request ip: I'm not sure that'll be enough
D. Let's encrypt doesn't like to sign such certificate as normal
service, but maybe we can persuade them to sign one (it's one time job
for them)
E. with this now we have another server to manage.
P.S is this too large wall of text?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Hi 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. […] The elephant in the room remains, how do you propose to deal with firstboot conditions? Not every internet connection can be auto-detected, the most common examples would include having to configure VLAN tagging on WAN or adding PPPoE credentials. 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. Regards Stefan Lippers-Hollmann -- I'm ignoring the usage profiles for offline networking infrastructure (e.g. the recent addition of the rtl838x subtarget for managed switches), what happens if you take an old device from the shelve (existing certificate expired) and want to reconfigure/ start using it again or the significant costs (in hardware, manpower and certification) to operate a CA here. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
I am not sure click though certificate warning is that much of a
security issue in this context neither OpenWrt should have certificates
issued by default if I understood it correctly.
Most people accessing OpenWrt LuCI interface knows what it is and would
not find it strange to have to accept a self-signed certificate.
Also OpenWrt devices mostly are accessible from internal and restricted
networks and not exposed to the Internet. Still if necessary it is still
possible to add its own valid certificate to it on those cases where
necessary.
I think the steps outlined below can be a valid thing, but not to be
done automatically. As an optional procedure to make the things easier
for those who have a need to a certificate on certain scenarios.
In such way we keep the things simple as possible.
Regards
Fernando
On 04/10/2020 10:48, 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.
Openwrt as project get a CA certificate with name constrained to only
able to sign subdomains of [luci.openwrt.org]. this makes we Technically
Constrained Subordinate CA, (from let's encrypt or digicert), let's call
it the Openwrt CA here (CA ) this makes we don't create too much load to
normal CA like let's encrypt, and as we have complete control of this
zone we can give subdomains as we want like, and don't need full audit
like fully pledged CA and handled like a wildcard cert for them, but the
CA system can be hosted by us and request won't offloaded to upper CA's
server. (except OCSP request, but it can be cashed)
and assignment of a subdomain and it's certificate happens this way :
{everything below will be done on https or otherwise encrypted channel}
1. on first boot, router want to get it's luci certificate send its ssh
host key to Openwrt CA reserve subdomain base32(hash of public
key).luci.openwrt.org (like onion v3 addressed does)
2. Openwrt CA sends nonce to our router
3. router signs nonce+timestamp+[hash of CSR] with sent ssh host key,
and send back to openwrt CA send this signed message with CSR
4. Openwrt CA verify other end controls host key match with hash and
confirmed the CSR, sign the certificate with (key from CSR/SAN with
domain we derived from host key) and sent back to router
5. router now has valid cerfiticate, redirect 192.168.1.1 or openwrt lan
to https version of signed subdomain
now user only have to check :
1. page has valid certificate
2. the subdomain is match with device's ssh host key
and this verify it's the device we wanted.
--- some consideration
A. how authoritative DNS server reply on public dns lookup those
luci.openwrt.org? act like an dDNS with same verification for DNS
update, or just not answer?
B. router itself need to catches it's on subdomain lookup and answers
it's own address on LAN side.
C. this idea doesn't have real way to ratelimit the certificate request
other them by request ip: I'm not sure that'll be enough
D. Let's encrypt doesn't like to sign such certificate as normal
service, but maybe we can persuade them to sign one (it's one time job
for them)
E. with this now we have another server to manage.
P.S is this too large wall of text?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
abnoeh wrote:
> Openwrt as project get a CA certificate with name constrained to only
> able to sign subdomains of [luci.openwrt.org]. this makes we
> Technically Constrained Subordinate CA, (from let's encrypt or
> digicert), let's call it the Openwrt CA here (CA ) this makes we don't
> create too much load to normal CA like let's encrypt, and as we have
> complete control of this zone we can give subdomains as we want like,
> and don't need full audit like fully pledged CA and handled like a
> wildcard cert for them, but the CA system can be hosted by us and
> request won't offloaded to upper CA's server. (except OCSP request, but
> it can be cashed)
While this is a technically correct solution, it may be politically impossible.
The CABForum insists that any Subordinate CA that we might get has to be
constrained by the CABForum rules.
If we don't comply, then Mozilla/Google/Apple will force whatever root CA
that signs us to revoke the subCA. (I think that this really really sucks)
That's essentially why Enterprise subordinate CAs have gone away.
The CAs now offer to host Enterprise CAs in their cloud, where they can do
all the right things to remain compliant. Most enterprises find that
annoying and expensive, and so they go the way of generating their own
private CA.
If we can live with the constraints, and can find a CA willing to delegate a
subordinate CA to us, then let's try.
> {everything below will be done on https or otherwise encrypted channel}
> 1. on first boot, router want to get it's luci certificate send its ssh
> host key to Openwrt CA reserve subdomain base32(hash of public
> key).luci.openwrt.org (like onion v3 addressed does)
> 2. Openwrt CA sends nonce to our router
> 3. router signs nonce+timestamp+[hash of CSR] with sent ssh host key,
> and send back to openwrt CA send this signed message with CSR
> 4. Openwrt CA verify other end controls host key match
> with hash and confirmed the CSR, sign the certificate with (key from
> CSR/SAN with domain we derived from host key) and sent back to router
> 5. router now has valid cerfiticate, redirect 192.168.1.1 or openwrt
> lan to https version of signed subdomain
This an interesting process, leveraging the SSH key as part of the unique part.
I prefer to use ULA, and to find a way to store ULA in eeprom.
However, I think you are assuming a RA/DHCP-based WAN connection.
For PPPoE (which is still a thing in a lot of places, including developing
world, where last mile is often wifi), this won't work that well.
> now user only have to check :
> 1. page has valid certificate
> 2. the subdomain is match with device's ssh host key
> and this verify it's the device we wanted.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Stefan Lippers-Hollmann 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. > […] > The elephant in the room remains, how do you propose to deal with > firstboot conditions? Not every internet connection can be > auto-detected, the most common examples would include having to > configure VLAN tagging on WAN or adding PPPoE credentials. > 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. 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). 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. 3) hardware that was running a version of openwrt with certificates, but had to be factory default'ed. It would be nice to keep some identity things across such events. (The MOX has a private key that is stored across such events, for instance) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Fernando Frediani wrote: > I am not sure click though certificate warning is that much of a > security issue in this context neither OpenWrt should have certificates > issued by default if I understood it correctly. > Most people accessing OpenWrt LuCI interface knows what it is and would > not find it strange to have to accept a self-signed certificate. Also > OpenWrt devices mostly are accessible from internal and restricted > networks and not exposed to the Internet. Still if necessary it is > still possible to add its own valid certificate to it on those cases > where necessary. So, let me invert your logic to explain the issue. Because of the lack of certificates, and the hassle with click-through issues with self-signed certificates, access to the OpenWRT LuCI interfaces are restricted to people who know what it is. Only highly trained people know how to accept a self-signed certificate. As a result, most devices are accessibly only from internal networks, and usually never exposed to the Internet. Default passwords remain unchanged, and malware infected a vulnerable PC easily attacks the OpenWRT LuCI interface. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
On 05/10/20 18:38, Michael Richardson wrote: Fernando Frediani wrote: > I am not sure click though certificate warning is that much of a > security issue in this context neither OpenWrt should have certificates > issued by default if I understood it correctly. > Most people accessing OpenWrt LuCI interface knows what it is and would > not find it strange to have to accept a self-signed certificate. Also > OpenWrt devices mostly are accessible from internal and restricted > networks and not exposed to the Internet. Still if necessary it is > still possible to add its own valid certificate to it on those cases > where necessary. So, let me invert your logic to explain the issue. Because of the lack of certificates, and the hassle with click-through issues with self-signed certificates, access to the OpenWRT LuCI interfaces are restricted to people who know what it is. Only highly trained people know how to accept a self-signed certificate. I think calling "highly trained people" someone that knows how to click on two buttons on a web browser interface is a bit too much. Just add screenshots in the first install tutorial and/or something to the documentation that explains how to do that in case someone really is very new and has never needed to accept a self-signed certificate. As a result, most devices are accessibly only from internal networks, and usually never exposed to the Internet. Default passwords remain unchanged, and malware infected a vulnerable PC easily attacks the OpenWRT LuCI interface. I think this assumes a situation that is true with IoT and embedded devices but isn't true for OpenWrt devices. I mean, someone goes to the length of installing a custom firmware on a router/AP/nas/whatever, which involves finding the firmware file, finding the procedure to flash it (and in many devices you must use tftp or serial or other recovery systems, you cannot flash it from stock web interface). When this firmware starts for the first time the wifi of the device is disabled so 90% of the users will very likely want to enable it again. Any NAS or special function is also disabled or not installed by default, so a NAS isn't particularly useful in this stage. Then after they did that they decide to leave the device as-is with default config with LAN/Wan routing and no wifi, which is in most cases plain worse than what the stock firmware offers? I was under the impression that people installing OpenWrt do it because they want some of the features, and that 90% of the people really want their wifi to be on, so there is very good incentive to learn what is that error they see in the browser on first installation and how to click on a couple buttons to accept the certificate and proceed to the interface where they can actually set up what they wanted to do with their device. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Alberto Bursi wrote: >> Fernando Frediani wrote: > I am not sure click >> though certificate warning is that much of a > security issue in this >> context neither OpenWrt should have certificates > issued by default >> if I understood it correctly. >> >> > Most people accessing OpenWrt LuCI interface knows what it is and >> would > not find it strange to have to accept a self-signed >> certificate. Also > OpenWrt devices mostly are accessible from >> internal and restricted > networks and not exposed to the >> Internet. Still if necessary it is > still possible to add its own >> valid certificate to it on those cases > where necessary. >> >> So, let me invert your logic to explain the issue. >> >> Because of the lack of certificates, and the hassle with click-through >> issues with self-signed certificates, access to the OpenWRT LuCI >> interfaces are restricted to people who know what it is. Only highly >> trained people know how to accept a self-signed certificate. > I think calling "highly trained people" someone that knows how to click > on two buttons on a web browser interface is a bit too much. That's not the point. in fact, it's entirely opposite of the point. The *training* is knowing when you can click on the two+ buttons, and when it is imprudent to do so. The mechanics of the clicking is entirely irrelevant. Training users to click through those warnings is exactly what browser makers are trying to avoid, and browser makers have been trying to make the exception harder and harder to find. Many would like it removed. And, for good reason, because it is almost always inappropriate for most non-technical users to do that. [Children, (grand)parents, etc...] So, honestly, anyone that needs screenshots to figure it out, should never be clicking through the links. > I mean, someone goes to the length of installing a custom firmware on a > router/AP/nas/whatever, which involves finding the firmware file, > finding the procedure to flash it (and in many devices you must use So, just to be clear, are you saying that we should design openwrt to only be useable by developers? Home routers are critical parts of the home IoT ecosystem. OpenWRT is shipped in millions of devices by manufacturers too lazy to bother doing much. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
On 06/10/20 19:43, Michael Richardson wrote: Training users to click through those warnings is exactly what browser makers are trying to avoid, and browser makers have been trying to make the exception harder and harder to find. Many would like it removed. And, for good reason, because it is almost always inappropriate for most non-technical users to do that. [Children, (grand)parents, etc...] What are childern and grandparents or non-technical users doing with a network device's administration interface? There is nothing for them there, most functions are well above their understanding of the device and network, they can break configuration, lock themselves out from Internet access, or disable security settings. The device interface even on a normal router or NAS is actually accessed only by people that have some idea of what they are doing, or tinkerers that are playing with it, or power users that use it in a more professional way. Which is why I'm saying the warnings and clicking the buttons are fine, because the audience is a specific subset of the population. Grandma, kids, non-tech-savyy people and whatnot will have someone, the so-called "friendly family nerd" or an actual specialist that will set up the device for them. > So, honestly, anyone that needs screenshots to figure it out, should never be clicking through the links. new generations of power users still need to learn from somewhere. So, just to be clear, are you saying that we should design openwrt to only be useable by developers? The right word is "power users" or "prosumers". They aren't developers, they may not be network administrators either, but they know enough about the concepts to work on the devices in a relatively safe manner. You don't seem to acknowledge that to get OpenWrt on your device, you must void warranty and install a custom firmware, taking risks and assuming responsibility of their actions. These aren't your kid or grandma or plumber or random commoner. Home routers are critical parts of the home IoT ecosystem. OpenWRT is shipped in millions of devices by manufacturers too lazy to bother doing much. afaik the only devices where OpenWrt is shipped and the manufacturer does not care are random chinese junk routers/APs on Aliexpress, and I don't see why should anyone here care about that, also because they usually ship Chaos Calmer release (i.e. a 5-ish year old unsupported release at this point) without SSL enabled anyway. Do you know of some other specific examples? -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Hi Alberto, Hi Michael, Hi everyone else, On Tue, Oct 06, 2020 at 11:00:42PM +0200, Alberto Bursi wrote: > > > On 06/10/20 19:43, Michael Richardson wrote: > > > > > > Training users to click through those warnings is exactly what browser > > makers > are trying to avoid, and browser makers have been trying to make the > exception harder and harder to find. Many would like it removed. > And, for good reason, because it is almost always inappropriate for most > non-technical users to do that. [Children, (grand)parents, etc...] > > What are childern and grandparents or non-technical users doing with a > network device's administration interface? There is nothing for them there, > most functions are well above their understanding of the device and network, > they can break configuration, lock themselves out from Internet access, or > disable security settings. > > The device interface even on a normal router or NAS is actually accessed > only by people that have some idea of what they are doing, or tinkerers that > are playing with it, or power users that use it in a more professional way. > > Which is why I'm saying the warnings and clicking the buttons are fine, > because the audience is a specific subset of the population. > > Grandma, kids, non-tech-savyy people and whatnot will have someone, the > so-called "friendly family nerd" or an actual specialist that will set up > the device for them. > > > So, honestly, anyone that needs screenshots to figure it out, should never > be clicking through the links. > > new generations of power users still need to learn from somewhere. > > > So, just to be clear, are you saying that we should design openwrt to only > > be > > useable by developers? > > The right word is "power users" or "prosumers". > > They aren't developers, they may not be network administrators either, but > they know enough about the concepts to work on the devices in a relatively > safe manner. > > You don't seem to acknowledge that to get OpenWrt on your device, you must > void warranty and install a custom firmware, taking risks and assuming > responsibility of their actions. These aren't your kid or grandma or plumber > or random commoner. I don't understand how your argument is related to that pretty nice suggestion regarding a fairly complex and (unfortunately) relevant problem. Apart from it being hard to proof that people wanting to access the configuration (and status!) interface of a device running OpenWrt (or something based on it) are all prosumers or developers, for future users this assumption even has the taste of a self fullfilling prophecy. To me, the situation with self-signed certificates and the resulting warnings is a bug, not a feature, and I do appreciate the debate on what we could do about it. The suggested approach is possibly the best we can do in a world where reasonable connection security can only be achieved with the help of external certification authorities (and browser/consumer-OS vendors making everyone 'trust' them, by itself also a major bug which we are trying to work around here...). It's a bit a matter of taste if the OpenWrt CA should associate the SSH host key (which then requires SSH on the router to be accessible for the CA to verify it) or if it wouldn't be easier to just use a hash of the to-be-signed public key. The latter option has the disadvantage that user then has no means to verify the identity using the SSH host key (which had to be accepted previously, a warning not as scary looking but technically quite the same as accepting a self-signed certificate in a browser). It has the advantage that it's even easier to do as no verification of any kind would have to be done while still providing a great improvement in terms of security by asserting a mapping between hostname and TLS key used for HTTPS. However, then we still only got stuff like https://[b32(hash(pubkey))].devices.openwrt.org working, and of course http://192.168.1.1 and http://openwrt.lan may redirect to that, but httpS://192.168.1.1 would still give a warning about the certificate not being issued for that hostname. Though it would also create some non-neglectable administrational overhead if actually deployed for the .openwrt.org domain, even just using a designated OpenWrt toy root CA certificate people can install manually in their browsers, downloadable from httpS://OpenWrt.org, is already much better than training users to accept invalid certificates (as long as they still can). And it provides a good example of how vendors downstream could do it right as well (and that may ultimately converge into a new industry standard for which there is obviously a desperate need. and that could then result in lobbying for a way to operate subordinate CA for such type of purpose). A truely good solution to the actual problem imho doesn't exist (because https://youbroketheinternet.org/ ) ___ openwrt-devel mailing list o
Re: A proposal of https certificate assignment system for luci
Apart from it being hard to proof that people wanting to access the configuration (and status!) interface of a device running OpenWrt (or something based on it) are all prosumers or developers, for future users this assumption even has the taste of a self fullfilling prophecy. To me, the situation with self-signed certificates and the resulting warnings is a bug, not a feature, and I do appreciate the debate on what we could do about it. The suggested approach is possibly the best we can do in a world where reasonable connection security can only be achieved with the help of external certification authorities (and browser/consumer-OS vendors making everyone 'trust' them, by itself also a major bug which we are trying to work around here...). It's a bit a matter of taste if the OpenWrt CA should associate the SSH host key (which then requires SSH on the router to be accessible for the CA to verify it) or if it wouldn't be easier to just use a hash of the to-be-signed public key. The latter option has the disadvantage that user then has no means to verify the identity using the SSH host key (which had to be accepted previously, a warning not as scary looking but technically quite the same as accepting a self-signed certificate in a browser). It has the advantage that it's even easier to do as no verification of any kind would have to be done while still providing a great improvement in terms of security by asserting a mapping between hostname and TLS key used for HTTPS. However, then we still only got stuff like https://[b32(hash(pubkey))].devices.openwrt.org working, and of course http://192.168.1.1 and http://openwrt.lan may redirect to that, but httpS://192.168.1.1 would still give a warning about the certificate not being issued for that hostname. Though it would also create some non-neglectable administrational overhead if actually deployed for the .openwrt.org domain, even just using a designated OpenWrt toy root CA certificate people can install manually in their browsers, downloadable from httpS://OpenWrt.org, is already much better than training users to accept invalid certificates (as long as they still can). And it provides a good example of how vendors downstream could do it right as well (and that may ultimately converge into a new industry standard for which there is obviously a desperate need. and that could then result in lobbying for a way to operate subordinate CA for such type of purpose). A truely good solution to the actual problem imho doesn't exist (because https://youbroketheinternet.org/ ) How about a completely different approach? Install a custom certificate on the developer or prosumer machine. It is normal to have an out of chain "business intranet" certificate to install. Most OS and browsers have a means to support this. OpenWrt would just need tools, helper scripts, or instructions for three cases: (1) For those using ready built images, each release (19.7.3 vs 19.7.4) has a different certificate the user can install. They download the image and certificate. This will get them the default "OpenWrt.lan" domain. (2) For those saving configurations, their router ID or domain can have its own certificate they install. LuCI can help build this for their first run through configuration before they save. (3) For those building their own images, they locally install a certificate of their own construction. They can option to find and include that certificate as part of menuconfig or just stuff in /file/etc/... Anyway a start of an idea. - Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
20. 10. 6. 오전 1:29에 Michael Richardson 이(가) 쓴 글:
abnoeh wrote:
> Openwrt as project get a CA certificate with name constrained to only
> able to sign subdomains of [luci.openwrt.org]. this makes we
> Technically Constrained Subordinate CA, (from let's encrypt or
> digicert), let's call it the Openwrt CA here (CA ) this makes we don't
> create too much load to normal CA like let's encrypt, and as we have
> complete control of this zone we can give subdomains as we want like,
> and don't need full audit like fully pledged CA and handled like a
> wildcard cert for them, but the CA system can be hosted by us and
> request won't offloaded to upper CA's server. (except OCSP request, but
> it can be cashed)
While this is a technically correct solution, it may be politically impossible.
The CABForum insists that any Subordinate CA that we might get has to be
constrained by the CABForum rules.
If we don't comply, then Mozilla/Google/Apple will force whatever root CA
that signs us to revoke the subCA. (I think that this really really sucks)
actually making our CA to Technically Constrained as CA/B 7.1.5 will
make we exempted from most of those audit requirements, just section 8.7
which is just we and our parent CA should check we are adhere to our own
CPS. and most root program take same approach, you should be name locked
or be public and audited.
form 8.1 Frequency or circumstances of assessmentCertificates that are
capable of being used to issue new certificates MUST either be
Technically Constrained in line with section 7.1.5 and audited in line
with section 8.7 only
That's essentially why Enterprise subordinate CAs have gone away.
The CAs now offer to host Enterprise CAs in their cloud, where they can do
all the right things to remain compliant. Most enterprises find that
annoying and expensive, and so they go the way of generating their own
private CA.
If we can live with the constraints, and can find a CA willing to delegate a
subordinate CA to us, then let's try.
> {everything below will be done on https or otherwise encrypted channel}
> 1. on first boot, router want to get it's luci certificate send its ssh
> host key to Openwrt CA reserve subdomain base32(hash of public
> key).luci.openwrt.org (like onion v3 addressed does)
> 2. Openwrt CA sends nonce to our router
> 3. router signs nonce+timestamp+[hash of CSR] with sent ssh host key,
> and send back to openwrt CA send this signed message with CSR
> 4. Openwrt CA verify other end controls host key match
> with hash and confirmed the CSR, sign the certificate with (key from
> CSR/SAN with domain we derived from host key) and sent back to router
> 5. router now has valid cerfiticate, redirect 192.168.1.1 or openwrt
> lan to https version of signed subdomain
This an interesting process, leveraging the SSH key as part of the unique part.
I prefer to use ULA, and to find a way to store ULA in eeprom.
using ssh key as unique part was to solve problem of 'Are you sure you
are looking at right page even at worst state (like dns hijack or remote
management over the internet) so I wanted to make domain something can
be cryptically connected to the device we connect, and ssh key was first
and only key we have.
maybe enforce cert's pubkey == ssh pubkey == domain kind of way be
better, but browsers don't support ed25519, or CA/B allow to make one,
so it need ssh-keescan to see key if device check ed25519 key by default.
However, I think you are assuming a RA/DHCP-based WAN connection.
For PPPoE (which is still a thing in a lot of places, including developing
world, where last mile is often wifi), this won't work that well.
at the end entire reason we need certificate is we having a webserver,
and all luci will do at the backend is running uci conmmand, can we run
luci on client side, and send uci command to ssh, wrap it all under the
name of "easy-installer"?
if we don't have webserver we don't need a certificate. or uhttpd, in fact.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
On 07/10/20 04:01, Daniel Golle wrote: Hi Alberto, Hi Michael, Hi everyone else, I don't understand how your argument is related to that pretty nice suggestion regarding a fairly complex and (unfortunately) relevant problem. It is relevant because it's asking how big of a problem it actually is to maintain the current status quo of accepting the warnings with the buttons. In my opinion, until the browsers start blocking the connection to sites with self-signed certificates, this is a non-issue because the userbase is tech-savyy enough to read the wiki and follow a tutorial, since they are already following a tutorial to install OpenWrt to begin with. Apart from it being hard to proof that people wanting to access the configuration (and status!) interface of a device running OpenWrt (or something based on it) are all prosumers or developers, for future users this assumption even has the taste of a self fullfilling prophecy. Hard to proof? I thought it was obvious enough. Is the following situation different where you live? Where I live (Italy), the devices from all ISPs have always been pre-configured since ages ago, wifi is always enabled and the device-specific wifi key is on a sticker under the device, also WPS functionality is commonly available with a button. They never ever have to open its configuration panels to do anything, just connect the cables and power plug. A few ISPs don't even provide passwords for their device web interface and their tech support people will remote-control them to enable or disable features (open ports and add rules and whatnot) as requested by the customer on the phone. For devices that aren't provided by the ISPs, basic stuff like setting up a guest wifi or sharing a USB device are one-button wizards that just ask the network name and password, or what is the USB device you want to share. All devices with a SIM card slot and modem are plug-and-play aka you just insert a SIM without the PIN and power on, and everything works. Also most devices have a selector in the web interface that allows to turn them into three modes: wifi AP, wifi repeater, router and reconfigures a bunch of stuff under the hood. On OpenWrt the user experience is very different from that, and I don't think it's a stretch to assume that it is filtering the userbase. We start by installing a custom firmware on a device, sometimes easy sometimes hard. The entire concept of doing that already filters out many non-tech-savyy people. If we talk of OpenWrt used on ISP-provided devices, it's usually a pre-configured plug-and-play system that the end user never looks at again. Then you must set up the wifi network, no wizard. It's assumed you know how to do it or read the wiki. Changing "mode" of the device require multiple steps of configuration on OpenWrt, sometimes can only be done from commandline. Again, it's assumed you know how to do it or have RTFM. Many features require to copy-paste console commands and/or follow a tutorial from the wiki to do this or that. Even basic stuff like setting up a guest wifi require multiple steps of configuration setting new interfaces, new firewall rules and whatnot. Connecting and sharing a USB drive? Yay, more steps to connect it, install drivers, mount it, set up Samba on the folder it is mounted on. Using devices that have an integrated 3G/LTE modem? More configuration. You want to set up a RAID on a NAS device? commandline only, baby. All proposals for making a default wifi with device-specific passwords have been shot down, and wifi isn't enabled even in devices where there are no other interfaces, forcing you to use serial for first configuration, which is even funnier for the poor souls that install OpenWrt in such devices. So, please explain how clicking on two buttons on the browser when connecting the first time matters for people that can deal with the above on their own (and therefore know stuff) or are already 100% following and trusting a wiki tutorial to install OpenWrt and set up their device. As I already said, just add a couple screenshots and instructions in the install guide and it's fine. A truely good solution to the actual problem imho doesn't exist (because https://youbroketheinternet.org/ ) The only decent solution, and also more user-friendly and easy to expand imho is Android/iOS apps. With that you can bypass all the certificate mafia bs and do your own thing. It does not need a backend on the devices either as it can just rely on a simple ssh interface to actually talk to the device and send direct commands. That's what most manufacturers are moving towards, like for example GL.Inet https://www.gl-inet.com/solutions/app/ but also TP-link with "TP-link Tether" Netgear with "Netgear Genie" and "Nighthawk" and "Orbi" and so on and so forth. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.o
Re: A proposal of https certificate assignment system for luci
On 07/10/20 15:34, abnoeh wrote: However, I think you are assuming a RA/DHCP-based WAN connection. For PPPoE (which is still a thing in a lot of places, including developing world, where last mile is often wifi), this won't work that well. at the end entire reason we need certificate is we having a webserver, and all luci will do at the backend is running uci conmmand, can we run luci on client side, and send uci command to ssh, wrap it all under the name of "easy-installer"? if we don't have webserver we don't need a certificate. or uhttpd, in fact. Yeah, this is why Android/iOS apps should be considered as a way to approach this issue. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
On Mon, Oct 05, 2020 at 12:34:14PM -0400, Michael Richardson wrote: > Stefan Lippers-Hollmann 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
On Thu, Oct 08, 2020 at 12:10:17AM +0200, Alberto Bursi wrote: > On 07/10/20 15:34, abnoeh wrote: >>> However, I think you are assuming a RA/DHCP-based WAN connection. >>> For PPPoE (which is still a thing in a lot of places, including >>> developing world, where last mile is often wifi), this won't work >>> that well. >> >> at the end entire reason we need certificate is we having a >> webserver, and all luci will do at the backend is running uci >> conmmand, can we run luci on client side, and send uci command to >> ssh, wrap it all under the name of "easy-installer"? >> >> if we don't have webserver we don't need a certificate. or uhttpd, in >> fact. > > Yeah, this is why Android/iOS apps should be considered as a way to > approach this issue. Not everybody (especially in the developing world, see above) has an Android or iOS device. Also, such an app would still have to either: 1. disregard certificate errors, or 2. handle old (& maybe even revoked) OpenWRT CA signatures/certificates, or 3. be subject to the same limitations as a web browser, defeating the point of an app. I guess you had 1 or 2 in mind, and I can see the appeal - I'm not dismissing your suggestion. However, an app might not be quite the panacea you imagine. 1 would be a security risk for app users, & 2 requires potentially uncomfortable trade-offs between security & usability thus again slightly defeating the point of an app. Ultimate, SSL/TLS on IoT is a hard problem: the two technologies are currently not *fully* mutually compatible without imposing some burden on the user. -- 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Op 6 okt. 2020, om 19:20 heeft Alberto Bursi het volgende geschreven: > ... > Just add screenshots in the first install tutorial and/or something to the > documentation that explains how to do that in case someone really is very new > and has never needed to accept a self-signed certificate. Agree (more or less). Why not apply the same policy as with the initially unset root password? Signal the the non-ssl state of the wui and invite, with a little extra information, the user to create and accept a self signed cert, after which the wui changes to HTTPS. Regards, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
On 2020-10-04 15:48, 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. After reading the previous debate (in part) and this one, I'm wonderering whether we aren't making things more difficult than they need to be. A security conscious user/administrator would install a router without any untrusted computers connected to the LAN side and setup the device properly before allowing others to connect. The WAN side connection is not important, as Luci is not listening there by default. So I think it is reasonably safe to do the initial setup over HTTP (without the "S") at the first boot if there are no certificates available from a previous OpenWRT install. Then the user can setup the WAN side if needed and upload (from local PC), generate (self-signed) or acquire (e.g. Let's Encrypt) the certificates for Luci. After that, the connection is switched to HTTPS and HTTP switched off. The only issue I see, is how to transfer admin, WAN and WiFi passwords at first boot in a secure way. Even though the user/admin should be alone on the connection, sending those unencrypted over the line is not desirable. Maybe those can be encrypted using client side javascript. The challenges IMHO are being able to safely retain previously installed certificates over OpenWRT reflashes/upgrades and having user friendly tools to get new certificates uploaded, generated or acquired. For the latter part, some configurable service to periodically download and install certificates from an external host might be desirable (that's how I do it with my NAS boxes at home). Cheers, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
On 09/10/2020 08:29, Bas Mevissen wrote: On 2020-10-04 15:48, abnoeh wrote: . So I think it is reasonably safe to do the initial setup over HTTP (without the "S") at the first boot if there are no certificates available from a previous OpenWRT install. Then the user can setup the WAN side if needed and upload (from local PC), generate (self-signed) or acquire (e.g. Let's Encrypt) the certificates for Luci. After that, the connection is switched to HTTPS and HTTP switched off. Exactly. Only those who really need and want to have a HTTPS certificate can to that manually after the router is setup and has Internet connection. Regards Fernando ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
20. 10. 9. 오후 8:29에 Bas Mevissen 이(가) 쓴 글: So I think it is reasonably safe to do the initial setup over HTTP (without the "S") at the first boot if there are no certificates available from a previous OpenWRT install. Then the user can setup the WAN side if needed and upload (from local PC), generate (self-signed) or acquire (e.g. Let's Encrypt) the certificates for Luci. After that, the connection is switched to HTTPS and HTTP switched off. The only issue I see, is how to transfer admin, WAN and WiFi passwords at first boot in a secure way. Even though the user/admin should be alone on the connection, sending those unencrypted over the line is not desirable. Maybe those can be encrypted using client side javascript. For things with USB port, firstboot loader script from load ssh autorized key/root password from usb drive and/or export script they when there is '.whoareyou' file touched in usb drive write it's ssh host key and it's self signed certificate into the usb drive? I think later can be part of hotplug.d script. The challenges IMHO are being able to safely retain previously installed certificates over OpenWRT reflashes/upgrades and having user friendly tools to get new certificates uploaded, generated or acquired. For the latter part, some configurable service to periodically download and install certificates from an external host might be desirable (that's how I do it with my NAS boxes at home). for sysupgrade, like save config option, add new save-keys option that only save dropbear key and uhttpd certs? Cheers, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
On 2020-10-09 14:33, abnoeh wrote: 20. 10. 9. 오후 8:29에 Bas Mevissen 이(가) 쓴 글: So I think it is reasonably safe to do the initial setup over HTTP (without the "S") at the first boot if there are no certificates available from a previous OpenWRT install. Then the user can setup the WAN side if needed and upload (from local PC), generate (self-signed) or acquire (e.g. Let's Encrypt) the certificates for Luci. After that, the connection is switched to HTTPS and HTTP switched off. The only issue I see, is how to transfer admin, WAN and WiFi passwords at first boot in a secure way. Even though the user/admin should be alone on the connection, sending those unencrypted over the line is not desirable. Maybe those can be encrypted using client side javascript. For things with USB port, firstboot loader script from load ssh autorized key/root password from usb drive and/or export script they when there is '.whoareyou' file touched in usb drive write it's ssh host key and it's self signed certificate into the usb drive? I think later can be part of hotplug.d script. Nice idea to be able to auto-load the config including key material. Might be very useful for larger installs. The challenges IMHO are being able to safely retain previously installed certificates over OpenWRT reflashes/upgrades and having user friendly tools to get new certificates uploaded, generated or acquired. For the latter part, some configurable service to periodically download and install certificates from an external host might be desirable (that's how I do it with my NAS boxes at home). for sysupgrade, like save config option, add new save-keys option that only save dropbear key and uhttpd certs? Nice idea to save SSH server keys as well. That will avoid warnings when connecting to the new box (at the same IP) for the first time. Obviously, one needs to be careful with plain text private keys and certs. Cheers, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Bas Mevissen wrote: > A security conscious user/administrator would install a router without any > untrusted computers connected to the LAN side and setup the device properly > before allowing others to connect. The WAN side connection is not important, > as Luci is not listening there by default. sure. What do security unconcious people do? > previous OpenWRT install. Then the user can setup the WAN side if needed and > upload (from local PC), generate (self-signed) or acquire (e.g. Let's > Encrypt) the certificates for Luci. After that, the connection is switched to > HTTPS and HTTP switched off. This is a a good story, but it doesn't have to be the only story. > The only issue I see, is how to transfer admin, WAN and WiFi passwords at > first boot in a secure way. Even though the user/admin should be alone on the > connection, sending those unencrypted over the line is not desirable. Maybe > those can be encrypted using client side javascript. There is nothing you can with javascript here that wouldn't just be security threatre. If you had anchors you could trust, then it would be done. > The challenges IMHO are being able to safely retain previously installed > certificates over OpenWRT reflashes/upgrades and having user friendly tools > to get new certificates uploaded, generated or acquired. For the latter part, > some configurable service to periodically download and install certificates > from an external host might be desirable (that's how I do it with my NAS > boxes at home). You need a name is DNS, then it's just a dns-01 challenge. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
On 2020-10-11 00:58, Michael Richardson wrote: Bas Mevissen wrote: > A security conscious user/administrator would install a router without any > untrusted computers connected to the LAN side and setup the device properly > before allowing others to connect. The WAN side connection is not important, > as Luci is not listening there by default. sure. What do security unconcious people do? Just put it in use with the build-in defaults. It is not without reason that ISP routers nowadays come with a semi-unique SSID and securely generated wifi passwords. With OpenWRT we should aim to get the best possible security with the least effort (on user side) possible. ISP routers usually only support HTTP or HTTPS with a self-signed bogus certificate for the admin interface. > previous OpenWRT install. Then the user can setup the WAN side if needed and > upload (from local PC), generate (self-signed) or acquire (e.g. Let's > Encrypt) the certificates for Luci. After that, the connection is switched to > HTTPS and HTTP switched off. This is a a good story, but it doesn't have to be the only story. It is the story where we can give the best out-of-the-box guidance and hopefully cover most installs. > The only issue I see, is how to transfer admin, WAN and WiFi passwords at > first boot in a secure way. Even though the user/admin should be alone on the > connection, sending those unencrypted over the line is not desirable. Maybe > those can be encrypted using client side javascript. There is nothing you can with javascript here that wouldn't just be security threatre. If you had anchors you could trust, then it would be done. The trust comes from being the only one connected to the specific box. If that is not guaranteed, it is very hard to impossible to be 100% sure. It at least requires a specific certificate being installed on a specific box. If you are on that level, you don't need the guided certificate install anyway. With my proposal and the requirement of being the only one on the network, you get pretty close to that level. > The challenges IMHO are being able to safely retain previously installed > certificates over OpenWRT reflashes/upgrades and having user friendly tools > to get new certificates uploaded, generated or acquired. For the latter part, > some configurable service to periodically download and install certificates > from an external host might be desirable (that's how I do it with my NAS > boxes at home). You need a name is DNS, then it's just a dns-01 challenge. I believe the most common being an HTTP-01 challenge (see https://letsencrypt.org/docs/challenge-types/). So you need a DNS entry pointing to your (dynamic?) IP and a HTTP server under OpenWRT control running on port 80 or 443. That is not always practicable for home internet connections. I found it to be much more practicable to have the certificate generated and renewed on an external host (with the FQDN of my NAS boxes pointing to that host in public DNS) and download the certificate files at regular intervals. Inside my network, the name of the NAS is resolved to its local IP address. Anyway, the options to upload, generate or acquire will probably cover the most common cases and are not hard to implement. Regards, Bas. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
