Message ID | 20201125082859.609881-1-mail@aparcar.org |
---|---|
State | Under Review |
Delegated to: | Paul Spooren |
Headers | show |
Series | Revert "build: switch VERSION_REPO to HTTPS" | expand |
Paul Spooren <mail@aparcar.org> [2020-11-24 22:29:00]: Hi, > Using HTTPS for opkg dramatically slows down download of packages and reload > of indexes. do you've such dramatic numbers handy? > This was mostly introduced to secure the ImageBuilder. However with the > usign signature checking ability added to ImageBuilders, this becomes > obsolete. It is still possible to manually change feeds to HTTPS if desired, > but the default can be HTTP. I don't agree. From my point of view HTTPS is another protection layer and should be enabled by default. It's our safety net against issues like CVE-2020-7982[1] as we know, regressions are quite common in software world. > This was already requested via IRC and accepted somewhat accepted as the > current ustream-wolfssl implementation is broken. If it's broken, then it should be fixed. If it's unmaintained then the package should be disabled or removed. Disabling HTTPS is not going to fix that issue in ustream-wolfssl package as reported in FS#3465. -- ynezz
Hi, On 25-11-20, Petr Štetiar wrote: > Paul Spooren <mail@aparcar.org> [2020-11-24 22:29:00]: > > Hi, > > > Using HTTPS for opkg dramatically slows down download of packages and reload > > of indexes. > > do you've such dramatic numbers handy? For the imagebuilder, it increases the *total* build time (not just download time!) by +50%: http://lists.openwrt.org/pipermail/openwrt-devel/2020-September/031406.html On a device, I suspect it will be much worse but I can't currently test that. It shouldn't be too hard, just make sure to clean opkg files between each test to have a proper apple-to-apple comparison. The main problem is the lack of persistent connection, which means doing a full expensive TLS exchange for each separate file download, however small it is. It's a lot of crypto for a small CPU on devices, and if it's widely deployed it will also impact the load on the download server. Thus, it's not reasonable to have this by default in a release. I'm working on adding persistent connection support to opkg but it's not straightforward. Baptiste
Baptiste Jonglez <baptiste@bitsofnetworks.org> [2020-11-25 12:41:18]: Hi, > For the imagebuilder, it increases the *total* build time (not just > download time!) by +50%: > > http://lists.openwrt.org/pipermail/openwrt-devel/2020-September/031406.html I don't consider 10 seconds dramatic increase of time, but it of course depends on your use case. If you aim for faster builds you can disable the HTTPS (one sed command) by yourself, proxy/cache the downloads etc. One of the project's goal is standard installation secure by default, which for me means HTTPS in this case and I'm willing to make this 10 second tradeoff. > On a device, I suspect it will be much worse but I can't currently test > that. It shouldn't be too hard, just make sure to clean opkg files > between each test to have a proper apple-to-apple comparison. You hardly download 100 packages on device. You don't care if it takes two minutes, because you're not doing it every day, it's running in the background etc. > The main problem is the lack of persistent connection, which means doing a > full expensive TLS exchange for each separate file download, however small > it is. It's a lot of crypto for a small CPU on devices, You can turn off HTTPS if you prefer speed over maximum security > and if it's widely deployed it will also impact the load on the download > server. There should be CDN from Fastly soon, hopefully before the release, SFC has already revisited the deal/documents and AFAIK it's waiting for the final signature. > Thus, it's not reasonable to have this by default in a release. I don't agree. It has to be default in the next release :-) > I'm working on adding persistent connection support to opkg but it's not > straightforward. Great, thanks! Cheers, Petr
On Wed, Nov 25, 2020 at 03:11:24PM +0100, Petr Štetiar wrote: > Baptiste Jonglez [2020-11-25 12:41:18]: >> For the imagebuilder, it increases the *total* build time (not just >> download time!) by +50%: >> >> http://lists.openwrt.org/pipermail/openwrt-devel/2020-September/031406.html > > I don't consider 10 seconds dramatic increase of time, but it of > course depends on your use case. If you aim for faster builds you can > disable the HTTPS (one sed command) by yourself, proxy/cache the > downloads etc. > > One of the project's goal is standard installation secure by default, > which for me means HTTPS in this case and I'm willing to make this 10 > second tradeoff. +1 >> On a device, I suspect it will be much worse but I can't currently >> test that. It shouldn't be too hard, just make sure to clean opkg >> files between each test to have a proper apple-to-apple comparison. > > You hardly download 100 packages on device. You don't care if it takes > two minutes, because you're not doing it every day, it's running in > the background etc. +1 >> The main problem is the lack of persistent connection, which means >> doing a full expensive TLS exchange for each separate file download, >> however small it is. It's a lot of crypto for a small CPU on >> devices, > > You can turn off HTTPS if you prefer speed over maximum security +1 >> Thus, it's not reasonable to have this by default in a release. > > I don't agree. It has to be default in the next release :-) +1 >> I'm working on adding persistent connection support to opkg but it's >> not straightforward. > > Great, thanks! +1 Thanks to both of you for your efforts. I know everyone is trying to strike good trade-offs, but security should be prioritised by default. Thanks again, Sam
On Wed Nov 25, 2020 at 4:11 AM HST, Petr Štetiar wrote: > Baptiste Jonglez <baptiste@bitsofnetworks.org> [2020-11-25 12:41:18]: > > Hi, > > > For the imagebuilder, it increases the *total* build time (not just > > download time!) by +50%: > > > > http://lists.openwrt.org/pipermail/openwrt-devel/2020-September/031406.html > > I don't consider 10 seconds dramatic increase of time, but it of course > depends on your use case. If you aim for faster builds you can disable > the > HTTPS (one sed command) by yourself, proxy/cache the downloads etc. > > One of the project's goal is standard installation secure by default, > which > for me means HTTPS in this case and I'm willing to make this 10 second > tradeoff. > > > On a device, I suspect it will be much worse but I can't currently test > > that. It shouldn't be too hard, just make sure to clean opkg files > > between each test to have a proper apple-to-apple comparison. > > You hardly download 100 packages on device. You don't care if it takes > two > minutes, because you're not doing it every day, it's running in the > background > etc. > > > The main problem is the lack of persistent connection, which means doing a > > full expensive TLS exchange for each separate file download, however small > > it is. It's a lot of crypto for a small CPU on devices, > > You can turn off HTTPS if you prefer speed over maximum security > > > and if it's widely deployed it will also impact the load on the download > > server. > > There should be CDN from Fastly soon, hopefully before the release, SFC > has > already revisited the deal/documents and AFAIK it's waiting for the > final > signature. > > > Thus, it's not reasonable to have this by default in a release. > > I don't agree. It has to be default in the next release :-) > > > I'm working on adding persistent connection support to opkg but it's not > > straightforward. > > Great, thanks! I agree with all your points, it should be supported and it should be default. However worse than no security seem a false sense of security. Based on the discussion on IRC I understand that certificates are inadequately validated, allowing encryption with faked certs. Until somebody jumps on ustream-ssl and fixes the WolfSSL implementation, we should consider to disable it. Best, Paul
Paul Spooren <mail@aparcar.org> [2020-11-25 08:52:30]: Hi, > Until somebody jumps on ustream-ssl and fixes the WolfSSL > implementation, we should consider to disable it. FYI I've just posted hopefully fixes for those issue(s): uclient https://patchwork.ozlabs.org/project/openwrt/list/?series=219813 ustream-ssl https://patchwork.ozlabs.org/project/openwrt/list/?series=219811 The updated packages are available in my staging tree[1]. Please let me know if there is anything else preventing marking this patch as 'Not applicable'. Thanks! 1. https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=shortlog;h=refs/heads/staging Cheers, Petr
diff --git a/include/version.mk b/include/version.mk index b7f42e13bb..7d3c1ad640 100644 --- a/include/version.mk +++ b/include/version.mk @@ -32,7 +32,7 @@ VERSION_CODE:=$(call qstrip,$(CONFIG_VERSION_CODE)) VERSION_CODE:=$(if $(VERSION_CODE),$(VERSION_CODE),$(REVISION)) VERSION_REPO:=$(call qstrip,$(CONFIG_VERSION_REPO)) -VERSION_REPO:=$(if $(VERSION_REPO),$(VERSION_REPO),https://downloads.openwrt.org/snapshots) +VERSION_REPO:=$(if $(VERSION_REPO),$(VERSION_REPO),http://downloads.openwrt.org/snapshots) VERSION_DIST:=$(call qstrip,$(CONFIG_VERSION_DIST)) VERSION_DIST:=$(if $(VERSION_DIST),$(VERSION_DIST),OpenWrt) diff --git a/package/base-files/image-config.in b/package/base-files/image-config.in index b5cd90f615..3432db525a 100644 --- a/package/base-files/image-config.in +++ b/package/base-files/image-config.in @@ -183,7 +183,7 @@ if VERSIONOPT config VERSION_REPO string prompt "Release repository" - default "https://downloads.openwrt.org/snapshots" + default "http://downloads.openwrt.org/snapshots" help This is the repository address embedded in the image, it defaults to the trunk snapshot repo; the url may contain the following placeholders:
This reverts commit c1875d1ebbd4c4bad45d7c93cf012317f8ce1810. Using HTTPS for opkg dramatically slows down download of packages and reload of indexes. This was mostly introduced to secure the ImageBuilder. However with the usign signature checking ability added to ImageBuilders, this becomes obsolete. It is still possible to manually change feeds to HTTPS if desired, but the default can be HTTP. Signed-off-by: Paul Spooren <mail@aparcar.org> --- This was already requested via IRC and accepted somewhat accepted as the current ustream-wolfssl implementation is broken. Ref: https://freenode.irclog.whitequark.org/openwrt-devel/2020-11-20#28417525 include/version.mk | 2 +- package/base-files/image-config.in | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)