>> The main flaw in this scheme is that if someone were to actually telnet (or ssh) to yourdomain.com:443 they would immediately know you're running a ssh daemon on that port. That would raise huge red flags, since it would be pretty obvious that you're trying to cover your tracks.

Couldn't you set up iptables on yourdomain.com to drop all incoming packets that don't originate from your work desktop?

Or even better, to do some internal package shuffling so all packages but those from your work computer end up at an actual SSL server running at some different port. Or forward them to an external SSL server, some e-commerce system for example. (Don't know if the latter works, but it would be neat.. The first option would probably also raise the red flags)


>> Also, if your employer does periodic disk scans to detect third-party software, use a client like WinTin or yTin that doesn't have to be "installed" in the Windows sense. Compress the client and your scripts into a password-protected zip file, then rename that file to something drab like "temp.txt". When you're ready to play, just rename the file and extract its contents.

I put my laptop pr0n in a password protected zip file like that in a last-minute stint of paranoia when I went to thailand (it's illegal there). Much to my dismay, the contents of the folder could still be listed... So I'd say it's more important to rename the ytin.exe file before adding it to the password protected zip folder. (Since I assume a good disc scanning program will recognize the headers of archive files and check their contents anyway)