Experimental BcraFFY (OpenSSL 1.1.x) builds

[eclp]

New (special) test builds … with OpenSSL 1.1.x

https://onedrive.live.com/?authkey=!AGY2taGX02nVmWA&id=CCE5625ED3599CE0!1427&cid=CCE5625ED3599CE0

 

[ColinTaylor]

Are we meant to know what BcraFFY is?

 

[Mutzli]

All I found online is:
Better Care Reconciliation Act for Fiscal Financial Year 2017
I doubt that is it.

 

[eclp]

That's what we should ask Eric.

 

[greggy101]

BCRA = Bipartisan Campaign Reform Act (Wiki)
FFY = Final F... You (Urban Dictionary)

 

[RMerlin]

It's a geekish puzzle. Up to you to figure out what it means

These special builds are for testing something myself and another dev are experimenting with lately.

Sent from my Nexus 5X using Tapatalk

 

[greggy101]

Broadcom Core (CPU) Released (Restricted) Access
FFY as I mentioned previously! LOL

Are there any prizes to be awarded for this "reverse engineering"?

 

[Dabombber]

Up to you to figure out what it means

That's a bit rotten.

 

[Gitsum]

Is there more information somewhere?

 

[greggy101]

I loaded it on AC88U in AP mode. Was hoping to see this (pic attached) but no luck

 

[QuikSilver]

Does it add anything or take away anything? Any reason not to install it?

 

[greggy101]

Any reason not to install it?

not being curious enough

 

[Sonyrolfy]

I did a dirty upgrade via wifi on a RT-AC86U, with no Browser cleaning, just waited 30 secs. Everything runs as expected, as on 384-9, except network map is still a bit fragile/unreliable, and still get tunderstrucked by a dcdc, but we knew where thats comming from. Wifi and logs are good and strong on both Mhz, and holding. Not much to non assoc and disassoc. maybe due i pretty much disabled almost every feature that comes with Wifi Pro settings. Uptime 5 hours with 2 VPN clients. Couldn’t find any new novelties tough. Maybe we can get a changelog?

Thanks !

 

[SMS786]

It's a geekish puzzle. Up to you to figure out what it means

These special builds are for testing something myself and another dev are experimenting with lately.

Sent from my Nexus 5X using Tapatalk

Built-in DoT support?

 

[Odkrys]

This builds contain openssl 1.1.x.
I didn't install the firmware..
I guess it is for openvpn.

 

[Shasarak]

It's a geekish puzzle. Up to you to figure out what it means

That's "OpenSSL" in rot13.

 

[eclp]

Resolution:

OpenSSL 1.1.x and DoT Built-in and AiMesh-Merlin full support.

 

[Sonyrolfy]

Thats good. OpenSSL 1.1.1A

384.9: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
384.10: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA

https://www.openssl.org/news/changelog.html#x2

 

[RMerlin]

We are testing OpenSSL 1.1.1 with specific services (since I cannot replace 1.0.2 with code containing closed-source components that use it). By removing the old Beceem Wifi MAX driver (and its dedicated 1.0.0 OpenSSL version) and cleaning up unused files I was able to add 1.1.1a in parallel to 1.0.2 with no size increase to the firmware (there will be however an increase in memory usage, as there will be two different versions of OpenSSL in RAM). Only these specific services are linked against 1.1.1:

- mssl (used by httpd for the webui)
- OpenVPN (note that there's still no TLS 1.3 or Chacha support, that will come with OpenVPN 2.5.0)
- Curl and wget
- Inadyn (DDNS client)
- Net-SNMP
- acme-client-portable
- vsftpd (that must make Asuswrt-Merlin the first embedded software to support TLS 1.3 for FTP LOL)

(and maybe 1 or two more that I forgot).

For most services OpenSSL 1.1.1 was patched so it will favor Chacha ahead of AES for models that lack AES acceleration (which means slightly better performance for accessing the webui over https, for example).

Note that OpenSSL 1.1.1 is currently a bit slower than 1.0.2. We are still trying to figure out why. In an OpenVPN benchmark test I ran the speed was identical, however using the "openssl speed" (and "openssl11 speed") commands, there's a clear drop in performance. We do not know yet if it translates in real life performance loss as well, or if it's specific to these two userspace tool. These past few days we found a number of ways to slightly improve performance (and some of these improvements will also apply to 1.0.2), but it's still not there.

As the label says, these builds are currently considered experimental. It means there's no guarantee that 384.10 will end up with OpenSSL 1.1.1 in parallel to 1.0.2 - these builds are meant for everyone involved to test things out, see what's broken by it (1.1.1 is a major upgrade, with various API changes - they required a number of code changes so far). And to see the viability of doing a staged migration. First step would be having both 1.1.1 and 1.0.2 in parallel, with services using one or the other according to their capabilities.

Some things that will have to be done by Asus if we are to eventually ditch 1.0.2:

- rc (the main daemon)
- WTFast (will have to be done by the WTFast guys)
- AiCloud (requires lighttpd backports from upstream, plus recompiled closed source components)
- Let's Encrypt

I can at least say work is being done in that direction, but cannot say any more at this point, as that part is outside of my control.

So for now, things that need testing with these experimental builds:

- OpenVPN
- Webui over HTTPS
- DDNS
- Asus's mobile application (not sure if it was working properly with 384.9, but if it was, need to ensure the new OpenSSL didn't break it)
- Everything else in general, in cases other things would be broken by the changes. For instance, anything that uses Curl.


Again, to reiterate: these builds are meant as an experiment, and are no guarantee that 384.10 will end up with OpenSSL 1.1.1a. It will depend on how well the experiment goes.

 

[XIII]

Wow. This is a very nice surprise!

@kvic How can we use this with pixelserv-tls? (Can we now use the dynamic version, or will that favour the Entware version of OpenSSL?)

I will try tonight whether I can finally use the enhanced functionality of unbound.