Make HTTPS in LuCI optional but dead simple in 20.12 [Was: Re: 20.xx: postponse LuCI HTTPS per default]
Petr Štetiar [2020-11-20 11:44:14]: > > I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per > > default. > > Do we need to make this hard decission? Can't we leave it to the end users? > We need most of the SSL stuff for other parts, so why not benefit from that in > other parts? > > For the start, can't we simply introduce some first time welcome page on HTTP, > explain to the user, that HTTPS is available, the pros and cons of this > solution and let the user decide? > > In less intrusive way, this welcome page/wizard could be replaced with some > information box "HTTPS is just a moments away", so the user would need to > explicitly request that HTTPS feature. > > There might be some better UX approach, but please try hard to move forward, > not backward :-) this PR#4660[1] (needs PR#4659[2]) and uhttpd patch[3] is my complete attempt to make the HTTPS optional, but just two clicks away. 1. https://github.com/openwrt/luci/pull/4660 2. https://github.com/openwrt/luci/pull/4659 3. https://patchwork.ozlabs.org/project/openwrt/patch/20201214090743.14651-1-yn...@true.cz/ Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 26/11/20 06:57, suchan wrote: 2020-11-21 오전 12:31에 Fernando Frediani 이(가) 쓴 글: Yes, exactly it is only an issue when someone have to access the web interface via wifi. In a home environment that is a small issue. In a more corporate environment there are two options: 1) access is done via wired network or 2) enable HTTPS, which make more sense. Enabling HTTPS by default is still not worth in my view given the extras that come with it and I like the idea of keep the default as simple and possible. Yes it is nice to have everything ready and automated to be done with a few clicks for those cases that require it. In fact I think this would be a better solution for now so it will be possible to gather gradually this transition (or not) from HTTP to HTTPS even for local/lan applications and see how often people would opt to use it. Still should it end up having HTTPS by default I see self-signed certificates are the way to go. Yes there are the warnings and I really don't think there is any issue with it. Those accessing the router Web Interface are not 'normal' Internet users and they know what they are doing so the warning from self-signed certificates should not be a surprise for them. And those cases when admins prefer they can always replace the self-signed one for Let's Encrypt for example. Regards Fernando if we move to https by default them it will include acme client by default too? We can't assume the device after installation will have internet access to request/renew a Let'sEncrypt certificate or something else from another provider, so I don't think including a client by default will be useful -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
2020-11-21 오전 12:31에 Fernando Frediani 이(가) 쓴 글: Yes, exactly it is only an issue when someone have to access the web interface via wifi. In a home environment that is a small issue. In a more corporate environment there are two options: 1) access is done via wired network or 2) enable HTTPS, which make more sense. Enabling HTTPS by default is still not worth in my view given the extras that come with it and I like the idea of keep the default as simple and possible. Yes it is nice to have everything ready and automated to be done with a few clicks for those cases that require it. In fact I think this would be a better solution for now so it will be possible to gather gradually this transition (or not) from HTTP to HTTPS even for local/lan applications and see how often people would opt to use it. Still should it end up having HTTPS by default I see self-signed certificates are the way to go. Yes there are the warnings and I really don't think there is any issue with it. Those accessing the router Web Interface are not 'normal' Internet users and they know what they are doing so the warning from self-signed certificates should not be a surprise for them. And those cases when admins prefer they can always replace the self-signed one for Let's Encrypt for example. Regards Fernando if we move to https by default them it will include acme client by default too? if so, what client we will use? We currently have two choice for client in package repo, acme.sh (named acme in openwrt) and uacme(https://github.com/openwrt/packages/tree/master/net/uacme). but non of that currently support wolfssl. (where we move to include by default. acme.sh have gui luci-app-acme but it only runs with openssl, uacme support embedded mbedtls(and can use openssl or mbedtls if supplied) and somewhat smaller, but currently doesnt support any luci manager. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
> I think that if the first setup is done with only the router and the trusted > PC connected to it through an ethernet cable (wifi is disabled by default), > there is physically nothing else on that "network" so whatever you see can > be accepted even if you don't have "dual authentication" with the serial > port. Right. With this, I think all we need to do is provide clear information to the user along with a recommendation that he import the certificate into his browser before activating WiFi. You went on to describe this in your email. I think the landing page is a good idea, in addition to the documentation. Thank you for taking the time to work through my concern. -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 20:23, Paul Spooren wrote: On Fri Nov 20, 2020 at 7:35 AM HST, Adrian Schmutzler wrote: Hi, -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Alberto Bursi Sent: Freitag, 20. November 2020 17:32 To: openwrt-devel@lists.openwrt.org Subject: Re: 20.xx: postponse LuCI HTTPS per default On 20/11/20 17:17, Fernando Frediani wrote: Hi Alberto On 20/11/2020 13:09, Alberto Bursi wrote: The only thing I can accept as a valid complaint against https by default is the increased minimum space requirements, everything else I really don't understand nor agree with. It's exactly this I am referring to when I talk about the extras not the steps the user will take to enable it. So why I mentioned to leave it as optional and easy to do for those who wish (and have space) to have it. Devices with low flash space (and RAM) are already receiving special treatment (different compile options, different default packages) to lower space footprint. These devices can (should?) be left out of the "https by default" easily. No, this is not an option. We certainly won't have (read "maintain") _two_ defaults for a matter like this. Apart from that, this discussion was not intended to discuss the various options _again_, but to ask whether we should have "https by default" as a _blocker_ for the next release. Personally, since the discussion seems to be as open and unresolved as a few months ago, I'm against making this a blocker. I'm curious where the whole topic evolves to, but that's not the subject of this thread. How about we use `luci-ssl` per default but set `redirect_https` to 0. This way everyone can access in a secure way, without changing the current user experience. An optional combination of Luiz idea could warn the users using HTTP, allowing to "ignore" or "activate redirect". I think that's a feasible solution for 20.xx. Spinning up a massive HTTPS dDNS or defining a new standard accepted in all common browsers seems a bit out of scope, for now. Paul I'm not sure what you are accomplishing with this beyond increasing the default image size. The way I see it, we either switch to https by default or we don't. Adding luci-ssl without redirect manages to annoy both types of users for no reason imho. It is just bloat for people using http, it's inconvenient for those that use https and would have liked the redirect to work by default -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 19:22, W. Michael Petullo wrote: I think making use of self-signed certificates in production is a bad idea because (1) it reinforces poor practices, namely electing to trust a self-signed certificate and (2) it does not authenticate the server/router, a critical piece of the TLS security model. maybe, but it's still better than sending all communication to the management interface as plain text. What is the difference between transmitting packets containing cleartext and transmitting encrypted packets to a party whose identity you do not know? What are you talking about? After the initial "pairing" process where you see the warning, the browser remembers the certificate for all subsequent connections. If the certificate changes (and it will change only if you do a firmware reset to default settings) you will see the the warning again. So you are just changing a CA-based system to a local pairing system. (I really do not mean for any of my comments here or earlier to be patronizing. I am just trying to describe my point of view.) When I make the first SSH connection to a new router, I confirm the fingerprint of the router's key using a serial-port connection. Thus I know it is safe to accept the pairing. If I were to skip this step, then I would have no assurance regarding to whom my encrypted messages were being sent now and in the future. I think that if the first setup is done with only the router and the trusted PC connected to it through an ethernet cable (wifi is disabled by default), there is physically nothing else on that "network" so whatever you see can be accepted even if you don't have "dual authentication" with the serial port. The only way for that to go bad is if your PC isn't trusted, but if that's the case, using a serial console from the same PC won't help much. Although I understand what you mean. How would our scheme recreate this? What would the interface provide to the user to help them perform this step? What would it recommend? Some tugging on Luiz Angelo Daros de Luca's proposal earlier in this thread (Fri, 20 Nov 2020 14:25:10), especially the addition of a suggested verification process, might help. How can you recreate a secure two-step verification process without two different communication mediums? I don't think it is possible, so this isn't viable. Imho the only thing that can be done for most devices is adding a http landing page that explains how to do the first pairing in the most secure way, like I said above. "make sure the device is connected through an ethernet cable to a trusted PC only, and that there are no other ethernet cables connected to this device, when you are ready to accept the self-signed certificate press OK button" And when you press OK it will redirect to https and you will get the warning and must accept it. Does it make sense to add this kind of "first setup" webpage to the device's web interface? Maybe. I have already mentioned some time ago in the older version of this discussion that 99% of the users that are doing this for the first time are going to be following some documentation anyway, so we could just write this down in the install tutorial in the wiki. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 18:35, Adrian Schmutzler wrote: Hi, -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Alberto Bursi Sent: Freitag, 20. November 2020 17:32 To: openwrt-devel@lists.openwrt.org Subject: Re: 20.xx: postponse LuCI HTTPS per default On 20/11/20 17:17, Fernando Frediani wrote: Hi Alberto On 20/11/2020 13:09, Alberto Bursi wrote: The only thing I can accept as a valid complaint against https by default is the increased minimum space requirements, everything else I really don't understand nor agree with. It's exactly this I am referring to when I talk about the extras not the steps the user will take to enable it. So why I mentioned to leave it as optional and easy to do for those who wish (and have space) to have it. Devices with low flash space (and RAM) are already receiving special treatment (different compile options, different default packages) to lower space footprint. These devices can (should?) be left out of the "https by default" easily. No, this is not an option. We certainly won't have (read "maintain") _two_ defaults for a matter like this. I'm not sure you can actually not "maintaining two defaults" regardless of what is decided. From what I understand, https support is an addon to the base http web interface infrastructure and not a fully different thing. So I think that if you switch to https by default you still need to maintain the "non-https" part of the web interface infrastructure anyway. Apart from that, this discussion was not intended to discuss the various options _again_, but to ask whether we should have "https by default" as a _blocker_ for the next release. Personally, since the discussion seems to be as open and unresolved as a few months ago, I'm against making this a blocker. Yeah I wouldn't treat it as a blocker, it's getting late for a release already and nobody in the main developer list seems to care about setting a default either way. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: 20.xx: postponse LuCI HTTPS per default
On Fri Nov 20, 2020 at 7:35 AM HST, Adrian Schmutzler wrote: > Hi, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of Alberto Bursi > > Sent: Freitag, 20. November 2020 17:32 > > To: openwrt-devel@lists.openwrt.org > > Subject: Re: 20.xx: postponse LuCI HTTPS per default > > > > > > > > On 20/11/20 17:17, Fernando Frediani wrote: > > > Hi Alberto > > > > > > On 20/11/2020 13:09, Alberto Bursi wrote: > > >> > > >> > > >> > > >> The only thing I can accept as a valid complaint against https by > > >> default is the increased minimum space requirements, everything else > > >> I really don't understand nor agree with. > > > > > > It's exactly this I am referring to when I talk about the extras not > > > the steps the user will take to enable it. So why I mentioned to leave > > > it as optional and easy to do for those who wish (and have space) to have > > it. > > > > > > > Devices with low flash space (and RAM) are already receiving special > > treatment (different compile options, different default packages) to lower > > space footprint. > > > > These devices can (should?) be left out of the "https by default" easily. > > No, this is not an option. We certainly won't have (read "maintain") > _two_ defaults for a matter like this. > > Apart from that, this discussion was not intended to discuss the various > options _again_, but to ask whether we should have "https by default" as > a _blocker_ for the next release. > Personally, since the discussion seems to be as open and unresolved as a > few months ago, I'm against making this a blocker. I'm curious where the > whole topic evolves to, but that's not the subject of this thread. How about we use `luci-ssl` per default but set `redirect_https` to 0. This way everyone can access in a secure way, without changing the current user experience. An optional combination of Luiz idea could warn the users using HTTP, allowing to "ignore" or "activate redirect". I think that's a feasible solution for 20.xx. Spinning up a massive HTTPS dDNS or defining a new standard accepted in all common browsers seems a bit out of scope, for now. Paul > > Best > > Adrian > > > > > But I would be strongly against degrading security for everyone just because > > of these devices. > > > > -Alberto > > > > > Regards > > > Fernando > > > > > >> > > >> > > >>> Yes it is nice to have everything ready and automated to be done > > >>> with a few clicks for those cases that require it. In fact I think > > >>> this would be a better solution for now so it will be possible to > > >>> gather gradually this transition (or not) from HTTP to HTTPS even > > >>> for local/lan applications and see how often people would opt to use it. > > >>> > > >>> Still should it end up having HTTPS by default I see self-signed > > >>> certificates are the way to go. Yes there are the warnings and I > > >>> really don't think there is any issue with it. > > >>> Those accessing the router Web Interface are not 'normal' Internet > > >>> users and they know what they are doing so the warning from > > >>> self-signed certificates should not be a surprise for them. > > >>> And those cases when admins prefer they can always replace the > > >>> self-signed one for Let's Encrypt for example. > > >>> > > >>> Regards > > >>> Fernando > > >> > > >> > > >> -Alberto > > >> > > >> ___ > > >> 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
I think making use of self-signed certificates in production is a bad idea because (1) it reinforces poor practices, namely electing to trust a self-signed certificate and (2) it does not authenticate the server/router, a critical piece of the TLS security model. >>> maybe, but it's still better than sending all communication to the >>> management interface as plain text. >> What is the difference between transmitting packets containing cleartext >> and transmitting encrypted packets to a party whose identity you do >> not know? > What are you talking about? After the initial "pairing" process where you > see the warning, the browser remembers the certificate for all subsequent > connections. > If the certificate changes (and it will change only if you do a firmware > reset to default settings) you will see the the warning again. > > So you are just changing a CA-based system to a local pairing system. (I really do not mean for any of my comments here or earlier to be patronizing. I am just trying to describe my point of view.) When I make the first SSH connection to a new router, I confirm the fingerprint of the router's key using a serial-port connection. Thus I know it is safe to accept the pairing. If I were to skip this step, then I would have no assurance regarding to whom my encrypted messages were being sent now and in the future. How would our scheme recreate this? What would the interface provide to the user to help them perform this step? What would it recommend? Some tugging on Luiz Angelo Daros de Luca's proposal earlier in this thread (Fri, 20 Nov 2020 14:25:10), especially the addition of a suggested verification process, might help. -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 17:47, W. Michael Petullo wrote: I think making use of self-signed certificates in production is a bad idea because (1) it reinforces poor practices, namely electing to trust a self-signed certificate and (2) it does not authenticate the server/router, a critical piece of the TLS security model. maybe, but it's still better than sending all communication to the management interface as plain text. What is the difference between transmitting packets containing cleartext and transmitting encrypted packets to a party whose identity you do not know? What are you talking about? After the initial "pairing" process where you see the warning, the browser remembers the certificate for all subsequent connections. If the certificate changes (and it will change only if you do a firmware reset to default settings) you will see the the warning again. So you are just changing a CA-based system to a local pairing system. What I am arguing is that just falling back on self-signed certificates in order to turn on HTTPS is not a good solution and is in fact counter-productive. I disgree with your argument, self-signed certificates are NOT less secure than http. Pairing is fine and secure even if you don't have the certificate mafia to "assure" that something is trusted. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: 20.xx: postponse LuCI HTTPS per default
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Alberto Bursi > Sent: Freitag, 20. November 2020 17:32 > To: openwrt-devel@lists.openwrt.org > Subject: Re: 20.xx: postponse LuCI HTTPS per default > > > > On 20/11/20 17:17, Fernando Frediani wrote: > > Hi Alberto > > > > On 20/11/2020 13:09, Alberto Bursi wrote: > >> > >> > >> > >> The only thing I can accept as a valid complaint against https by > >> default is the increased minimum space requirements, everything else > >> I really don't understand nor agree with. > > > > It's exactly this I am referring to when I talk about the extras not > > the steps the user will take to enable it. So why I mentioned to leave > > it as optional and easy to do for those who wish (and have space) to have > it. > > > > Devices with low flash space (and RAM) are already receiving special > treatment (different compile options, different default packages) to lower > space footprint. > > These devices can (should?) be left out of the "https by default" easily. No, this is not an option. We certainly won't have (read "maintain") _two_ defaults for a matter like this. Apart from that, this discussion was not intended to discuss the various options _again_, but to ask whether we should have "https by default" as a _blocker_ for the next release. Personally, since the discussion seems to be as open and unresolved as a few months ago, I'm against making this a blocker. I'm curious where the whole topic evolves to, but that's not the subject of this thread. Best Adrian > > But I would be strongly against degrading security for everyone just because > of these devices. > > -Alberto > > > Regards > > Fernando > > > >> > >> > >>> Yes it is nice to have everything ready and automated to be done > >>> with a few clicks for those cases that require it. In fact I think > >>> this would be a better solution for now so it will be possible to > >>> gather gradually this transition (or not) from HTTP to HTTPS even > >>> for local/lan applications and see how often people would opt to use it. > >>> > >>> Still should it end up having HTTPS by default I see self-signed > >>> certificates are the way to go. Yes there are the warnings and I > >>> really don't think there is any issue with it. > >>> Those accessing the router Web Interface are not 'normal' Internet > >>> users and they know what they are doing so the warning from > >>> self-signed certificates should not be a surprise for them. > >>> And those cases when admins prefer they can always replace the > >>> self-signed one for Let's Encrypt for example. > >>> > >>> Regards > >>> Fernando > >> > >> > >> -Alberto > >> > >> ___ > >> 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 openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
Hi, I guess we could simply ask the user by default (with options to auto generate a certificate or ignore https). Luci already warns that a root password must be set. Why not also add something like: "Upgrade to a secure connection?". "No password Set! There is no ... ... " "You are using an unencrypted connection! Before informing sensitive information, like a password, it is recommended to enable encryption (https) ... # it will require authentication if a password is already set " If the user opts to use it, it could generate a self-signed certificate and offer it to be downloaded/imported even before using it. http://192.168.1.1/luci/https-settings#generate-self-signed... HTTP Settings: #if "the certificate is not trusted by the browser. Can we test it using ajax?" Click here to download and import the router certificate now. Otherwise, your browser will warn you that the router certificate is not trusted. Then, you can ignore the error and continue. However, it would be safer to add the router to browser certificate exceptions. You might need to do it again every time the certificate is regenerated. If the certificate warning page reappears again for the same router at the same browser, it might not be automatically trusted as it could be a malicious device impersonating your router trying to steal your credentials. #endif [Generate a new self-signed certificate] [Generate a new certificate request] / [Import the signed certificate] # if a CSR was generated [Generate a new Let's Encrypt certificate] # it would be a nice add-on [Remove current certificate and disable encryption] The next luci request will redirect the browser to https:// My 2 cents, --- Luiz Angelo Daros de Luca luizl...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 17:39, Fernando Frediani wrote: Hi. I don't really see having HTTPS by default as something that make such a difference for most common users nor as a major security issue in the context it is used at the cost it puts, which may seems not too much but I always think of the very minimal for a default image and HTTPS isn't something really necessary for I would say most scenarios. Yes you have already said that you don't think people at home need HTTPS, but I still think it makes sense to have it in all devices that aren't limited by low flash space, for the reasons I already mentioned. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
>> I think making use of self-signed certificates in production is a bad >> idea because (1) it reinforces poor practices, namely electing to trust >> a self-signed certificate and (2) it does not authenticate the >> server/router, a critical piece of the TLS security model. > maybe, but it's still better than sending all communication to the > management interface as plain text. >> My point of view is that we should delay HTTPS-by-default until we have >> a scheme for establishing the identity of the router. Until then, we >> should be honest and make use of HTTP. What is the difference between transmitting packets containing cleartext and transmitting encrypted packets to a party whose identity you do not know? > nobody is working on that, and in most cases it's not really possible. You > always have a point where the user has to make the call of trusting the > device's ID or code or something. Yes. This is true, and trusting CAs is a specialization of this. I understand that we do not have a scheme yet, and the necessary out-of-band channels in a router are limited. What I am arguing is that just falling back on self-signed certificates in order to turn on HTTPS is not a good solution and is in fact counter-productive. -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
Hi. I don't really see having HTTPS by default as something that make such a difference for most common users nor as a major security issue in the context it is used at the cost it puts, which may seems not too much but I always think of the very minimal for a default image and HTTPS isn't something really necessary for I would say most scenarios. Again I am not against using HTTPS but rather leaving it as optional for those who really want to enable. So not really concerned about the low flash devices, but because this will be yet another thing to increase the size of the default image. On 20/11/2020 13:32, Alberto Bursi wrote: On 20/11/20 17:17, Fernando Frediani wrote: Hi Alberto On 20/11/2020 13:09, Alberto Bursi wrote: The only thing I can accept as a valid complaint against https by default is the increased minimum space requirements, everything else I really don't understand nor agree with. It's exactly this I am referring to when I talk about the extras not the steps the user will take to enable it. So why I mentioned to leave it as optional and easy to do for those who wish (and have space) to have it. Devices with low flash space (and RAM) are already receiving special treatment (different compile options, different default packages) to lower space footprint. These devices can (should?) be left out of the "https by default" easily. But I would be strongly against degrading security for everyone just because of these devices. -Alberto Regards Fernando Yes it is nice to have everything ready and automated to be done with a few clicks for those cases that require it. In fact I think this would be a better solution for now so it will be possible to gather gradually this transition (or not) from HTTP to HTTPS even for local/lan applications and see how often people would opt to use it. Still should it end up having HTTPS by default I see self-signed certificates are the way to go. Yes there are the warnings and I really don't think there is any issue with it. Those accessing the router Web Interface are not 'normal' Internet users and they know what they are doing so the warning from self-signed certificates should not be a surprise for them. And those cases when admins prefer they can always replace the self-signed one for Let's Encrypt for example. Regards Fernando -Alberto ___ 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 17:17, Fernando Frediani wrote: Hi Alberto On 20/11/2020 13:09, Alberto Bursi wrote: The only thing I can accept as a valid complaint against https by default is the increased minimum space requirements, everything else I really don't understand nor agree with. It's exactly this I am referring to when I talk about the extras not the steps the user will take to enable it. So why I mentioned to leave it as optional and easy to do for those who wish (and have space) to have it. Devices with low flash space (and RAM) are already receiving special treatment (different compile options, different default packages) to lower space footprint. These devices can (should?) be left out of the "https by default" easily. But I would be strongly against degrading security for everyone just because of these devices. -Alberto Regards Fernando Yes it is nice to have everything ready and automated to be done with a few clicks for those cases that require it. In fact I think this would be a better solution for now so it will be possible to gather gradually this transition (or not) from HTTP to HTTPS even for local/lan applications and see how often people would opt to use it. Still should it end up having HTTPS by default I see self-signed certificates are the way to go. Yes there are the warnings and I really don't think there is any issue with it. Those accessing the router Web Interface are not 'normal' Internet users and they know what they are doing so the warning from self-signed certificates should not be a surprise for them. And those cases when admins prefer they can always replace the self-signed one for Let's Encrypt for example. Regards Fernando -Alberto ___ 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: 20.xx: postponse LuCI HTTPS per default
Hi Alberto On 20/11/2020 13:09, Alberto Bursi wrote: The only thing I can accept as a valid complaint against https by default is the increased minimum space requirements, everything else I really don't understand nor agree with. It's exactly this I am referring to when I talk about the extras not the steps the user will take to enable it. So why I mentioned to leave it as optional and easy to do for those who wish (and have space) to have it. Regards Fernando Yes it is nice to have everything ready and automated to be done with a few clicks for those cases that require it. In fact I think this would be a better solution for now so it will be possible to gather gradually this transition (or not) from HTTP to HTTPS even for local/lan applications and see how often people would opt to use it. Still should it end up having HTTPS by default I see self-signed certificates are the way to go. Yes there are the warnings and I really don't think there is any issue with it. Those accessing the router Web Interface are not 'normal' Internet users and they know what they are doing so the warning from self-signed certificates should not be a surprise for them. And those cases when admins prefer they can always replace the self-signed one for Let's Encrypt for example. Regards Fernando -Alberto ___ 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: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 16:52, W. Michael Petullo wrote: I think making use of self-signed certificates in production is a bad idea because (1) it reinforces poor practices, namely electing to trust a self-signed certificate and (2) it does not authenticate the server/router, a critical piece of the TLS security model. maybe, but it's still better than sending all communication to the management interface as plain text. My point of view is that we should delay HTTPS-by-default until we have a scheme for establishing the identity of the router. Until then, we should be honest and make use of HTTP. nobody is working on that, and in most cases it's not really possible. You always have a point where the user has to make the call of trusting the device's ID or code or something. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 16:31, Fernando Frediani wrote: Yes, exactly it is only an issue when someone have to access the web interface via wifi. In a home environment that is a small issue. Not sure how it is a small issue when wifi is the main method used to connect to a router and the Internet in a home environment. In a more corporate environment there are two options: 1) access is done via wired network or 2) enable HTTPS, which make more sense. which means that now everyone that wants a secure system has to go for additional setup steps, or compile/assemble their own firmware images. And this for what, because of a one-time popup in the browser? Enabling HTTPS by default is still not worth in my view given the extras that come with it and I like the idea of keep the default as simple and possible. It is literally one additional click on a button in the browser, and you will never see that warning again in that browser after that. This is nothing if compared to the learning curve to actually install and configure OpenWrt additional functionality on a new device. The only thing I can accept as a valid complaint against https by default is the increased minimum space requirements, everything else I really don't understand nor agree with. Yes it is nice to have everything ready and automated to be done with a few clicks for those cases that require it. In fact I think this would be a better solution for now so it will be possible to gather gradually this transition (or not) from HTTP to HTTPS even for local/lan applications and see how often people would opt to use it. Still should it end up having HTTPS by default I see self-signed certificates are the way to go. Yes there are the warnings and I really don't think there is any issue with it. Those accessing the router Web Interface are not 'normal' Internet users and they know what they are doing so the warning from self-signed certificates should not be a surprise for them. And those cases when admins prefer they can always replace the self-signed one for Let's Encrypt for example. Regards Fernando -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
The only reason I see to have HTTPS and certificates in OpenWrt in my view is to give some layer of security for those accessing the router via Wifi or over the Internet for example. And only admins, who have setup the router or work directly with it will access it (not normal users) so they know well what they are doing to not find a problem to have a self-signed certificate, or if it's the case they may deploy (optionally and later on) a Let's Encrypt certificatate which will be in even fewer cases. Fernando On 20/11/2020 12:52, W. Michael Petullo wrote: I think making use of self-signed certificates in production is a bad idea because (1) it reinforces poor practices, namely electing to trust a self-signed certificate and (2) it does not authenticate the server/router, a critical piece of the TLS security model. My point of view is that we should delay HTTPS-by-default until we have a scheme for establishing the identity of the router. Until then, we should be honest and make use of HTTP. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
I think making use of self-signed certificates in production is a bad idea because (1) it reinforces poor practices, namely electing to trust a self-signed certificate and (2) it does not authenticate the server/router, a critical piece of the TLS security model. My point of view is that we should delay HTTPS-by-default until we have a scheme for establishing the identity of the router. Until then, we should be honest and make use of HTTP. -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
Yes, exactly it is only an issue when someone have to access the web interface via wifi. In a home environment that is a small issue. In a more corporate environment there are two options: 1) access is done via wired network or 2) enable HTTPS, which make more sense. Enabling HTTPS by default is still not worth in my view given the extras that come with it and I like the idea of keep the default as simple and possible. Yes it is nice to have everything ready and automated to be done with a few clicks for those cases that require it. In fact I think this would be a better solution for now so it will be possible to gather gradually this transition (or not) from HTTP to HTTPS even for local/lan applications and see how often people would opt to use it. Still should it end up having HTTPS by default I see self-signed certificates are the way to go. Yes there are the warnings and I really don't think there is any issue with it. Those accessing the router Web Interface are not 'normal' Internet users and they know what they are doing so the warning from self-signed certificates should not be a surprise for them. And those cases when admins prefer they can always replace the self-signed one for Let's Encrypt for example. Regards Fernando On 20/11/2020 11:46, Alberto Bursi wrote: On 20/11/20 14:22, Fernando Frediani wrote: I don't see having HTTPS by default in LuCI as something good or even necessary ? It's actually an unnecessary complication that could always be optional. One of the main reasons is that in many and probably most cases of a new deployed OpenWrt router there is still no Internet connection available. Also it doesn't seem to be that people need it since access by default is only done via the LAN interfaces. Not using SSL means anyone in the LAN can snoop the password to access the router. While this is a non-issue for most home wired networks, it is for wifi and most people will use wifi on their router. WPA2 is not going anywhere for a long while still and it is susceptible to deauth attacks. After the attacker has captured enough handshakes after the deauth they will know the wifi password. It just takes a while but there are plenty of automated tools to do that 24/7 like Pawnagotchi (a raspberry zero running a dedicated application) or wifi pineapples or whatever. Using SSL for web interface means the system is at least compartimentalized so in case someone breaks into the wifi/LAN they won't also take over the router as well. If someone for some reason wishes for example to expose the LuCI web interface to the internet than fine to have it running on HTTPS and that can be enabled by those who wish to operate in such way. As this example there are certainly others that justify to have a HTTPS but I don't they they are most. The same way I see as interesting to have an automated way to generate SSL Certificates (ex: via Let's Encrypt), but again, that should be optional to only those who wish to use HTTPS for their specific needs. Fernando On 20/11/2020 06:44, Karl Palsson wrote: "Paul Spooren" wrote: Hi, The current list of release goals for 20.xx states[0] that LuCI should use HTTPS per default. This works by creating on-device a self-signed certificate. Self-signed certificates result in warnings and may cause more harm than good, multiple discussion are found in the mail archive. As no clean solution seems in reach while 20.xx seems close, I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. This isn't a vote but a request for developer/user opinions. Very much in favour of leaving this off, self-signed isn't viable by default Sincerely, Karl Palsson ___ 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 14:22, Fernando Frediani wrote: I don't see having HTTPS by default in LuCI as something good or even necessary ? It's actually an unnecessary complication that could always be optional. One of the main reasons is that in many and probably most cases of a new deployed OpenWrt router there is still no Internet connection available. Also it doesn't seem to be that people need it since access by default is only done via the LAN interfaces. Not using SSL means anyone in the LAN can snoop the password to access the router. While this is a non-issue for most home wired networks, it is for wifi and most people will use wifi on their router. WPA2 is not going anywhere for a long while still and it is susceptible to deauth attacks. After the attacker has captured enough handshakes after the deauth they will know the wifi password. It just takes a while but there are plenty of automated tools to do that 24/7 like Pawnagotchi (a raspberry zero running a dedicated application) or wifi pineapples or whatever. Using SSL for web interface means the system is at least compartimentalized so in case someone breaks into the wifi/LAN they won't also take over the router as well. If someone for some reason wishes for example to expose the LuCI web interface to the internet than fine to have it running on HTTPS and that can be enabled by those who wish to operate in such way. As this example there are certainly others that justify to have a HTTPS but I don't they they are most. The same way I see as interesting to have an automated way to generate SSL Certificates (ex: via Let's Encrypt), but again, that should be optional to only those who wish to use HTTPS for their specific needs. Fernando On 20/11/2020 06:44, Karl Palsson wrote: "Paul Spooren" wrote: Hi, The current list of release goals for 20.xx states[0] that LuCI should use HTTPS per default. This works by creating on-device a self-signed certificate. Self-signed certificates result in warnings and may cause more harm than good, multiple discussion are found in the mail archive. As no clean solution seems in reach while 20.xx seems close, I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. This isn't a vote but a request for developer/user opinions. Very much in favour of leaving this off, self-signed isn't viable by default Sincerely, Karl Palsson ___ 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: 20.xx: postponse LuCI HTTPS per default
I don't see having HTTPS by default in LuCI as something good or even necessary ? It's actually an unnecessary complication that could always be optional. One of the main reasons is that in many and probably most cases of a new deployed OpenWrt router there is still no Internet connection available. Also it doesn't seem to be that people need it since access by default is only done via the LAN interfaces. If someone for some reason wishes for example to expose the LuCI web interface to the internet than fine to have it running on HTTPS and that can be enabled by those who wish to operate in such way. As this example there are certainly others that justify to have a HTTPS but I don't they they are most. The same way I see as interesting to have an automated way to generate SSL Certificates (ex: via Let's Encrypt), but again, that should be optional to only those who wish to use HTTPS for their specific needs. Fernando On 20/11/2020 06:44, Karl Palsson wrote: "Paul Spooren" wrote: Hi, The current list of release goals for 20.xx states[0] that LuCI should use HTTPS per default. This works by creating on-device a self-signed certificate. Self-signed certificates result in warnings and may cause more harm than good, multiple discussion are found in the mail archive. As no clean solution seems in reach while 20.xx seems close, I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. This isn't a vote but a request for developer/user opinions. Very much in favour of leaving this off, self-signed isn't viable by default Sincerely, Karl Palsson ___ 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: 20.xx: postponse LuCI HTTPS per default
Paul Spooren [2020-11-19 13:09:02]: Hi, > while 20.xx seems close, I don't share your view on this one, 21.xx is close, yes :-) Just being realistic here. So I would say, that if this issue should be tackled, there is still some time left to do so. > I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per > default. Do we need to make this hard decission? Can't we leave it to the end users? We need most of the SSL stuff for other parts, so why not benefit from that in other parts? For the start, can't we simply introduce some first time welcome page on HTTP, explain to the user, that HTTPS is available, the pros and cons of this solution and let the user decide? In less intrusive way, this welcome page/wizard could be replaced with some information box "HTTPS is just a moments away", so the user would need to explicitly request that HTTPS feature. There might be some better UX approach, but please try hard to move forward, not backward :-) -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
"Paul Spooren" writes: > The current list of release goals for 20.xx states[0] that LuCI should > use HTTPS per default. This works by creating on-device a self-signed > certificate. Self-signed certificates result in warnings and may cause > more harm than good, multiple discussion are found in the mail archive. I believe the certificate discussion is a side-track. The problem you are trying to solve is not specific to OpenWrt. I am all for making OpenWrt better than the rest of the world, but there's gotta be some realistic limits to that.. Every embedded device with https support use a self-signed sertificate of some sort today. OpenWrt can do that too. Doing so does not prevent a better solution in the future, if there ever is one. The underlying issue should be considered a browser security bug IMHO. Failing to support standalone embedded https is compromising security by making certificate warnings unavoidable. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
"Paul Spooren" wrote: > Hi, > > The current list of release goals for 20.xx states[0] that LuCI > should use HTTPS per default. This works by creating on-device > a self-signed certificate. Self-signed certificates result in > warnings and may cause more harm than good, multiple discussion > are found in the mail archive. > > As no clean solution seems in reach while 20.xx seems close, > I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs > `luci`) per default. > > This isn't a vote but a request for developer/user opinions. Very much in favour of leaving this off, self-signed isn't viable by default Sincerely, Karl Palsson OpenPGP-digital-signature.html Description: OpenPGP Digital Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
> From: Michael Richardson > Subject: Re: 20.xx: postponse LuCI HTTPS per default > Date: 2020-11-20, 7:26:44 AM EET > To: "Paul Spooren" , openwrt-devel@lists.openwrt.org > > > > Paul Spooren wrote: >> The current list of release goals for 20.xx states[0] that LuCI should >> use HTTPS per default. This works by creating on-device a self-signed >> certificate. Self-signed certificates result in warnings and may cause >> more harm than good, multiple discussion are found in the mail archive. > >> As no clean solution seems in reach while 20.xx seems close, I'd like to >> suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. > >> This isn't a vote but a request for developer/user opinions. > > I agree with postponing this. > I think that we need to do some work on this problem. > This is a subset (an easier subset actually) of a general IoT onboarding > problem. > > I would like to form a design-team to figure out what we can do in practice, > and I would be happy to lead/act-as-convenor it via a series online working > meetings if the group wants. > > The need for a PPPoE username/password is one of the challenges. I think we should keep the non-secure HTTP available as a fallback, because some web browsers, may refuse to connect to self-signed certificates. The following changes would keep compatibility, yet also help users switch to the secure interface. * If using HTTP at the login page, display a link to the HTTPS login. * Also display a link with some help: Why HTTPS is important. * The help should explain the warning about unsigned certificates. * Avoid automatic permanent redirect to HTTPS unless the user wants this. * The design should be easy to notice, yet not intrusive. Regarding the idea to use Let’s Encrypt, in theory part of the process can be automated, but OpenWRT still has to know the DNS name of the site. If Let’s Encrypt integration is provided, it would be better to enable and configure it manually. After that the system can update its certificate using a cron task. Georgi Valkov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
Paul Spooren wrote: > The current list of release goals for 20.xx states[0] that LuCI should > use HTTPS per default. This works by creating on-device a self-signed > certificate. Self-signed certificates result in warnings and may cause > more harm than good, multiple discussion are found in the mail archive. > As no clean solution seems in reach while 20.xx seems close, I'd like to > suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. > This isn't a vote but a request for developer/user opinions. I agree with postponing this. I think that we need to do some work on this problem. This is a subset (an easier subset actually) of a general IoT onboarding problem. I would like to form a design-team to figure out what we can do in practice, and I would be happy to lead/act-as-convenor it via a series online working meetings if the group wants. The need for a PPPoE username/password is one of the challenges. -- ] 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
R: 20.xx: postponse LuCI HTTPS per default
> Given that the first login via LuCI, on a fresh install, is not with a > password anyway. What if setting the initial password sets up > letsencrypt also. Then when letsencrypt's first successful cert install, > https gets enabled as the default and then requests the user reboot to > complete the setup and will force their next session to https. > > I agree that https with self-signed certs are not good, especially on a > first boot/install device. > My 2 cents, I still think that have a properly verified cert is madness. I really think that to address this the best way would be to add a big And very explicative alert to the first login page. The process would be 1. First boot --> First login (no password set) Append to the already present alert about password-less system, an alert about self signed cert and that the browser will tell that the router page will not be secure. (again this must be very explicative and easy to understand) 2. As soon as the user set a password, the webserver is restarted with http disabled/redirected and https now enabled. The user should now know that the page is secure and that he can whitelist/allowlist(for the inclusive people :D) it. This way the user won't be scared of unsecure page and can understand why the page is secure. Also if we want to push security to an upper level with self signed cert, we can ask the user to insert some data so that the self signed cert can be generated based on that and actually validated by the user (to prevent any MIT attack) > Cheers > Derek > > On 11/19/20 6:09 PM, Paul Spooren wrote: > > Hi, > > > > The current list of release goals for 20.xx states[0] that LuCI should > > use HTTPS per default. This works by creating on-device a self-signed > > certificate. Self-signed certificates result in warnings and may cause > > more harm than good, multiple discussion are found in the mail archive. > > > > As no clean solution seems in reach while 20.xx seems close, I'd like to > > suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. > > > > This isn't a vote but a request for developer/user opinions. > > > > Sunshine, > > Paul > > > > [0]: https://openwrt.org/docs/guide-developer/releases/goals/20.xx > > > > ___ > > 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: 20.xx: postponse LuCI HTTPS per default
Hi On 2020-11-19, TheWerthFam wrote: > Given that the first login via LuCI, on a fresh install, is not with a > password anyway. What if setting the initial password sets up > letsencrypt also. Then when letsencrypt's first successful cert install, > https gets enabled as the default and then requests the user reboot to > complete the setup and will force their next session to https. [...] This won't be possible in most cases. First of all you have a chicken an egg problem, as you'd have to set a password over a different management channel (e.g. ssh) - this is more of a media-breach, than accepting a self-signed certificate. Then there are a lot of cases where setting up internet access in an automated fashion simply isn't possible, at all, be it PPPoE (xDSL), having to use VLAN tagging, WAN over wireless or LTE connections, before even thinking about internal infrastructure. Users behind cgNAT (and that *very* common for cable, fibre or 4g/ 5g mobile users) simply don't have public IPv4 connectivity either (and often no IPv6 connectivity either). The next problem would be that this requires a public domain, which costs money and probably won't be easy to get sorted by many users. Yes, OpenWrt 'could' fill this gap, by handing out subdomains to the users, but this would require a lot of additional costly infrastructure and legal advice (what happens if a user doesn't behave and uses this for illegal activity, OpenWrt would be on the hook, at least first). Before even considering purely functional decisions, such as how to ensure unique DNS entries (no, as much as we'd like to, MAC addresses aren't always reliably unique, even if you ignore intentionally spoofed MACs) and stable over a factor reset. Without a quite advanced service backend (similar to dDNS providers, which OpenWrt is unlikely to become), you'd also end up with rather cryptic hostnames, which opens another can of worms (remembering it, introducing ant raising the risk of phishing attacks, etc.). Let's encrypt sounds like a great service, and it is for its intended use cases, but it utterly fails for mostly stateless embedded systems like routers, even more so for semi-internal (router behind a router, cgNAT, ...). I can't imagine any setup facilitating its features that would cover a significant portion of OpenWrt's most common use cases, without introducing serious problems and side-effects for a significant number of OpenWrt users - and/or would require heavy investments into OpenWrt's infrastructure (technical and legal). Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
Given that the first login via LuCI, on a fresh install, is not with a password anyway. What if setting the initial password sets up letsencrypt also. Then when letsencrypt's first successful cert install, https gets enabled as the default and then requests the user reboot to complete the setup and will force their next session to https. I agree that https with self-signed certs are not good, especially on a first boot/install device. Cheers Derek On 11/19/20 6:09 PM, Paul Spooren wrote: Hi, The current list of release goals for 20.xx states[0] that LuCI should use HTTPS per default. This works by creating on-device a self-signed certificate. Self-signed certificates result in warnings and may cause more harm than good, multiple discussion are found in the mail archive. As no clean solution seems in reach while 20.xx seems close, I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. This isn't a vote but a request for developer/user opinions. Sunshine, Paul [0]: https://openwrt.org/docs/guide-developer/releases/goals/20.xx ___ 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
20.xx: postponse LuCI HTTPS per default
Hi, The current list of release goals for 20.xx states[0] that LuCI should use HTTPS per default. This works by creating on-device a self-signed certificate. Self-signed certificates result in warnings and may cause more harm than good, multiple discussion are found in the mail archive. As no clean solution seems in reach while 20.xx seems close, I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. This isn't a vote but a request for developer/user opinions. Sunshine, Paul [0]: https://openwrt.org/docs/guide-developer/releases/goals/20.xx ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
