Posted: Fri Oct 31, 2014 11:16 Post subject: Re: https needs update
SimulationMan32 wrote:
I have this error in chrome:
ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION
I have found this on Kong 22000++ and Brainslayer 25203.
I don't know how to bug report so could someone do this for me please?
I am using Chrome Beta v39.0.2171.42 beta-m (64-bit)
Please fix this as it may become a problem for others.
P.S Has this something to do with heartbleed?
FF is going to turn off sslv3 support in upcoming release. This is no problem for latest models, all builds for units with nand flash already come with tls support. For older units it may not be possible to include tls support, due to the flash size limitation, this has to be evaluated.
For remote management you can always use ssh in order to create a tunnel to the webif on your router.
Joined: 28 Aug 2014 Posts: 135 Location: Winnipeg, MB, Canada
Posted: Fri Oct 31, 2014 21:05 Post subject: Re: https needs update
<Kong> wrote:
FF is going to turn off sslv3 support in upcoming release. This is no problem for latest models, all builds for units with nand flash already come with tls support. For older units it may not be possible to include tls support, due to the flash size limitation, this has to be evaluated.
For remote management you can always use ssh in order to create a tunnel to the webif on your router.
Hey Kong! Does this mean your going to look into it. I really like the convenience and security of https.
I've never been able to get HTTPS working on my LAN. It works if I login remotely. What am I missing?
I do have an internet filter on the computers, so maybe that is it. I end up in a loop with Chrome about the cert mismatch. Any ideas, or is this normal/expected for LAN access? _________________ R7000 Nighthawk - DD-WRT v3.0-r47033
R7000 Nighthawk - DD-WRT v3.0-r47033 ~~~~~~~~~~Dismantled for learning opportunities~~~~~~~~~~
WRT54Gv2
WRT54Gv8.2
I hate to resurrect an old thread, but I thought it might be better than creating a new one. Is there any work on this? Chrome 39 is now out of beta and I'm seeing this issue still in r25408
Joined: 28 Aug 2014 Posts: 135 Location: Winnipeg, MB, Canada
Posted: Fri Nov 28, 2014 21:25 Post subject:
I am using Chrome 39 (Beta Channel) and I have not found this issue present in dd-wrt 25408. I don't know why though...? _________________ KONG Builds for R7000, AC68U
Brainslayer for everything else
how do I enable TLS in BS Build 23929?
Firefox and Chrome are unable to connect (as stated in the first posting)
I have a Linksys E3000 - I think using TLS should be no problem?
Posted: Sat Nov 29, 2014 17:20 Post subject: Same issue with
Issue seems present for:
Router Model Asus RT-N66U
Firmware Version DD-WRT v24-sp2 (11/20/14) mega - build 25408
K3 build (dd-wrt.v24-25408_NEWD-2_K3.x_mega_RT-N66U.trx)
but NOT for:
Router Model Linksys WRT54G/GL/GS
Firmware Version DD-WRT v24-sp2 (11/20/14) mega - build 25408
(dd-wrt.v24_mega_generic.bin)
Joined: 28 Aug 2014 Posts: 135 Location: Winnipeg, MB, Canada
Posted: Sun Nov 30, 2014 1:17 Post subject:
Is there a difference between K2.6 and K3.X? I have no problems with https on my e4200 or e3000 and I am running 25408 K2.6. _________________ KONG Builds for R7000, AC68U
Brainslayer for everything else
Posted: Mon Dec 01, 2014 4:28 Post subject: SSL Testing
First, as a long time dd-wrt user I am thankful for all of the hard work the devs do on this project. With the recent updates to all of the major browsers to improve the security of SSL, I'm sure the various issues that arise aren't easy to deal with. I'm currently experiencing issues connecting to my router over HTTPS, so I decided to dig in and see what I could figure out.
With this build, I can't connect with any major browser when it is on latest. I've got a version of FF 32, which is the last working version for FF. I started by looking at Wireshark to see the initial exchange and saw that the browsers would try all versions of TLS (1.2,1.1,1.0) and dd-wrt would respond by closing the connection by sending an ACK then FIN, ACK. Finally when SSLv3 was attempted by the browsers, dd-wrt responded with a Server Hello and selecting a cipher suite which was TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a). Although the cipher suite indicates TLS it is clearly communicating via SSLv3. This will eventually be more of a problem as browser vendors disable this, but the only browser so far that didn't attempt SSLv3 was FF. I was able to work around that in FF, but going into about:config and setting:
security.tls.version.min - 0 (It was 1.)
At this point, all browsers seem to be responding the same. It appears that after each browser receives the key, the browser resets the connection by sending a RST packet. I believe this is because the build uses 512 bit certificate. The current recommendations are to use at least 2048 bit certs and browser vendors are just outright rejecting anything that is considered too small. Out of curiosity, I downloaded the gencert.sh and openssl.cnf from source under /src/router/httpd/ and upload to my router. Running the gencert.sh script successfully created a cert at 2048, so it appears that wasn't used to create the cert for this build.
Therefore, I believe there are two issues:
1) No support for TLS
2) Small keys - (which I believe can be overriden; more on that later)
For issue 1, no TLS support, I dug through the code to see if there was an ability to override via config. I didn't find any way to override, but I did notice what appears to be a clear support of only SSLv2 & v3. To preface the follow, I'm not C developer so I may be missing something along the way in my analysis. Looking at /src/router/httpd/httpd.c (rev 23866) on line 1360 it calls SSLv23_server_method() to initialize the SSL_CTX. The comment behind line 1886 in /src/router/openssl/ssl/ssl.h where SSLv23_server_method(void) is defined says '/* SSLv3 but can rollback to v2 */'. Since this was the behavior I was experiencing it seemed to support what the comment says, but there may well be something else overriding that which I am missing. The only way to fix this would be at build time as far as I can tell. If there is a way to modify support protocols at runtime, someone please comment.
Issue 2 on the other hand, appears to be fixable via supplying your own certificates. I'm not sure what the best technique is for this. This post describes one technique, but I'm not overly experienced working in embedded environments. Is the only way to support this by having the new certs stored off of the router and mount via USB or network storage? Or is there some writable space in dd-wrt that can be used? I was having trouble getting directories created, so I thought I would post and come back to it afterward.
Not sure if this will help anyone, but I thought I would share what I had found so far. To the devs, if there is anyway I can assist, let me know. I'm happy to help.
