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

Database of Private SSL Keys Published

Discussion in 'Tomato Firmware' started by The_Unknown, Dec 20, 2010.

  1. The_Unknown

    The_Unknown Network Guru Member

  2. mstombs

    mstombs Network Guru Member

    Bit of a "root becomes root" exploit, if an attacker has access to your LAN, waiting for and sniffing your https traffic while you are configuring the router isn't the most obvious thing to worry about!

    The router https certificate is not used in comms between your browser and general https websites.

    Various options in tomato web gui to add your own SSL certificate CN name, regenerate and save in nvram, which shows it shouldn't be a firmware default, and Tomato not affected -

    But Tomato doesn't have a password on serial console access (dd-wrt does) - does that mean an attacker can hook up a serial connection and read the https cert using "nvram show command", he wouldn't want to steal the router or use the reset button because then you'd notice!
  3. RonWessels

    RonWessels Network Guru Member

    Not necessarily. If you have remote administration turned on, the SSL cracking becomes a bit more of a worrisome issue.

    But I do agree that it's not a really big deal. The referenced article seems to imply (at least my reading of it) that all secure web browsing going through your router (eg. your banking, etc) is compromised. As mstombs points out, that is just not so.
  4. ~nephelim~

    ~nephelim~ LI Guru Member

    Tomato HTTPS cert is generated through an /urs/sbin/gencert.sh script.

    cd /etc
    NVCN=`nvram get https_crt_cn`
    if [ "$NVCN" == "" ]; then
    	NVCN=`nvram get lan_ipaddr`
    cp -L openssl.cnf openssl.config
    for CN in $NVCN; do
            echo "$I.commonName=CN" >> openssl.config
            echo "$I.commonName_value=$CN" >> openssl.config
            I=$(($I + 1))
    # create the key and certificate request
    openssl req -new -out /tmp/cert.csr -config openssl.config -keyout /tmp/privkey.pem -newkey rsa:512 -passout [B]pass:password[/B]
    # remove the passphrase from the key
    openssl rsa -in /tmp/privkey.pem -out key.pem -passin [B]pass:password[/B]
    # convert the certificate request into a signed certificate
    openssl x509 -in /tmp/cert.csr -out cert.pem -req -signkey key.pem -setstartsecs $SECS -days 3653 -set_serial $1
    #	openssl x509 -in /etc/cert.pem -text -noout
    rm -f /tmp/cert.csr /tmp/privkey.pem openssl.config
    It appears that the private key is generated using an hardcoded password.

    But looks like that using the same openssl.config with the same hardcoded password generate slightly different private key (privkey.pem ) file each time.

    I don't really know how much effort would be needed to use the hardcoded password and (user defined) publicly available CN info to generate a matching private key (if possible at all).

    Maybe it could be possible to use also pass:$(nvram get http_passwd) to not take any chance for https but as far I know Tomato's VPN and SSH rely on user provided keys.

Share This Page