SSL certificates question

Discussion in 'Tomato Firmware' started by Mangix, Jan 8, 2014.

  1. Mangix

    Mangix Networkin' Nut Member

    Currently, most versions of tomato use an RSA 1024 bit key for the HTTPS connection. shibby used to use a 2048 bit one but stopped because of nvram limitations or something similar.

    Given that Google Chrome and Firefox are dropping support for 1024 bit RSA keys this year, it would probably be a good idea to switch things up in Tomato.

    A switch can be made to RSA 2048 or to ECDSA 256. The latter has more theoretical security but is not compatible everywhere. In fact, only Windows XP(ie, IE6-8 on XP) does not support ECDSA. All modern browsers do(including Chrome or Firefox on XP).

    ECDSA is also easier on the router side. Fewer ops are used for signing.

    Any thoughts?
  2. koitsu

    koitsu Network Guru Member

    The question then becomes how much code bloat gets added to the relevant SSL libraries in the base firmware by adding support for the ECDSA cipher. Honestly if I had to pick one or the other, I'd go with RSA 2048, solely because it's more universally used and understood.

    Options as I see them:

    1) We may have to start doing 2048-bit RSA keys only in firmwares made for router models that have the NVRAM space for it (ex. 60KBytes or 64KBytes),

    2) We may have to default to not supporting HTTPS at all unless there's a USB drive attached or a CIFS share available for the RSA private key (and/or CA) to be stored on.

    3) Consider gzip compressing the certificate, then base64-encoding it (to be stored in NVRAM). I tried this with a 1024-bit .crt file (file size = 1066 bytes). The gzip -9 result was 771 bytes (bzip2 and xz were larger!). The base64 encoding resulted in a 1042 byte file. :/

    4) Consider dedicating a small JFFS or Squashfs partition as part of flash (not NVRAM) for persistent storage of things like this -- say 128KBytes. Option #1 applies here though -- this could only be available on some routers, because the extremely small ones only have things like 4MBytes of flash.

    The problem here is really not something Tomato can deal with elegantly other than relying on external storage space, if you ask me. My opinion has always been to scrap SSL entirely from the firmware (including Dropbear and all that) and instead make everyone use Entware that wants such things. There would need to be code written for "dynamic tie-ins" within Tomato into Entware libraries (OpenSSL, etc.) to enable HTTPS, but still.

    I wish people would stop trying to make these residential routers out to be "powerhouse workstations", treating them like the equivalent of a Linux desktop PC. They aren't. We (the community/consumer) have no control over any of this, I'm sorry to say. I mean there's even cases already of people running out of NVRAM space on an RT-N16!

    And I've never understood this constant fixation with HTTPS within residential routers. I really, truly want to understand why people cannot use SSH with a port forward of --> (across the tunnel). It's secure, it works, and it removes the need for SSL within the webserver entirely. No more concerns over certificate sizes and all this (respectfully) sperglording. :)
  3. lancethepants

    lancethepants Network Guru Member

    I think koitsu is absolutely right. When I (rarely) need access to the gui, I use ssh or some form of vpn to gain access to my home network.
    Also, you don't have to be limited by what is built into the gui. Grab a (static) nginx or stunnel binary I have on my site, and you can set things up yourself, with any size key you like, and voila. You can even throw it on jffs, and forget about needing to rely on USB.
  4. Mangix

    Mangix Networkin' Nut Member

    A few comments:

    Dropbear is an SSH server and has nothing to do with OpenSSL.

    RSA 2048 does seem to be a better option. But I am not sure how much of an issue NVRAM space is.

    I agree with scraping HTTPS support. I ssh in to the router and use HTTP.

    A .crt file is IIRC already base64 encoded. A compressor should not be able to compress it as compressors work on finding patterns across the stream. Any cryptographic key should be random and unpredictable.

    OpenSSL is kind of nasty. The code is absolutely horrific. I think a better library like PolarSSL should be used. It's not as fast though...

    My suggestion was merely directed toward the current mods. Given that they have HTTPS support, they may wish to stay current. Again, I do believe that HTTPS support should be scraped as it does not buy you much in terms of security.

    Also a tiny nitpicking note: ECDSA is not a cipher. It's a signature algorithm. You actually can't use elliptic curves to encrypt(IES uses elliptic curves to derive they key but still uses AES).
  5. koitsu

    koitsu Network Guru Member

    Re: dropbear: I was under the impression dropbear relies on some form of SSL or cryptographic functions due to its link to libcrypt:

    root@gw:/tmp/home/root# ldd /usr/bin/dropbear => /lib/ (0x2aabf000) => /lib/ (0x2aae3000) => /lib/ (0x2aaf4000) => /lib/ (0x2ab13000) => /lib/ (0x2aaa8000)
    If I'm wrong (or possibly both wrong and right (ex. yes crypto, no SSL)), then cool, I've learned something.

    Re: RSA 2048 and NVRAM space and certificates: if they're base64-encoded, then that effectively means they're ASCII. Let's see what results we get for compression of an RSA 2048 bit .crt and the correlating private key. This is on my FreeBSD box:

    $ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout test.key -out test.crt
    Generating a 2048 bit RSA private key
    writing new private key to 'test.key'
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    Country Name (2 letter code) [AU]:US
    State or Province Name (full name) [Some-State]:California
    Locality Name (eg, city) []:Mountain View
    Organization Name (eg, company) [Internet Widgits Pty Ltd]:Snakes Inc.
    Organizational Unit Name (eg, section) []:
    Common Name (e.g. server FQDN or YOUR name) []:
    Email Address []:
    $ rm test.key
    $ ls -l test.*
    -rw-------  1 jdc  users  1484 Jan 11 00:01 test.crt
    $ cat test.crt
    -----END CERTIFICATE-----
    $ gzip -9 -k -v test.crt
    test.crt:  25.8% -- replaced with test.crt.gz
    $ bzip2 -9 -k -v test.crt
      test.crt:  1.221:1,  6.550 bits/byte, 18.13% saved, 1484 in, 1215 out.
    $ xz -9 -k -v test.crt
    test.crt (1/2)
      100 %  1204 B / 1484 B = 0.811
    $ ls -l test.*
    -rw-------  1 jdc  users  1484 Jan 11 00:01 test.crt
    -rw-------  1 jdc  users  1215 Jan 11 00:01 test.crt.bz2
    -rw-------  1 jdc  users  1101 Jan 11 00:01 test.crt.gz
    -rw-------  1 jdc  users  1204 Jan 11 00:01 test.crt.xz
    Looks like gzip (with level 9 compression) saves the most for these type of files. Not too surprised; bzip2 and xz aren't always better.

    Now let's see what byte counts we get, size-wise, of base64 encoded versions of the compressed versions:

    $ cat test.crt.gz | perl -e'use MIME::Base64 qw(encode_base64); local $/ = undef; print encode_base64(<>);' | wc
      20  20  1488
    $ cat test.crt.bz2 | perl -e'use MIME::Base64 qw(encode_base64); local $/ = undef; print encode_base64(<>);' | wc
      22  22  1642
    $ cat test.crt.xz | perl -e'use MIME::Base64 qw(encode_base64); local $/ = undef; print encode_base64(<>);' | wc
      22  22  1630
    Conclusion: we're better off just sticking the raw base64 RSA 2048 .crt into NVRAM natively. gzip -9 might make the file smaller (for things like a filesystem, e.g. the JFFS or Squashfs choice I mentioned), but base64 | gzip -9 | base64 results in a file 4 bytes larger than the original. Dang.

    Re: ECDSA: ah, I just assumed it was an alternate cipher. Cryptography, in case you haven't figured it out, is not exactly one of my fortes. I'm just a senior UNIX SA with extensive networking exp and some programming exp. to boot. Thank you for the information/education, I always appreciate it!
    Last edited: Jan 11, 2014
  6. shibby20

    shibby20 Network Guru Member

    we don`t have to save certs in nvram. RSA certs generated by tomato are non-authorised well why we should save them im nvram? Router will generate new cert/key by each reboot. Just dont check "Save In NVRAM" :)
  7. koitsu

    koitsu Network Guru Member

    Hmm, then what was @Mangix talking about when he said:

    Maybe misremembering something? Or are the automatically-generated crt/key 1024 bit due to CPU usage concerns (ex. takes too long to generate 2048 over 1024 on consumer routers)? I'm just guessing of course, I don't know the real reason.

    root@gw:/tmp# time openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout test.key -out test.crt
    Generating a 2048 bit RSA private key
    writing new private key to 'test.key'
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    . []:US
    . []:.
    . []:.
    . []:.
    . []:.
    6.42user 0.14system 0:06.56elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (0major+0minor)pagefaults 0swaps
    root@gw:/tmp# time openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout test.key -out test.crt
    Generating a 1024 bit RSA private key
    writing new private key to 'test.key'
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    . []:US
    . []:.
    . []:.
    . []:.
    . []:.
    2.84user 0.10system 0:02.96elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (0major+0minor)pagefaults 0swaps
  8. Porter

    Porter LI Guru Member

    I'd just like to address another problem we have in routers other than cpu power which is low entropy. Routers usually generate their keys at boot time when only low entropy is available. Therefore they rely on the pseudo random number generator /dev/urandom instead of /dev/random (which would block if not enough entropy is available).

    I'm not an expert on this matter but from what I understand this is another grave security concern. It looks like key length is only one of our problems.
  9. shibby20

    shibby20 Network Guru Member

    true. On RT-N16 it takes:
    1024bits = 3 seconds
    2048bits = 9 seconds

    but is this a problem?
  10. shibby20

    shibby20 Network Guru Member

    @Porter - sure, but command
    dd if=/dev/random bs=1 count=1024 of=$HOME/.rnd-test

    on RT-N16 takes a minutes!
  11. Porter

    Porter LI Guru Member


    Thanks for the real-world tests! :)

    Reading the wikipedia article again it just states that certificates generated with /dev/urandom shouldn't be used long-term. I highly doubt that many routers have an uptime of more than a year (just guessing), so this might indeed be not a big problem.
  12. schnappi

    schnappi Networkin' Nut Member

    Agreed regarding accessing a router via localhost...but HTTPS can come in handy when you are already on a LAN and a router won't let you loopback to connect via SSH and one doesn't feel like changing the SSH settings to the local ip of the router changing the loopback settings.
    Last edited: Apr 12, 2014
  13. Mangix

    Mangix Networkin' Nut Member

    I think I read git commit messages for the 2048 to 1024 change. I'm not sure really.

    Dropbear: I though it uses its own crypto stuff. The source directory has libtomcrypt. Well w/e. Doesn't matter.

    dev/random vs. dev/urandom: This is FUD spread by people who have no idea how this stuff works. It is true that /dev/random provides "random" numbers but /dev/random is dependent on interrupts, which routers generate very few of. /dev/urandom on the other hand takes /dev/random as input and uses sha256 to generate even more entropy. Since there are no preimage attacks on sha256 yet, it's safe to use.

    Although a small caveat: Newer kernels have improved /dev/random and /dev/urandom to be even better. Tomato unfortunately is on 2.6. Probably not too big of a deal.

    edit: Also not that *BSD does not differentiate between /dev/random and /dev/urandom. They are treated as the same for reasons stated above.

    On HTTPS: The security part is bogus. Tomato's certificates will generate a warning screen in any browser because they are not signed by a certificate authority. This means that if someone on the LAN used sslsniff to perform a MITM attack, it's the same screen on the browser. If your LAN is compromised, HTTPS will not save you.
    gfunkdave and koitsu like this.
  14. Porter

    Porter LI Guru Member


    I'd just like to comment on you saying this was FUD. This actually is a real-world problem.

    Cryptoanalysts have found weaknesses. There is a website dedicated to this problem . From their FAQ

    Also there is a research paper. Abstract:
    On page 13 of the research paper they give advice to developers and manufacturers.

    If you'd like to see a lecture about this specific problem, here is Nadia Heninger herself speaking about the vulnerability:

    She tells the audience that there are patches for the linux kernel. I'm asking myself whether those could be backported to the kernels Tomato uses? Are all other crypthographic implementations in Tomato up to date?
  15. MatteoV

    MatteoV Networkin' Nut Member

    Hi all.
    I am educating on ssl, certificates, openssl, pki web server infrastructure and all these stuff since the previous months, just for fun and learning.
    I managed to create my own very secure trusted CA, add it to my devices, create its intermediate CA, and then I started using it for signing my own stuff and trust/don't them. I am managing web servers (locally), in particular, and the idea born for them, plus they are needed to provide certificate revoke list and/or OCSP systems.
    The unit I'm using for routing, E4200, and TomatoRAF, helps identifying the right web servers like they were real (dns server's config), eventually switch them on if they are needed, and so on. In real web I don't own the used domain, well, not now, who knows :)

    In the previous days I tried extending the idea and generating a cert with my own CA for the ROUTER webgui. I answered first of all because I think one can actually FIX this point:
    in fact you can get a green screen if you sign the Tomato certificate with a CA the system in use trusts (your own CA, or an intermediary CA of your CA). That way I gained the value of recognizing MITM attacks or similar and you can do it too now.
    First thing to consider to do this is use these instructions . All the CA generation and the same for intermediate CA part is a bit more complex, but I guess you're already more skilled than me on that. If needed just drop me a question.
    There are a pair of important things I expected to see in Tomato, some already mentioned:
    1. implementation of the CA chain sent from the webgui. @godyang here did show how to do it. I found out Tomato RAF does not implement it @Victek , but it is important. What is it? Say you have one of the standard (as far as I understood) PKI done this way: (ROOT CA) => (INTERMEDIATE CA(s) signed by the ROOT CA) => (FINAL CERT(s) signed by the INTERMEDIATE CA(s)). The Tomato webgui will have the final cert ,signed by the intermediate CA. In short, there's no way for any system to understand the final certs have been signed by the trusted ROOT CA. That means every system will still give a red bar being unable to verify the upper cert. Instead, if the final subject will send out the complete CA chain, say, its own cert and the intermediate cert(s), then every system will say, ok, the intermediate has been verified by the ROOT CA I trust, the intermediate (now trusted) signed the final subject's cert, so everything is alright. This is implemented in web servers usually (Apache, etc). ATM I solved just adding the intermediate CA in the trusted list, not ideal, but green bar is there now.
    2. the space problem is an issue. I understand the fact nvram is the only way to integrate ssl in many cases. But, while there are so many options to grab and save data from/to an external storage, there is no such feature for the SSL stuff which can be a lot big (especially with the whole CA chain). I think Tomato should provide a simple system allowing to grab the pub cert (and CA chain) and the private key on external storage. That would be easy and nvram should only contain a path. The system will avoid regenerating certs if the path is OK.
    3. After following the first and second link, I actually solved the problem that Tomato regenerates certs at every boot even if regenerate checkbox is off and save in nvram is on (don't know why, can be a bug or the missing feature about CA Chain?): I made a simple script linking /tmp/etc/cert.pem and /tmp/etc/key.pem to my own external ones. Then restarting httpd service. That works. Nvram saved value is maintained at reboot but it is not used.
    Thanks all for listening. Hope I gave some hints and didn't learn so bad :)
  16. Mangix

    Mangix Networkin' Nut Member

    I'm very familiar with their work on this. But the thing is, mostly ODMs have or had this issue. I invite you to generate an ssh key on the router(or use the already generated ones found at /tmp/etc/dropbear/dropbear_rsa_host_key) and run them through You will not see a match. As far as DSA goes, it should not be used under any circumstance.

    The fact that I have not received a direct response to my /dev/random and /dev/urandom comment further reinforces my statements in the previous post.

    @MatteoV This is true but requires much more work than the average tomato user will bother to do. OTOH it's probably still vulnerable to sslstrip type attacks.

    HTTPS is probably the wrong thing to expect any real security from as it's easy to mess up.
  17. MatteoV

    MatteoV Networkin' Nut Member

    Thanks for this one @Mangix I just fixed it everywhere in the servers! I was able to do it even in the Tomato's webgui supplied by NGinx (described here ). I didn't know about this problem before, honestly, and it seems, well, a huge one!
  18. Porter

    Porter LI Guru Member

    I've checked my keys with their website. Indeed no problems. But this problem should have never existed in the first place.

    Well, my post was specifically aimed at your statement of /dev/random and /dev/urandom. Something like 'RSA and DSA can fail catastrophically when used with malfunctioning random number generators...' should have tipped you of.

    This is where Nadia starts to talk about /dev/random vs. /dev/urandom (35:05):

    At 44:23 she adds that certain crypto implementations have problems, too.
  19. lancethepants

    lancethepants Network Guru Member

    Very interesting clip (if you can get past all the 'ums'). Particularly interesting that portion where she speaks about routers. It appears most devices generate their keys very early on in the boot process, when there is little or no entropy. Plus are little guys have very few sources to query for randomness. The option to allow tomato to regenerate a new key every reboot may be unwise. This would be applicable for https. Hopefully by the time a user enables ssh access, the router may have had enough time to generate some randomness. Maybe a good idea to check your keys on a database like to check for weakness. Funny she takes a stab at dropbear too (which tomato uses), for using /dev/urandom. But like she says, it's not just them, everyone is doing it, unfortunately.

    Personally, I think using a self-generated cert for https access is no fun. Browsers won't recognize it and give you the green light unless you manually install it. Plus, who really is checking their self-signed cert to ensure it's still the original one they generated. Also, if it changes each reboot, how can you know it's safe and hasn't been later tampered with at some point after boot? In my opinion, if you're serious about https access security, I would get a signed cert from a trustworthy recognized source. There are places if you google you can get these for free. Then if you get anything other than the green light, you'll know somethings not right. Just depends on how paranoid you want to be. Doesn't hurt to be overly cautious. Of course chained certs are even more problematic when considering nvram space. Sounds like the perfect job for /jffs.
    I also have all wan facing ssh ports using two-factor authentication (where passworded access is enabled, including tomato). With entware and other resources, you can do just about anything.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice