DD-WRT and SSL Certificates
Hello!
In this publication, I will talk about some non-obvious points when using DD-WRT on your router. Probably, the regulars of DD-WRT will be clear here, but those who bet for the first time will have a lot of useful things.
In order to carry out everything described, we need a router that is supported by DD-WRT, a Linux computer with any more or less modern distribution (I have Debian Wheezy) and a thirst for new knowledge.
So, I finally got my hands on the already pretty old LinkSys E4200 firmware from DD-WRT. There were many complaints about the old original firmware from LinkSys. In particular:
1) Not all USB Mass Storage worked;
2) The worst WebUI brakes when entering via HTTPS;
3) Constant abuse of browsers on the SSL certificate, which seems to be generated every new session. Therefore, adding exceptions did not work;
4) The absence of a local DNS;
5) Well, and many other glitches.
In general, one Sunday evening I decided to fill in the DD-WRT. I did everything as described in the Wiki on my router, that is, I first uploaded the mini version, then upgraded to mega. The builds themselves were taken from the Router Database page, that is, assembly 21061. I
found the following jambs:
1) Chrome 39 refused to visit the router via HTTPS;
2) Firefox 33 also had some strange problems with HTTPS;
3) The new IE refused to make an exception for the self-signed certificate;
4) Chromium 38 also refused to visit the router via HTTPS;
5) SSH did not work. When I tried to log in, I received the response “Connection was closed by 192.168.1.1”
In general, I managed to successfully visit the router using HTTPS only with Konqueror.
Further picking revealed the following problem: the router web-server did not know TLS1. And in newer versions of browsers, due to the SSL3 POODLE vulnerability discovered some time ago, SSL3 seems to be disabled completely. On Linux Chromium, I disabled it myself.
In addition, the use of HTTPS “out of the box” DD-WRT is very strange, since the key itself is stored in the firmware in open form (we will see it firsthand), which in general negates the whole need of HTTPS.
So, the first thing to know when using DD-WRT:Spit on the version of firmware that Router Database offers you . Instead, find a more recent build for your router here .
Having updated the version to the latest, I solved two problems at once:
1) SSH worked. It turns out he was broken in the original build;
2) The router’s web server began to support TLS 1.2, which allowed it to be accessed by all browsers except Firefox 33 (although this was cured in 34) and IE and Chrome under Windows, although this can also be treated by setting up Windows policies, namely disabling the ban to ignore site certificate issues.
There is only one problem left - an unsafe certificate in the firmware. To cure it, we will have to parse the firmware into files, replace the certificate and key in it, and assemble the firmware back into one file. We will not compile firmware from source.
For our purposes, there is an excellent utility called Firmware Modification Kit, you can download its sources here . The utility must be assembled with a standard sequence of commands:
Further in the directory with firmware-mod-kit there are two scripts: extract-firmware.sh and build-firmware.sh. We start:
$ ./extract-firmware.sh ~ / Downloads / dd-wrt.v24-25408_NEWD-2_K2.6_mega-nv60k.bin
It is clear that your firmware file is indicated here. It unpacks the firmware into the fmk directory.
Next, we go to the fmk / rootfs / etc directory and see with our own eyes the certificate cert.pem, which the router presents when entering via HTTPS and the key from it key.pem, which is stored in clear text. There is a file privkey.pem - this is the same key.pem encrypted with the password "pass: password". And it is available to anyone who downloads this firmware.
So, our task is to generate our own key and certificate. I did this: I generated my own Certificate Authority (CA) - I still need it when configuring OpenVPN on the same router. Next, I generated a key / certificate pair for the router’s Web server and signed it with my CA, received the certificate and put the key in the specified location of the firmware. And I added my Certificate Authority as a trusted one on all my computers.
In order not to write twice how to do this, I will refer to a wonderful article on Habré about activities with CA and certificates. I note only two important points:
1) in the comments to this article there is a description of how to generate a certificate for multiple domains or IP addresses. I generated a certificate for the address 192.168.1.1, for the domain amber.loc (as I call the router inside the LAN), for the external IP address (if you have one) and for the external DNS name (you can take a dynamic DNS name) .
2) the generated key must be done without a password. * Paranoid mode ON * After creating and uploading the firmware, destroy both the key and the firmware file itself. * Paranoid mode OFF * . The password-protected privkey.pem key in the firmware is not used in any way.
After you have replaced the specified files in the firmware, run the script:
$ ./build-firmware.sh fmk /
and we get in the fmk directory a new firmware new-firmware.bin, which we upload to the router.
That's all.
In this publication, I will talk about some non-obvious points when using DD-WRT on your router. Probably, the regulars of DD-WRT will be clear here, but those who bet for the first time will have a lot of useful things.
In order to carry out everything described, we need a router that is supported by DD-WRT, a Linux computer with any more or less modern distribution (I have Debian Wheezy) and a thirst for new knowledge.
So, I finally got my hands on the already pretty old LinkSys E4200 firmware from DD-WRT. There were many complaints about the old original firmware from LinkSys. In particular:
1) Not all USB Mass Storage worked;
2) The worst WebUI brakes when entering via HTTPS;
3) Constant abuse of browsers on the SSL certificate, which seems to be generated every new session. Therefore, adding exceptions did not work;
4) The absence of a local DNS;
5) Well, and many other glitches.
In general, one Sunday evening I decided to fill in the DD-WRT. I did everything as described in the Wiki on my router, that is, I first uploaded the mini version, then upgraded to mega. The builds themselves were taken from the Router Database page, that is, assembly 21061. I
found the following jambs:
1) Chrome 39 refused to visit the router via HTTPS;
2) Firefox 33 also had some strange problems with HTTPS;
3) The new IE refused to make an exception for the self-signed certificate;
4) Chromium 38 also refused to visit the router via HTTPS;
5) SSH did not work. When I tried to log in, I received the response “Connection was closed by 192.168.1.1”
In general, I managed to successfully visit the router using HTTPS only with Konqueror.
Further picking revealed the following problem: the router web-server did not know TLS1. And in newer versions of browsers, due to the SSL3 POODLE vulnerability discovered some time ago, SSL3 seems to be disabled completely. On Linux Chromium, I disabled it myself.
In addition, the use of HTTPS “out of the box” DD-WRT is very strange, since the key itself is stored in the firmware in open form (we will see it firsthand), which in general negates the whole need of HTTPS.
So, the first thing to know when using DD-WRT:Spit on the version of firmware that Router Database offers you . Instead, find a more recent build for your router here .
Having updated the version to the latest, I solved two problems at once:
1) SSH worked. It turns out he was broken in the original build;
2) The router’s web server began to support TLS 1.2, which allowed it to be accessed by all browsers except Firefox 33 (although this was cured in 34) and IE and Chrome under Windows, although this can also be treated by setting up Windows policies, namely disabling the ban to ignore site certificate issues.
There is only one problem left - an unsafe certificate in the firmware. To cure it, we will have to parse the firmware into files, replace the certificate and key in it, and assemble the firmware back into one file. We will not compile firmware from source.
For our purposes, there is an excellent utility called Firmware Modification Kit, you can download its sources here . The utility must be assembled with a standard sequence of commands:
$ ./configure
$ make
Further in the directory with firmware-mod-kit there are two scripts: extract-firmware.sh and build-firmware.sh. We start:
$ ./extract-firmware.sh ~ / Downloads / dd-wrt.v24-25408_NEWD-2_K2.6_mega-nv60k.bin
It is clear that your firmware file is indicated here. It unpacks the firmware into the fmk directory.
Next, we go to the fmk / rootfs / etc directory and see with our own eyes the certificate cert.pem, which the router presents when entering via HTTPS and the key from it key.pem, which is stored in clear text. There is a file privkey.pem - this is the same key.pem encrypted with the password "pass: password". And it is available to anyone who downloads this firmware.
So, our task is to generate our own key and certificate. I did this: I generated my own Certificate Authority (CA) - I still need it when configuring OpenVPN on the same router. Next, I generated a key / certificate pair for the router’s Web server and signed it with my CA, received the certificate and put the key in the specified location of the firmware. And I added my Certificate Authority as a trusted one on all my computers.
In order not to write twice how to do this, I will refer to a wonderful article on Habré about activities with CA and certificates. I note only two important points:
1) in the comments to this article there is a description of how to generate a certificate for multiple domains or IP addresses. I generated a certificate for the address 192.168.1.1, for the domain amber.loc (as I call the router inside the LAN), for the external IP address (if you have one) and for the external DNS name (you can take a dynamic DNS name) .
2) the generated key must be done without a password. * Paranoid mode ON * After creating and uploading the firmware, destroy both the key and the firmware file itself. * Paranoid mode OFF * . The password-protected privkey.pem key in the firmware is not used in any way.
After you have replaced the specified files in the firmware, run the script:
$ ./build-firmware.sh fmk /
and we get in the fmk directory a new firmware new-firmware.bin, which we upload to the router.
That's all.