[Fork] Tomato-ARM by @kille72


Status
Not open for further replies.
Code: 
TO-DO:
1. Problem with Radius/WPA2 Enterprise (since MultiWAN)
2. "Tweak" Switch3/4g/Watchdog
3. Slow 2.4GHz WiFi Netgear R6400
4. Problem with Wireless Client Mode (since MultiWAN)
5. Modeminfo in GUI
6. UPS ON/OFF in GUI

Will be #2 and #5 available in v140? Dont you know?
 
Elfew said:
Code: 
TO-DO:
1. Problem with Radius/WPA2 Enterprise (since MultiWAN)
2. "Tweak" Switch3/4g/Watchdog
3. Slow 2.4GHz WiFi Netgear R6400
4. Problem with Wireless Client Mode (since MultiWAN)
5. Modeminfo in GUI
6. UPS ON/OFF in GUI

Will be #2 and #5 available in v140? Dont you know?
Click to expand...

#1: Shibby would look at this problem, I don't know if he's done with any fix in version 140.
#2: It's my and Pedros project, we're testing it now. I come later with test versions 140.x that contain news for testing.
#3: According to Shibby, it's hard to fix it without new drivers.
#4: Has it ever worked?
#5: NeoX is working on this project, now he paused so I do not know when it's ready.
#6: Available in version 140.
#7: Pedro and I also work with, Clean/Modify Tomato UI according to the Web Consortium W3C standard.
#8: Tomato Autoupdate system will inform about new versions by Kille72 (in my builds).

There will be some more news in version 140 by Shibby, you'll see soon :)
 
Last edited:
In my tinc thread I have this.

I've integrated tinc 1.1preX. Version 1.1 fixes some security vulnerabilities in the tinc 1.0 branch. Currently 1.1 is still in pre-releases. Each pre-release is incompatible with other pre-releases, so you must make sure to use the same version everywhere, at least until 1.1 final is released. The gui will display the current version you are running.
Click to expand...

I was hoping 1.1 final was coming soon, but it has been years with only a few more pre-releases since. There are ways around tinc versioning if you can't upgrade all your routers at once. Pretty much mount binding static binaries stored in jffs over top the ones built in tomato. It's what I've done in the past.
 
RMerlin said:
As a heads-up, you and the other Tomato maintainers might want to take a look at my recent changes to the gencert.sh script used to generate the httpd SSL certificate. A number of changes were recently made to it to better handle newer versions of Chrome and Firefox, which are deprecating the use of the CN field in favor of the SANs:

https://github.com/RMerl/asuswrt-merlin/commits/master/release/src/router/httpd/gencert.sh

There's a few pieces in it that are specific to Asuswrt which will need to be adjusted/removed (like the DDNS part or the hardcoded router.asus.com), but otherwise it would be a fairly simple adaptation for Tomato.

The discussion that sparked these changes:

https://www.snbforums.com/threads/warning-on-chrome-58.38671/
Click to expand...

Chrome 58 indeed complains about SAN missing, but still renders stuff correctly (I use AT GUI, no idea about the default GUI, neither I care).

I tried to update this using several approaches, but ended up ripping off your code for the most part.

upload_2017-4-24_14-12-58.png

Regarding this:
Obsolete Connection Settings
The connection to this site uses a strong protocol (TLS 1.2), an obsolete key exchange (RSA), and a strong cipher (AES_128_GCM).

I have no idea how to generate a key with a different algorithm.

I wanted somehow to keep the epoch stuff when we generate certificates, but I had compilation issues that drove me so mad that I got rid of all hacks in the source. Binary size got up by 100KB but I don't care anymore. At least I don't have to worry anymore about getting back all hacks in place when updating OpenSSL.

https://bitbucket.org/AndreDVJ/advancedtomato-arm/commits/all

I am known of breaking stuff, so I initially didn't want to push my changes to my repo but did anyway. If anyone knows anything else that requires OpenSSL, let me know.

If anyone has anything to suggest as an improvement, feel free to do so, otherwise I'm done with that script. It doesn't look good, but it works at my end.
 
I am also pushing R7000 build (what's running on my router) and an AC68U build in my repo. Well since these two devices are the most popular ARM ones, will be easier to hear out if I broke something else.
 
AndreDVJ said:
Regarding this:
Obsolete Connection Settings
The connection to this site uses a strong protocol (TLS 1.2), an obsolete key exchange (RSA), and a strong cipher (AES_128_GCM).

I have no idea how to generate a key with a different algorithm.
Click to expand...

Make sure you implemented ECDHE support in mssl. My commits are here:

https://github.com/RMerl/asuswrt-merlin/commit/f6b875f2bbf330fe40bcb55031a6ccd0a2cad3be
https://github.com/RMerl/asuswrt-merlin/commit/b819b5f3c16760ba7e683b1c1a98ad66051f3167

Also note that some versions of Safari have broken ECDHE support. I'm not sure if disabling it for Safari is still relevant today, I haven't revisited that code since I initially implemented it.
 
Shibby implemented: https://bitbucket.org/pl_shibby/tomato-arm/commits/d5514b3cc69da85c17380920f978788e1be14aae

And yes I found by myself what broke. Rebooting the router, web interface starts before WAN, so router is still back at the start of UNIX's epoch time. Certificate gets created and is valid from that time until January 1st 1980.

I'm no good with OpenSSL, but I will try something to set these dates. Hacking back setstartsecs can be an option.
 
AndreDVJ said:
Shibby implemented: https://bitbucket.org/pl_shibby/tomato-arm/commits/d5514b3cc69da85c17380920f978788e1be14aae

And yes I found by myself what broke. Rebooting the router, web interface starts before WAN, so router is still back at the start of UNIX's epoch time. Certificate gets created and is valid from that time until January 1st 1980.

I'm no good with OpenSSL, but I will try something to set these dates. Hacking back setstartsecs can be an option.
Click to expand...

I believe that's why Asus uses the SECS global var, tho I never really investigated that specific bit.

I remember openssl also used to have a patch related to certificates, but I can't remember what it was for - been years since I've upgraded from the heavily patched openssl to a more vanilla-one. There was one specific patch which I've kept at the time.
 
Something else did the trick, and better than I wanted.

I added support for -startdate and -enddate arguments in req command for OpenSSL.

I still don't know how to enforce another key exchange algorithm. I copied/pasted AsusWRT's mssl.c, and had the same result. Something has to do with httpd, but I have no clue what to look.

I can't get much better than this, but at least I got somewhere.

upload_2017-4-25_13-54-3.png
 
Try a different browser and see what key exchange mechanism it uses.

You could also test everything by exposing your webui to the WAN, then running a test suite such as https://www.ssllabs.com/ssltest/ on your router's webui.

This is what I get here with my router:

Code: 
# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH secp256r1 (eq. 3072 bits RSA)   FS    128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH secp256r1 (eq. 3072 bits RSA)   FS    256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp256r1 (eq. 3072 bits RSA)   FS    128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp256r1 (eq. 3072 bits RSA)   FS    128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp256r1 (eq. 3072 bits RSA)   FS    256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp256r1 (eq. 3072 bits RSA)   FS    256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)    128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)    256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)    128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)    256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)    128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)    256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84)    256
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)    128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   WEAK    112
 
kille72 said:
#1: Shibby would look at this problem, I don't know if he's done with any fix in version 140.
#2: It's my and Pedros project, we're testing it now. I come later with test versions 140.x that contain news for testing.
#3: According to Shibby, it's hard to fix it without new drivers.
#4: Has it ever worked?
#5: NeoX is working on this project, now he paused so I do not know when it's ready.
#6: Available in version 140.
#7: Pedro and I also work with, Clean/Modify Tomato UI according to the Web Consortium W3C standard.
#8: Tomato Autoupdate system will inform about new versions by Kille72 (in my builds).

There will be some more news in version 140 by Shibby, you'll see soon :)
Click to expand...
That sounds like a plan :) I am looking forward!
 
Hey kille72, maybe you can help me when you get a chance. I'm running 138.13 and it had the same behavior in 138.14. When I put in dhcp-option DNS 209.222.18.222 in my openvpn config for my openvpn client it pushes this dns to everyone on the router. Is there a dnsmaq custom script or something you suggest on how I can prevent this? I'm still learning but I did try some IPtables scripts in the firewall but was unsuccessful. And I also want to thank everyone who is contributing to keep tomato alive, it is great firmware to use.
 
Status
Not open for further replies.

Back
Top