Hi, post jacking a bit as I had a similar question I was just looking into. Can we set the TLS version/ciphers we want for the HTTPS management portal in a persistent config file somewhere or is that baked into the build?
Based on Kongs comment above it almost sounds like its baked into the build but want to double check.
Thanks,
You have to bake it into the build so you'll have to compile it yourself or convince one of the devs to incorporate it.
I'm for TLSv1.2 and above but unfortunately there are people here that think "more secure than stock firmware" is good enough. Security is a sliding scale but I'd prefer mine not to be compromised through questionable configuration choices.
It would be possible to make a selection for it, but the webif is already a bit lame. Lots of help section in the webif are outdated etc. it lacks a beginner/advanced mode etc. and some sections should be reorganized. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
I've even provided a patch so most of the legwork is done. Once again, I ask that you consider applying this.
For the HTTP headers, I recommend reading Scott Helme's excellent series of blog posts as to why.
Next, I've also looked at dropbear and wish to make some suggested changes. The ticket is here. http://svn.dd-wrt.com/ticket/5714 wherein the changes are in the associated diff.
These are relatively small simple config changes but make a world of difference.
Joined: 06 Jun 2006 Posts: 7463 Location: Dresden, Germany
Posted: Thu Jul 20, 2017 8:18 Post subject:
this is all nonsense. remote administration is disabled by default and i never would advise someone to enable it and to expose the webgui to the internet and even then you cannot break it. because why? you still need a username and password. the ssl attacks are hased on decrypting traffic. but of someone reads the content of the webgui he still has no sensitive information to break in. the passwords are still extra encrypted. why do i keep alot of algorithms enabled? easy, some people are still like to use old browsers _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Joined: 06 Jun 2006 Posts: 7463 Location: Dresden, Germany
Posted: Thu Jul 20, 2017 15:45 Post subject:
i also checked testssl.sh and these weak ciphers arent included since a long time, except you're using a old 4 mb flash device which uses matrixssl. but there is no fix for it, its simply not enough space for a strong ssl library _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
this is all nonsense. remote administration is disabled by default and i never would advise someone to enable it and to expose the webgui to the internet and even then you cannot break it. because why? you still need a username and password. the ssl attacks are hased on decrypting traffic. but of someone reads the content of the webgui he still has no sensitive information to break in. the passwords are still extra encrypted. why do i keep alot of algorithms enabled? easy, some people are still like to use old browsers
pls actually look at the proposed patches, they do not require a new lib. if people still use old browsers, they need to upgrade. it's 2017 ferchristsake
given that the interface uses http basic auth and not proper http sessions, guess what? http basic auth has no mechanism to log out. plus it's plaintext over ssl, not
It looks like ddwrt how has TLSv1.3 (at least in the Kong version that I checked). So that's great!
But the overall list of ciphers offered is still less than ideal. Given that the browser vendors are *only* going to support TLSv1.2 and higher starting next year, it makes sense that anything older be disabled.
Using 'EECDH+AESGCM:AES+EECDH:!TLSv1:!AESCCM' as the cipher string will result in a good config
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Wed Aug 21, 2019 8:30 Post subject:
Semi-random comments. One of my ongoing tinkering projects is patching and updating oem stock firmware. The only problem is that, for instance in the case of oem Linksys firmware gpl code, both rc and httpd, among other things are pre-compiled binaries. There is no way to tweak or fix them save and except borrowing code from elsewhere, like any incarnation of Tomato. I probably haven't looked deep enough into the GPL source, perhaps, but it would be nice to have the un-compiled source for at least those two binaries. Mainly because some of the included packages for oem stock firmware cannot be changed easily or are not free to update to the latest security patched version, i.e. twonky media server, which is included in the oem stock firmware for Linksys routers. I haven't taken the time to figure out how to fool the pre-compiled rc and httpd to think minidlna is twonky. Anyhow, back towards the point, keeping up with security patches and updates is a never-ending process. Also, FWIW, in regards to the 2.6 Kernel, the most recent version is around 2 years old, 2.6.32.71 (MIPS), if you follow the MIPS community. I tried finding similar info for ARM, but came up short - but I probably wasn't looking as hard . That is probably the other tricky thing, looking at the security vulnerabilities in the 2.6.32 kernel, looking at the upstream patches (for newer kernels) and figuring out backports that will work. Some of the vulnerabilities I have noticed, though, shouldn't be configured items for a router kernel. I mean, who uses CD-ROM drives in a router save and except for an x86 or x86_64/amd64 hardware-based device? Anyhow, just some random things that came to mind reading through this post thread. Security is definitely something that should always be addressed, vulnerabilities mitigated and/or patched, etc., no doubt about that.
EDIT: The easiest 2.6 kernel to patch is actually 2.6.39.4, although there are some upstream patches that just won't work. There could be ways to somehow mitigate things with some kind of hack, but. The painfully obvious thing is, that most managed networking equipment doesn't use modern kernels, and other than possibly using proprietary hardware drivers to mitigate things, there really is no sense of system security in the devices whatsoever.
Last edited by kernel-panic69 on Mon Aug 26, 2019 2:21; edited 1 time in total
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Mon Aug 26, 2019 2:15 Post subject:
BrainSlayer wrote:
i also checked testssl.sh and these weak ciphers arent included since a long time, except you're using a old 4 mb flash device which uses matrixssl. but there is no fix for it, its simply not enough space for a strong ssl library
Just for giggles, I looked up matrixssl. The version in the svn repository is a little dated.