Discussion in 'Tomato Firmware' started by gawd0wns, Jun 6, 2014.
v1.0.1h has been released
Yup, I'm (we?) aware. The implications here are more serious than Heartbleed, FYI:
It'll be a matter of days/weeks before things get updated in TomatoUSB, so users should please be patient. And on TomatoUSB this only affects things like people using OpenVPN (as a client or server), or using the HTTPS "Remote Administration" capability (which people should just shut off and instead use SSH + port forward/tunnel).
Does this bug compromise private keys or the certificate authority for an OpenVPN setup? Or is it enough simply to update the firmware without needing to recreate the OpenVPN credentials?
My impression is that you would not need to regenerate keys in this case (i.e. the MITM attack could be used regardless). If you want to be safe, after things are fixed + firmware released, sure go ahead and regenerate keys. But my impression is that the attack can be used regardless.
But as usual the only people who seem to know the answers to these type of questions are those who actually understand the OpenSSL code (and all these bugs are proof there are too few people who do).
Any good soul would compile a static version of openvpn with the new openssl library?
You're a life saver, lancethepants!
Hey, I have a question, since I'm considering a new router - I'm guessing these static compiled binaries don't work on the new ARM routers, right? I'm trying to decide between an AC-68U (ARM) and AC-66U. (MIPS) It seems like the MIPS ones are the better bets right now, at least until ARM support catches up?
Right, binaries will not work across different architectures. For mips I like to use the toolchain that entware uses. I'm currently using a musl libc based toolchain for arm binaries, so I have been able to make a few I've wanted that way. Mips has been around for a while, is more stable, and you have entware there too (hopefully coming to arm). Arm is newer and still being heavily worked on, but should be significantly faster than their mips cousins. Just personal preference and needs.
Thank you sir
Thanks from me as well!
Hey all, quick question.
I'm looking to free up NVRAM space on my RT-N16. Since I'm already running OpenVPN on WAN Up, can I shove the certs onto cifs1 and point it to them via launch cmdline? (or perhaps edit the launch script somewhere?)
I was looking around on the manpage for the right switches, but it occured to me that someone here may have already done it, and a 2 minute post may save me an hour of digging. (The manpage is very verbose!)
You mean you set a script to start OpenVPN? Why not just check the box?
I used to put the OpenVPN certs in the JFFS partition on my RT-N16. That way they're always available.
Great! How did you do that?
The spots to enter in certs/keys default to NVRAM.
I have mine stored on a usb drive in the router. You would place these in the advanced tab of your OpenVPN setup in the custom configuration box. You can replace /tmp/mnt/ with /cifs1/ or wherever you are storing the certificates.
Go to Admin-JFFS and enable the partition.
Using vi, copy and paste your certificates and keys into their own files in /jffs.
Clear all the text boxes for keys in the VPN settings.
In the Advanced VPN settings, as mentioned above, add the lines
(or whatever you name the files)
The suggestion to put them on a USB drive is more flexible, since with JFFS enabled you can't upgrade the router's firmware.
Is this correct? OpenVPN seems to fail to start with anything in the custom configuration box. Hmm...
your path is wrong, space between / jffs
Do a " cat /jffs/ca.crt " and se if you can read ca.crt
Huh? There's no space there. Cat outputs all the files just fine.
Any other ideas? Could one of my other settings be stopping it from starting? I did change over to 4096 bit - is that too much for a router to handle?