Revert "build: switch VERSION_REPO to HTTPS"

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(-)

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