1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Enabled Web Access via HTTPS - invalid SSL?

Discussion in 'Tomato Firmware' started by delajed, Jun 28, 2009.

  1. delajed

    delajed Addicted to LI Member

    To be on the safer side, I decided it would be wise to limit web admin-access to the router to HTTPS. However, when I did this, it told me that my certificate was invalid. Should I be worried about this? (And if it is inspired, is my login info being broadcasted to the network I'm on?)

    I'm just wondering what steps I can take to ensure the security of my network.

    Thanks.
     
  2. ntest7

    ntest7 Network Guru Member

    This is normal since it's a self-signed certificate. Communications are still encrypted.
     
  3. leandroong

    leandroong Addicted to LI Member

    I don't know what happens, using firefox 25 beta 3, suddenly gives invalid SSL. It always prompt me again to accept the security certificate. Any solution?

    Tomato Firmware 1.28.0000 MIPSR1-112 K26 USB AIO
     

    Attached Files:

  4. Mangix

    Mangix Networkin' Nut Member

    Solution: Don't use firefox.

    More seriously: this error is completely normal. Browsers are not happy about self signed certificated which in normal circumstances indicate a security breach.

    Since this is a beta, it might be checking if the key size is less than 2048. By the end of this year, it's expected that most sites will be using a 2048-bit certificate. As such, Google chrome will start warning if a site has a certificate of less than 2048 in 2014 with some exceptions. dd-wrt recently upgraded the bit length from 512 to 2048.

    Shibby's mod uses 2048 bit certificates but other mods might be different.

    edit: Never mind. They all use 1024 bit now.
     
    Last edited: Oct 2, 2013
  5. koitsu

    koitsu Network Guru Member

    The issue shown in the above screenshot is unknown. The cert is indeed self-signed, which Firefox (as well as other browsers -- don't think Firefox is just the one who throws a hissy fit about it) will complain about.

    However, the error message shown says "with invalid information". Firefox complaining about self-signed certs results in a message that says "The certificate is not trusted because it is self-signed". The errors here are different.

    The issue is almost certainly because the CN (Common Name) in the certificate probably does not match 10.0.1.1.

    Port numbers should not be part of the CN (it does not matter if you're using port 401 or 443 (normal)). So the CN for the certificate should be 10.0.1.1.

    However, any attempt to access the webserver via SSL on an IP address (or FQDN) that is different than what's in the Common Name will throw a complaint/error (justifiably so) that looks very similar to what you're getting. The only solution for that is to have multiple certificates associated with multiple IPs (Common Names), which AFAIK is not supported in the webserver used by Tomato/TomatoUSB.

    I've attached an screenshot of Firefox when visiting an example webserver on the Internet which has a self-signed certificate which is broken/bad in 3 regards: #1 cert is self-signed, #2 FQDN being used to access the site does not match the wildcard Common Name (i.e. https://illusi0n.org/ will not match the wildcard), and #3 cert expired on 2013/7/16. I'm providing this purely as an example of how Firefox's informational messages differ depending on what the issue is, and the error shown in the screenshot of the previous post is not complaining about self-signed.
     

    Attached Files:

  6. leandroong

    leandroong Addicted to LI Member

    IE10 certification error image:
     

    Attached Files:

  7. leandroong

    leandroong Addicted to LI Member

    Addl firefox certification info:
     

    Attached Files:

  8. koitsu

    koitsu Network Guru Member

    Looks to me like the CommonName being generated in the certificate is wrong (apparent from the Firefox screenshot); it should be 1.0.1.1 not BTRouter2. After that the only "error" that should be shown is that the certificate is self-signed (nothing can be done about that).

    It looks like the existing code might be relying entirely on the lan_hostname or wan_hostname NVRAM variables, and/or possibly wan_domain.

    So whatever scripts/tools/etc. are generating the certs on TomatoUSB need to be modified, including the GUI (assuming there already is a GUI for it). The CommonName should be a field that the user can enter data into, pre-filled with the contents of NVRAM variable lan_ipaddr. A comment should be added somewhere in the GUI as well to inform the individual that 1) the "domain" or "IP" they enter into their browser needs to match the CommonName exactly, and 2) do not enter the port number (if applicable) into the CommonName.

    I have no idea if using a wildcard CommonName of just * (asterisk) by itself would work for general-use cases where someone has the webserver listening on multiple IPs due to their setup. Someone would need to try it. I am not volunteering. :)

    {opinion}
    I generally do not "support" the idea of using SSL natively on the routers for their GUIs; I'd much rather people just SSH into them and then use an SSH port forward to access the router (via HTTP, which is the encrypted because it's going across SSH). The effect is the same, but with a lot less BS. As someone who ran a hosting organisation for nearly 18 years, I can tell you that public-facing webservers with SSL really require you to use a single FQDN (or IP address) for the site, consistently 100% of the time, and to squelch the self-signed complaint the only solution is to get the cert signed by a CA (which isn't worth it in this case). Hence, SSH + port forward + HTTP makes a lot more sense, if you ask me.
    {/opinion}
     
    Last edited: Oct 3, 2013
  9. lancethepants

    lancethepants Network Guru Member

    I think Koitsu hits the nail on the head. I usually access the web gui interface over ssh, or through vpn.
    I never was much of a fan for tomato's built-in https support.
    As far as I know, I don't think it supports chained certificates, which is what I would use.
    There was a thread about this quite some time ago. Someone patched chain certificate support, but I don't think it ever made it to the mods afaik.

    If you're hardset for a good https gui experience, this is what I would do.

    1. Get a free browser trusted and recognized ssl certificate from startssl. (You would need your own domain name; and ddns if you have dynamic IP).
    2. Install stunnel or (I prefer) nginx from entware. TomatoRaf has nginx built in many of his firmwares. (I could most likely create a static binary of stunnel for use in /jffs for higher dependability).
    3. Setup nginx (or stunnel) to be a reverse ssl proxy, using the free cert obtained earlier.

    This will give you https access, and if you set it up correctly, you're browser won't barf over non-matching common-name, or self-signed certs.

    I don't use https for gui, but that's the way I would definitely do it if I did.
     
  10. leandroong

    leandroong Addicted to LI Member

  11. leandroong

    leandroong Addicted to LI Member

    I figure out the problem. Base on this google site, https://support.mozilla.org/en-US/questions/716343
    After, removing firefox private browsing mode, I was able to save router certificate permanently. Closing and reopening does not need to add exception for the certificate.

    Thanks to all
     

Share This Page