| Message ID | 20200829183321.17675-1-hauke@hauke-m.de |
|---|---|
| State | Rejected |
| Delegated to: | Hauke Mehrtens |
| Headers | show |
| Series | uhttpd: Increase default certificate validate from 2 to 10 years | expand |
Hi Hauke, > -----Original Message----- > From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] > On Behalf Of Hauke Mehrtens > Sent: Samstag, 29. August 2020 20:33 > To: openwrt-devel@lists.openwrt.org > Cc: Hauke Mehrtens <hauke@hauke-m.de> > Subject: [PATCH] uhttpd: Increase default certificate validate from 2 to 10 > years > > The user has to accept this specific certificate manually in his browser, the > browser does not trust it automatically, in this process the user gets a scary > message to approve. I am not aware of a way to improve this initial certificate > approval. > > After the certificate expired the user gets a scary message from his browser > again. This message looks very similar to a real Man in the middle (MitM) > attack, in the MitM attack the warning would complain about a wrong key, in > this case about an expired key. We should avoid that the user gets such > messages the more he gets such messages the more likely it is that he will > also approve this message when a real MitM attack is happening. > > When a normal certificate authority is used the user does not get a scary > message when the certificate changed as long as it is stilled signed by a CA. In > such cases it makes sense to have a short validity period because certificate > revocation practically does not work in the Internet. Certificate revocation > really does not work for self signed certificates, but exchanging certificates is > hard because of the scary messages users see. > > Even with a certificate validity of 2 years an attacker which has access to the > private key could use it for the rest of the time to do MitM attacks, which > would not be noticed. If a key gets compromised the user has to manually > remove the trust in all SSL clients anyway, no matter if it is valid for 2 or 10 > years. > > Lets not increase it to more than 10 years, because the algorithms used in the > certificate will probably not be sufficient any more in 10 years. > > The default self signed SSL certificate for Apache in Debian 10 is also valid for > 10 years. > > To increase the security of the users and also make it more user friendly > increase the validity to 10 years. I think you have a point, but due to the typical lifetime of our releases I'd choose 5 years. Best Adrian > > Modern browser only restrict the validity of certificates signed by globally > trusted CAs, not self signed certificates. > > Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> > --- > package/network/services/uhttpd/files/uhttpd.config | 2 +- > package/network/services/uhttpd/files/uhttpd.init | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/package/network/services/uhttpd/files/uhttpd.config > b/package/network/services/uhttpd/files/uhttpd.config > index 39089ca25b34..587c97402246 100644 > --- a/package/network/services/uhttpd/files/uhttpd.config > +++ b/package/network/services/uhttpd/files/uhttpd.config > @@ -116,7 +116,7 @@ config uhttpd main > config cert defaults > > # Validity time > - option days 730 > + option days 3650 > > # key type: rsa or ec > option key_type rsa > diff --git a/package/network/services/uhttpd/files/uhttpd.init > b/package/network/services/uhttpd/files/uhttpd.init > index 869f79bea20f..5f870f6ad6e1 100755 > --- a/package/network/services/uhttpd/files/uhttpd.init > +++ b/package/network/services/uhttpd/files/uhttpd.init > @@ -55,7 +55,7 @@ generate_keys() { > [ -x "$PX5G_BIN" ] && GENKEY_CMD="$PX5G_BIN selfsigned -der" > [ -n "$GENKEY_CMD" ] && { > $GENKEY_CMD \ > - -days ${days:-730} -newkey ${KEY_OPTS} -keyout > "${UHTTPD_KEY}.new" -out "${UHTTPD_CERT}.new" \ > + -days ${days:-3650} -newkey ${KEY_OPTS} -keyout > "${UHTTPD_KEY}.new" > +-out "${UHTTPD_CERT}.new" \ > -subj /C="${country:-ZZ}"/ST="${state:- > Somewhere}"/L="${location:-Unknown}"/O="${commonname:- > OpenWrt}$UNIQUEID"/CN="${commonname:-OpenWrt}" > sync > mv "${UHTTPD_KEY}.new" "${UHTTPD_KEY}" > -- > 2.20.1 > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 8/30/20 3:09 PM, Adrian Schmutzler wrote: > Hi Hauke, > >> -----Original Message----- >> From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] >> On Behalf Of Hauke Mehrtens >> Sent: Samstag, 29. August 2020 20:33 >> To: openwrt-devel@lists.openwrt.org >> Cc: Hauke Mehrtens <hauke@hauke-m.de> >> Subject: [PATCH] uhttpd: Increase default certificate validate from 2 to 10 >> years >> >> The user has to accept this specific certificate manually in his browser, the >> browser does not trust it automatically, in this process the user gets a scary >> message to approve. I am not aware of a way to improve this initial certificate >> approval. >> >> After the certificate expired the user gets a scary message from his browser >> again. This message looks very similar to a real Man in the middle (MitM) >> attack, in the MitM attack the warning would complain about a wrong key, in >> this case about an expired key. We should avoid that the user gets such >> messages the more he gets such messages the more likely it is that he will >> also approve this message when a real MitM attack is happening. >> >> When a normal certificate authority is used the user does not get a scary >> message when the certificate changed as long as it is stilled signed by a CA. In >> such cases it makes sense to have a short validity period because certificate >> revocation practically does not work in the Internet. Certificate revocation >> really does not work for self signed certificates, but exchanging certificates is >> hard because of the scary messages users see. >> >> Even with a certificate validity of 2 years an attacker which has access to the >> private key could use it for the rest of the time to do MitM attacks, which >> would not be noticed. If a key gets compromised the user has to manually >> remove the trust in all SSL clients anyway, no matter if it is valid for 2 or 10 >> years. >> >> Lets not increase it to more than 10 years, because the algorithms used in the >> certificate will probably not be sufficient any more in 10 years. >> >> The default self signed SSL certificate for Apache in Debian 10 is also valid for >> 10 years. >> >> To increase the security of the users and also make it more user friendly >> increase the validity to 10 years. > > I think you have a point, but due to the typical lifetime of our releases I'd choose 5 years. We should not create a new key and certificate after a sysupgrade, the old certificate should still be used, otherwise a user would see a scary warning message from his browser. A user can still replace the key and certificate before the old one expired without a problem. Hauke
It's worth mentioning that recent versions of macos since 10.15 have a restriction on certificate validity period, self-signed or not. It's a strong restriction that the browser ui will have no buttons or knobs to bypass the certificate validation, rendering such sites inaccessible. I remembered it's also a system wide enforcement that chrome on macos also respects this. [1] Requirements for trusted certificates in iOS 13 and macOS 10.15, https://support.apple.com/en-us/HT210176 > TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). [2] About upcoming limits on trusted certificates, https://support.apple.com/en-us/HT211025 > TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days. Regards, yousong
On Tue, Sep 01, 2020 at 06:45:02AM +0800, Yousong Zhou wrote: > It's worth mentioning that recent versions of macos since 10.15 have a > restriction on certificate validity period, self-signed or not. It's > a strong restriction that the browser ui will have no buttons or knobs > to bypass the certificate validation, rendering such sites > inaccessible. I remembered it's also a system wide enforcement that > chrome on macos also respects this. > > [1] Requirements for trusted certificates in iOS 13 and macOS 10.15, > https://support.apple.com/en-us/HT210176 > > > TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). > > [2] About upcoming limits on trusted certificates, > https://support.apple.com/en-us/HT211025 > > > TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days. There it also says: 'This change will not affect certificates issued from user-added or administrator-added Root CAs.' So why not force users of devices owned by $$$megacorp to install the self-signed as an additional CA? This could even be done via an installation tool, downloading the certificate from the router using a built-in copy of wolfssl or whatever, ignoring the certificates validity. Executing the installation program on $$$megacorp-os will of course trigger a cascade of extremely scary looking warnings and may require changing system settings to even allow running it at all. Another cascade of warnings will have to be dealt with when adding the self-signed as user-added Root CA. I'm pretty sure things like this are needed quite often in Intranet environments and shouldn't be hard to implement or document the stepts in the Wiki. After all, I wouldn't worry about any of this too much as long as there is /some/ way to make it work. And users of $$$megacorp-os are completely used to these kind of procedures as they are required all the time to get things working (unless you bought them through $$$megacorp-store which prohibits the use of FOSS licences, despite the fact that $$$megacorp-os is of course built on the shoulders of the FOSS movement and itself in great parts published under FOSS licences). Just my 2 cents... > > Regards, > yousong > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On Tue, 1 Sep 2020 at 06:45, Yousong Zhou <yszhou4tech@gmail.com> wrote: > > It's worth mentioning that recent versions of macos since 10.15 have a > restriction on certificate validity period, self-signed or not. It's > a strong restriction that the browser ui will have no buttons or knobs > to bypass the certificate validation, rendering such sites > inaccessible. I remembered it's also a system wide enforcement that > chrome on macos also respects this. > > [1] Requirements for trusted certificates in iOS 13 and macOS 10.15, > https://support.apple.com/en-us/HT210176 > > > TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). > > [2] About upcoming limits on trusted certificates, > https://support.apple.com/en-us/HT211025 > > > TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days. > > Regards, > yousong The other thing that just occurred to me is, chrome will not cache content fetched from links with invalid certificates. It's a WontFix decision [1] . I would guess a 400MHz MIPS CPU might have a hard time with this. [1] Issue 110649: Browser not caching files if HTTPS is used even if it's allowed by webserver via response headers, https://bugs.chromium.org/p/chromium/issues/detail?id=110649#c8 Regards, yousong
> Op 1 sep. 2020, om 01:21 heeft Daniel Golle <daniel@makrotopia.org> het volgende geschreven: > > On Tue, Sep 01, 2020 at 06:45:02AM +0800, Yousong Zhou wrote: >> It's worth mentioning that recent versions of macos since 10.15 have a >> restriction on certificate validity period, self-signed or not. It's >> a strong restriction that the browser ui will have no buttons or knobs >> to bypass the certificate validation, rendering such sites >> inaccessible. I remembered it's also a system wide enforcement that >> chrome on macos also respects this. >> >> [1] Requirements for trusted certificates in iOS 13 and macOS 10.15, >> https://support.apple.com/en-us/HT210176 >> >>> TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). >> >> [2] About upcoming limits on trusted certificates, >> https://support.apple.com/en-us/HT211025 >> >>> TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days. > > There it also says: > 'This change will not affect certificates issued from user-added or > administrator-added Root CAs.' > > So why not force users of devices owned by $$$megacorp to install the > self-signed as an additional CA? > > This could even be done via an installation tool, downloading the > certificate from the router using a built-in copy of wolfssl or > whatever, ignoring the certificates validity. > > Executing the installation program on $$$megacorp-os will of course > trigger a cascade of extremely scary looking warnings and may require > changing system settings to even allow running it at all. Another > cascade of warnings will have to be dealt with when adding the > self-signed as user-added Root CA. > I'm pretty sure things like this are needed quite often in Intranet > environments and shouldn't be hard to implement or document the stepts > in the Wiki. > After all, I wouldn't worry about any of this too much as long as there > is /some/ way to make it work. And users of $$$megacorp-os are > completely used to these kind of procedures as they are required all > the time to get things working (unless you bought them through > $$$megacorp-store which prohibits the use of FOSS licences, despite the > fact that $$$megacorp-os is of course built on the shoulders of the > FOSS movement and itself in great parts published under FOSS licences). > > Just my 2 cents... > > > >> >> Regards, >> yousong >> Why not apply kind of same policy as with the initial password? So at first boot just HTTP and a message prompting the user to switch to https with instructions for importing/setting the certificate. Bye, Paul
Yousong Zhou <yszhou4tech@gmail.com> wrote: > It's worth mentioning that recent versions of macos since 10.15 > have a restriction on certificate validity period, self-signed > or not. It's a strong restriction that the browser ui will have > no buttons or knobs to bypass the certificate validation, > rendering such sites inaccessible. I remembered it's also a > system wide enforcement that chrome on macos also respects > this. > > [1] Requirements for trusted certificates in iOS 13 and macOS > 10.15, https://support.apple.com/en-us/HT210176 > > > TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). > > [2] About upcoming limits on trusted certificates, > https://support.apple.com/en-us/HT211025 > > > TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days. > Are they blocking or planning to block non-http sites? This would be further arguments that self-signed certs by default for luci are actively bad. Latest reference I can find for chromium is that HTTP will be marked as insecure, but not with the click through horror show of self signed certs. https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure Sincerely, Karl Palsson
Forgive me for chiming in now, for I have not been following the discussion closely. Is this change (specifically, using these certs for "ordinary operation" of OpenWrt) being considered for the 20.0x release? Would it delay the RC1 release in any way? If so, I believe we should move it off that critical path, since there's a lot of uncertainty here. (We already have plenty in 20.0x - I worry that adding more tasks/features will push us to 20.1x, or worse.) If it's not included in 20.0x, we can definitely continue the experiments in snapshot to see whether its benefits are worth the difficulties. Thanks for listening. Rich > On Sep 1, 2020, at 9:57 AM, Karl Palsson <karlp@tweak.net.au> wrote: > > > Yousong Zhou <yszhou4tech@gmail.com> wrote: >> It's worth mentioning that recent versions of macos since 10.15 >> have a restriction on certificate validity period, self-signed >> or not. It's a strong restriction that the browser ui will have >> no buttons or knobs to bypass the certificate validation, >> rendering such sites inaccessible. I remembered it's also a >> system wide enforcement that chrome on macos also respects >> this. >> >> [1] Requirements for trusted certificates in iOS 13 and macOS >> 10.15, https://support.apple.com/en-us/HT210176 >> >>> TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). >> >> [2] About upcoming limits on trusted certificates, >> https://support.apple.com/en-us/HT211025 >> >>> TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days. >> > > Are they blocking or planning to block non-http sites? This would > be further arguments that self-signed certs by default for luci > are actively bad. > > Latest reference I can find for chromium is that HTTP will be > marked as insecure, but not with the click through horror show of > self signed certs. > > https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure > > Sincerely, > Karl Palsson_______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 9/1/20 12:45 AM, Yousong Zhou wrote: > It's worth mentioning that recent versions of macos since 10.15 have a > restriction on certificate validity period, self-signed or not. It's > a strong restriction that the browser ui will have no buttons or knobs > to bypass the certificate validation, rendering such sites > inaccessible. I remembered it's also a system wide enforcement that > chrome on macos also respects this. > > [1] Requirements for trusted certificates in iOS 13 and macOS 10.15, > https://support.apple.com/en-us/HT210176 > >> TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). > > [2] About upcoming limits on trusted certificates, > https://support.apple.com/en-us/HT211025 > >> TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days. > > Regards, > yousong Could someone please test how MacOS and iOS behave with a self signed certificate, valid for 10 years which was issued no later than today please. The changes which are applied today on 1. September are only affecting certificates signed by preinstalled CAs. This information from Apple does not tell how the system will behave with self signed certificates. The older changes will reject certificates valid for longer than 825 days (27 months). Apple also says this: > TLS server certificates must present the DNS name of the server in the > Subject Alternative Name extension of the certificate. DNS names in > the CommonName of a certificate are no longer trusted. Currently we do not set a "Subject Alternative Name", but we also do not really know the host name. We could set this to openwrt.lan, the default hostname. We will still over normal http, using https is only an addition. Hauke
On Wed, 2 Sep 2020 at 01:32, Hauke Mehrtens <hauke@hauke-m.de> wrote: > > On 9/1/20 12:45 AM, Yousong Zhou wrote: > > It's worth mentioning that recent versions of macos since 10.15 have a > > restriction on certificate validity period, self-signed or not. It's > > a strong restriction that the browser ui will have no buttons or knobs > > to bypass the certificate validation, rendering such sites > > inaccessible. I remembered it's also a system wide enforcement that > > chrome on macos also respects this. > > > > [1] Requirements for trusted certificates in iOS 13 and macOS 10.15, > > https://support.apple.com/en-us/HT210176 > > > >> TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). > > > > [2] About upcoming limits on trusted certificates, > > https://support.apple.com/en-us/HT211025 > > > >> TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days. > > > > Regards, > > yousong > > Could someone please test how MacOS and iOS behave with a self signed > certificate, valid for 10 years which was issued no later than today please. Tried with chrome on macos 10.15 (catalina), no way to proceed on the certificate warning page. With macos 10.13 (high sierra), chrome will allow you to ignore the check and continue on, but safari will warn after clicking "visit this website" that "You will have to modify your system settings to allow this." and prompt for a password to change "Certificate Trust Settings". Regards, yousong
Hauke Mehrtens <hauke@hauke-m.de> wrote: > > We will still over normal http, using https is only an > addition. So you will change <<option redirect_https '1'>> back to 0 by default then? So it's actually optional? It's currently hardset to 1 here: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/uhttpd/files/uhttpd.config;h=39089ca25b34bfdcc065682360030e3d3d6433ac;hb=HEAD#l13 This then forces the self signed problematic behaviour anyway. Sincerely, Karl Palsson
On 9/2/20 12:05 PM, Yousong Zhou wrote: > On Wed, 2 Sep 2020 at 01:32, Hauke Mehrtens <hauke@hauke-m.de> wrote: >> >> On 9/1/20 12:45 AM, Yousong Zhou wrote: >>> It's worth mentioning that recent versions of macos since 10.15 have a >>> restriction on certificate validity period, self-signed or not. It's >>> a strong restriction that the browser ui will have no buttons or knobs >>> to bypass the certificate validation, rendering such sites >>> inaccessible. I remembered it's also a system wide enforcement that >>> chrome on macos also respects this. >>> >>> [1] Requirements for trusted certificates in iOS 13 and macOS 10.15, >>> https://support.apple.com/en-us/HT210176 >>> >>>> TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). >>> >>> [2] About upcoming limits on trusted certificates, >>> https://support.apple.com/en-us/HT211025 >>> >>>> TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days. >>> >>> Regards, >>> yousong >> >> Could someone please test how MacOS and iOS behave with a self signed >> certificate, valid for 10 years which was issued no later than today please. > > Tried with chrome on macos 10.15 (catalina), no way to proceed on the > certificate warning page. > > With macos 10.13 (high sierra), chrome will allow you to ignore the > check and continue on, but safari will warn after clicking "visit this > website" that "You will have to modify your system settings to allow > this." and prompt for a password to change "Certificate Trust > Settings". Hi Yousong, Thanks for testing this. based on these restrictions I would NACK this change and stay with the 2 years we currently have. This way the user can "easily" acknowledge the self signed certificate. Easy means here without modifying system settings to installing an own certificate authority. We should probably add a process easily renew a certificate after 2 years. Hauke
diff --git a/package/network/services/uhttpd/files/uhttpd.config b/package/network/services/uhttpd/files/uhttpd.config index 39089ca25b34..587c97402246 100644 --- a/package/network/services/uhttpd/files/uhttpd.config +++ b/package/network/services/uhttpd/files/uhttpd.config @@ -116,7 +116,7 @@ config uhttpd main config cert defaults # Validity time - option days 730 + option days 3650 # key type: rsa or ec option key_type rsa diff --git a/package/network/services/uhttpd/files/uhttpd.init b/package/network/services/uhttpd/files/uhttpd.init index 869f79bea20f..5f870f6ad6e1 100755 --- a/package/network/services/uhttpd/files/uhttpd.init +++ b/package/network/services/uhttpd/files/uhttpd.init @@ -55,7 +55,7 @@ generate_keys() { [ -x "$PX5G_BIN" ] && GENKEY_CMD="$PX5G_BIN selfsigned -der" [ -n "$GENKEY_CMD" ] && { $GENKEY_CMD \ - -days ${days:-730} -newkey ${KEY_OPTS} -keyout "${UHTTPD_KEY}.new" -out "${UHTTPD_CERT}.new" \ + -days ${days:-3650} -newkey ${KEY_OPTS} -keyout "${UHTTPD_KEY}.new" -out "${UHTTPD_CERT}.new" \ -subj /C="${country:-ZZ}"/ST="${state:-Somewhere}"/L="${location:-Unknown}"/O="${commonname:-OpenWrt}$UNIQUEID"/CN="${commonname:-OpenWrt}" sync mv "${UHTTPD_KEY}.new" "${UHTTPD_KEY}"
The user has to accept this specific certificate manually in his browser, the browser does not trust it automatically, in this process the user gets a scary message to approve. I am not aware of a way to improve this initial certificate approval. After the certificate expired the user gets a scary message from his browser again. This message looks very similar to a real Man in the middle (MitM) attack, in the MitM attack the warning would complain about a wrong key, in this case about an expired key. We should avoid that the user gets such messages the more he gets such messages the more likely it is that he will also approve this message when a real MitM attack is happening. When a normal certificate authority is used the user does not get a scary message when the certificate changed as long as it is stilled signed by a CA. In such cases it makes sense to have a short validity period because certificate revocation practically does not work in the Internet. Certificate revocation really does not work for self signed certificates, but exchanging certificates is hard because of the scary messages users see. Even with a certificate validity of 2 years an attacker which has access to the private key could use it for the rest of the time to do MitM attacks, which would not be noticed. If a key gets compromised the user has to manually remove the trust in all SSL clients anyway, no matter if it is valid for 2 or 10 years. Lets not increase it to more than 10 years, because the algorithms used in the certificate will probably not be sufficient any more in 10 years. The default self signed SSL certificate for Apache in Debian 10 is also valid for 10 years. To increase the security of the users and also make it more user friendly increase the validity to 10 years. Modern browser only restrict the validity of certificates signed by globally trusted CAs, not self signed certificates. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> --- package/network/services/uhttpd/files/uhttpd.config | 2 +- package/network/services/uhttpd/files/uhttpd.init | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)