Monday, July 07, 2008

The Firefox 3 SSL scam

I wonder how much money the Mozilla foundation received from Verisign, Thawte and/or other certification authorities to design their new SSL warning.

This is obviously designed so as to completely kill the use of self-signed certificates, forcing anyone who wants to use encrypted communications to pay money to some huge private (usually foreign) corporation for the privilege of simple stuff like encrypting login passwords for webmail.

One more step in the over-taking of the Internet by big money. And this time thanks to an "open source" organization.

This is supposed to be to improve security. Well, let's see how the security is improved.

To access the site, you need to click a "Or you can add an exception…" link. This expands to an additional warning, with a helpful "Get me out of here" button. That button helpfully sends you to Google (which happens to be the corporation paying the Mozilla developers).

The other button is "Add Exception...". In Firefox 2 (or Opera or others), you came immediately to this stage, where you could examine the certificate's content (including it's fingerprint to verify it), and could accept the certificate for this one time only.

The "improved security" in Firefox 3 will only let you add the certificate permanently! And doesn't let you know anything about this certificate you are about to accept forever. No way to display it's fingerprint, let alone the full content and who claims to have signed it. All you can do is blindly accept some unknown "thing" forever without any possible verification. Or go back to your Big Brother Google to search for another site.

There is a View button and a "Permanently add" check box, but both are greyed out! To enable them, you need to change some obscure about:config setting(s).

When I set up my webmail with a self-signed certificate, I also sent the users the certificate's fingerprint so that they could check it when accepting the certificate. Now, with Firefox 3, they have no (easy) way to check it. They will get used to yet more clicking through endless incomprehesible security dialogs (as with Vista's ridiculous UAC), or I could disable encryption, making my users feel comfortable when accessing their webmail, even though they would broadcast their password to anyone who cares to listen on the (often wireless) LAN.

Firefox is otherwise a very good web browser, and has been my preferred browser since version 0.9 or something, when it was called Phoenix (that was before it was called Firebird). Too bad it now bends so low before big business.

(See also The new SSL error pages in Firefox 3 suck.)

Labels: , , ,

Sunday, July 06, 2008

Remote support through NAT firewalls

Remote support with tools like Remote Desktop, (Tight|Real|Ultra)VNC servers and clients etc. normally requires forwarding ports through NAT routers/firewalls on one side or the other.

In practice, this doesn't quite work: guiding the remote user over the phone to configure his router is unrealistic. He probably doesn't even know his router's password.

An alternative is to use reverse connections, so you deal with the port forwarding on your own router. But this doesn't work either if you are away from home and connect through someone else's router.

There are services which allow you to use someone else's server in the middle of the connection. But these services are usually expensive, charging a monthly fee, and besides you may not want the data to go through some third party's server for security reasons.

One nice solution I found for Windows is to use UltraVNC Single Click, and to run an UltraVNC repeater on my own server. The principle is shown here.

(I'm still looking for an equivalent solution to connect to remote Macs, so if you have suggestions, please post a comment).

So if you have a server with a public IP address you can do this to support Windows users.

Install a repeater on your server:

For my Debian Linux server, I installed the Linux version of the UltraVNC repeater from here:
http://koti.mbnet.fi/jtko/uvncrepeater/repeater014.zip.

After unzipping and moving into the directory, compilation was trouble free with a simple make.

The rest consisted of the following steps (which were quickly adapted from this post, and could probably be improved):
  • Create a new user: adduser uvncrep (with the shell set to /bin/false)
  • Edit the .ini file to produce a /etc/uvncrepeater.ini resembling this (use your server's IP for the "ownipaddress" value, and any numbers you like for the "idlistx" values).
    [general]
    viewerport = 5900
    serverport = 5500
    ownipaddress = aaa.bbb.ccc.ddd
    maxsessions = 10
    runasuser = uvncrep
    allowedmodes = 2
    logginglevel = 3

    [mode2]
    requirelistedid = 0
    idlist0 = 1800
    idlist1 = 1801
    idlist2 = 1803

    [eventinterface]
    useeventinterface = false
  • Copy the repeater executable to /usr/local/sbin/uvncrepeaterd
  • Create /etc/init.d/uvncrepeater:
    #!/bin/sh

    PATH=/sbin:/bin
    UVNCREPPID=/var/run/uvncrepeater.pid
    UVNCREPLOG=/var/log/uvncrepeater.log
    UVNCREPRUN=/usr/local/sbin/uvncrepeater-log
    UVNCREPSVC=/usr/local/sbin/uvncrepeaterd
    UVNCREPINI=/etc/uvncrepeater.ini

    #if service file does not exist then exit the script

    if test ! -x $UVNCREPSVC ; then
    echo $UVNCREPSVC file was not found.
    echo Exiting...
    exit 2
    fi

    #Create the file to start the service if it does not exist

    if test ! -x $UVNCREPRUN ; then
    echo '#!/bin/sh' > $UVNCREPRUN
    echo 'exec' $UVNCREPSVC $UVNCREPINI '2>>' $UVNCREPLOG >> $UVNCREPRUN
    chmod +x $UVNCREPRUN
    fi

    case "$1" in
    start)
    echo -n "Running UltraVNC Repeater..."
    start-stop-daemon --start -b -m -p $UVNCREPPID --exec $UVNCREPRUN -- $UVNCREPLOG
    echo "."
    ;;
    stop)
    echo "Stopping UltraVNC Repeater..."
    start-stop-daemon --stop -p $UVNCREPPID
    rm $UVNCREPPID
    ;;
    *)
    echo "Usage: $0 {start|stop}"
    exit 1
    esac
    exit 0
  • Start the daemon with /etc/init.d/uvncrepeater start

Configure the Single Click executable

This is the small executable which your clients will download and run so that you can access their computer.

You can follow the instructions here.

For the helpdesk.txt file, you can use the one provided in custom.zip. However, it is a bit messy, and has a few typos/spelling mistakes. If you prefer, you can try this alternative template or this sample file instead. Both will need editing, particularly to set your server's hostname and one of the IDs you configured on the server .

Then set up a page from which your clients can download the SC executable.

Set up the UltraVNC viewer

After installing UltraVNC on your machine, start the viewer, and configure it like this:

VNC Server: ID:xxxx (where xxxx is the id number used in your repeater .ini file and when creating the SC executable). "ID" must be in uppercase, and there must be no space in the whole field.

Check Proxy/Repeater and enter your repeater's name or IP and port. For example:
repeater.example.com:5900

UltraVNC Viewer settings

Notes:

As far as I can tell, VNC Reflector looks like it would provide the same functionality as the repeater. I haven't tried it.

To support Vista users, there are some difficulties. Apparently there may be solutions in this lengthy thread, but I haven't tried them yet. (Fortunately, I have been able to mostly avoid Vista until now.)

And, as mentioned at the beginning, I would be glad to find a solution to support Mac users from my Windows box through my repeater.

Labels: , , , ,