DD-WRT and SSL certificates
Hello!
In this publication I will talk about some unobvious points when using DD-WRT on your router. Probably the DD-WRT regulars here will be all obvious, but for those who put for the first time there will be many useful things.
In order to implement all of the above, 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, finally I got my hands to hoist my rather old LinkSys E4200 firmware from DD-WRT. The old original firmware from LinkSys had a lot of complaints. In particular:
')
1) Worked not with all USB Mass Storage;
2) The terrible, wild brakes WebUI when entering through HTTPS;
3) Constant abuse of browsers for the SSL certificate, which seems to be generated every new session. Therefore, adding exceptions did not work;
4) Otstutstvie local DNS;
5) Well, many other glitches.
In general, one Sunday evening, I decided to fill in DD-WRT. I did everything as described in the Wiki on my router, that is, I first uploaded the mini version, then upgraded it to mega. The builds themselves were taken from the Router Database page, that is, build 21061.
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) 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, a successful visit to the router using HTTPS was only possible with the help of Konqueror.
Further tinkering revealed the following problem: the web server of the router was unable to TLS1. And in new versions of browsers, due to the SSL3 POODLE vulnerability discovered some time ago, SSL3 seems to be completely disabled. On Linux Chromium, I banned 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 the clear (later we will see it with our own eyes), which, in general, negates the whole need of HTTPS.
So, the first thing you need to know when using DD-WRT: spit on the version of the firmware that the Router Database offers you . Instead, find a more recent build for your router here .
Updating the version to the latest, I solved two problems at once:
1) SSH earned. It turns out he was broken in the original build;
2) The web server of the router began to support TLS 1.2, which allowed it to be accessed by all browsers except Firefox 33 (although it was cured in 34) and IE and Chrome under Windows, although this is treated by configuring the Windows policies, namely disabling the ban to ignore the problems of certificate sites.
There is only one problem unsafe certificate in the firmware. To cure it, we will have to disassemble the firmware by file, replace the certificate and key in it, and assemble the firmware back into one file. We will not compile the firmware from source.
For our purposes there is an excellent utility called the Firmware Modification Kit, you can download its source here . The utility needs to be assembled with a standard sequence of commands:
Further in the directory with the firmware-mod-kit there are two scripts: extract-firmware.sh and build-firmware.sh. Run:
$ ./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 in the fmk directory.
Next, go to the fmk / rootfs / etc directory and see the cert.pem certificate, which presents the router when accessing via HTTPS and the key from it, key.pem, which is stored in clear form. There is a privkey.pem file - 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 setting up OpenVPN on the same router. Next, I generated a key / certificate request pair for the router's Web server and signed it with my CA, I received the certificate and key in the specified firmware location. And I added my Certificate Authority as trusted on all my computers.
In order not to write twice how to do this, I refer to a wonderful article on Habré regarding activities with CA and certificates. I will note only two important points:
1) in the comments to this article there is a description of how to generate a certificate for several domains or IP addresses. I generated a certificate for the address 192.168.1.1, for the amber.loc domain (this is the name of the router inside the LAN), to the external IP address (if you have one), and to 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 lying in the firmware is not used at all.
After you replace 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 unobvious points when using DD-WRT on your router. Probably the DD-WRT regulars here will be all obvious, but for those who put for the first time there will be many useful things.
In order to implement all of the above, 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, finally I got my hands to hoist my rather old LinkSys E4200 firmware from DD-WRT. The old original firmware from LinkSys had a lot of complaints. In particular:
')
1) Worked not with all USB Mass Storage;
2) The terrible, wild brakes WebUI when entering through HTTPS;
3) Constant abuse of browsers for the SSL certificate, which seems to be generated every new session. Therefore, adding exceptions did not work;
4) Otstutstvie local DNS;
5) Well, many other glitches.
In general, one Sunday evening, I decided to fill in DD-WRT. I did everything as described in the Wiki on my router, that is, I first uploaded the mini version, then upgraded it to mega. The builds themselves were taken from the Router Database page, that is, build 21061.
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) 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, a successful visit to the router using HTTPS was only possible with the help of Konqueror.
Further tinkering revealed the following problem: the web server of the router was unable to TLS1. And in new versions of browsers, due to the SSL3 POODLE vulnerability discovered some time ago, SSL3 seems to be completely disabled. On Linux Chromium, I banned 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 the clear (later we will see it with our own eyes), which, in general, negates the whole need of HTTPS.
So, the first thing you need to know when using DD-WRT: spit on the version of the firmware that the Router Database offers you . Instead, find a more recent build for your router here .
Updating the version to the latest, I solved two problems at once:
1) SSH earned. It turns out he was broken in the original build;
2) The web server of the router began to support TLS 1.2, which allowed it to be accessed by all browsers except Firefox 33 (although it was cured in 34) and IE and Chrome under Windows, although this is treated by configuring the Windows policies, namely disabling the ban to ignore the problems of certificate sites.
There is only one problem unsafe certificate in the firmware. To cure it, we will have to disassemble the firmware by file, replace the certificate and key in it, and assemble the firmware back into one file. We will not compile the firmware from source.
For our purposes there is an excellent utility called the Firmware Modification Kit, you can download its source here . The utility needs to be assembled with a standard sequence of commands:
$ ./configure
$ make
Further in the directory with the firmware-mod-kit there are two scripts: extract-firmware.sh and build-firmware.sh. Run:
$ ./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 in the fmk directory.
Next, go to the fmk / rootfs / etc directory and see the cert.pem certificate, which presents the router when accessing via HTTPS and the key from it, key.pem, which is stored in clear form. There is a privkey.pem file - 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 setting up OpenVPN on the same router. Next, I generated a key / certificate request pair for the router's Web server and signed it with my CA, I received the certificate and key in the specified firmware location. And I added my Certificate Authority as trusted on all my computers.
In order not to write twice how to do this, I refer to a wonderful article on Habré regarding activities with CA and certificates. I will note only two important points:
1) in the comments to this article there is a description of how to generate a certificate for several domains or IP addresses. I generated a certificate for the address 192.168.1.1, for the amber.loc domain (this is the name of the router inside the LAN), to the external IP address (if you have one), and to 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 lying in the firmware is not used at all.
After you replace 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.
Source: https://habr.com/ru/post/244105/
All Articles