My pajamas:

Some pictures from Julian:

As stated before, I am going to assume a windows client as this is the most common scenario, if you are using another OS please adjust instructions as necessary. For windows we need the client itself, and for convenience a nice GUI to go on top of it. The most common package (and the best I’ve seen) is Mathias Sundman’s combined OpenVPN/GUI install, be sure to get the combined package and not the GUI only download. Install it, reboot if necessary.

Once OpenVPN is installed we need to add the SSL certs we created in the first section of this guide. These must be transported securely from the server to the client, if not your VPN’s security is compromised. Assuming the default install directory, copy ca.crt, ta.key, and your client-specific certs (say client.crt and client.key) to the
c:\Program Files\OpenVPN\config directory.

Next, we need to create a config file (client.ovpn) in the same directory with the following contents:

client
dev tun
proto udp
remote vpn.example.com 1194
nobind
persist-key
persist-tun
ca   ca.crt
cert client.crt
key  client.key
ns-cert-type server
tls-auth ta.key 1
cipher BF-CBC
comp-lzo
verb 6
mute 20

replay-window 256
mssfix 1260
;fragment 1260

;Uncomment below if you are using openvpn-auth for two-factor authentication
;auth-user-pass

If you’ve followed the guide carefully, you should now be ready to connect to your VPN server.

Double-clicking the OpenVPN icon in the system tray should automatically launch OpenVPN with the client.ovpn configuration, and before you know it you should be securely connected to the server. If you have been successfully connected you will have a virtual tunnel set up between you and the server. Running ipconfig should show that your virtual tunnel device is connected and has an IP assigned. Try pinging the server on the other end of the tunnel (the default gateway shown from ipconfig) - if you get a response you’re in business.

At this point we have a secure VPN connection, but it can be improved upon, which I will cover in part three of this series, VPNs and You: 3 - Hardening your OpenVPN solution.

Trouble-shooting:

If OpenVPN is having trouble contacting the server, make sure the server name is right in the config file, and that the server is running. If both of these are fine then you probably have a firewall issue (either on the local client, the server, or both). Also, if you are connecting to the server fine, but cannot connect to the machines behind the openvpn server, you may have other firewall issues or routing problems. For any of these (or other similar) issues, please see part four of this series, VPNs and You: 4 - Tweaking firewall and network settings for solutions.

• page was no longer valid XHTML due to some unencoded &s and reused object IDs
• icons were not all the same size
• no way to display text along with the icons
• no slashdot submission support
• ability to use blog categor(y|ies) in submission URLs, for tag fields for instance

I ended up fixing these myself, and in the hope that others will want these fixes/features I am making the new version available for download.

Installation directions can be assumed to be the same as the official v1.14 release.

Read on for details of what was changed . . .

I probably should have tried Sociable, but I didn’t, besides it would only have solved the first item, although adding sites in Sociable looks easier than adding them in Notable. Regardless, I didn’t try Sociable, I just did it myself. After some confusion about why my changes weren’t effecting anything (notable stores its settings in the blog DB, so changes in the script did nothing), things went pretty smoothly.

My first tactic for dealing with the DB issue was to delete the DB info to force it to read from the script again (not great), but I happened to run into someone else’s blog who was hacking on Notable also, and who had fixed this issue cleanly, so I stole his solution for that (Thanks Dave!). I also noticed that he had wanted text along with his icons as well, but he did it by adding the text to each icon - I wanted something more user-definable, something flexible.

Fixing the XHTML validation stuff was easy, just replaced the &s with &s where appropriate, and removed the IDs completely on the span classes. It would have been fairly easy to make them unique, but I really didn’t see a reason why they needed specific IDs anyway, so I just yanked ‘em.

Resizing the icons so they were all 16×16. Some I did manually, but most I just took directly from the different sites’ favicon.icos.

Next I added some options to the Notable option panel to allow user-input text for any site, and created some code to handle displaying it (and wrapping it in a wp-notable_text span class so you can CSS it however you like).

I added slashdot as an option, easy with the DB issue fixed.

Finally, I added some code to replace {{category}} with the categor(y|ies) the story is filed under (multiple categories are comma separated). I did not add this to all of the submission URLs of sites that could potentially take advantage of this (in fact I only did it for slashdot), but it is easy to do in the wp-notable.php file.

I also cooked up some CSS (also partly stolen from David Seah, CSS is not my strong suit) to present the icons and text cleanly. My relevent CSS entries are:

/* WP NOTABLE ADDONS */

.notable {
	width: 100%;
	border-top: 1px dotted #ccc;
	margin-top: 16px;
	padding-top: 3px;
}

.wp-notable-line {
	line-height:16px;
}

.wp-notable {
	float: left;
	padding-right: 8px;
	opacity: .50;
}

.wp-notable:hover {
	opacity: 1.0;
}

.wp-notable_image {
	vertical-align: bottom;
	border: none;
}

.wp-notable_text {
    font-family: small fonts, arial;
    font-size: 7pt;
    padding-left: 1px;
}

.wp-notable a:link    { color: black; text-decoration: none; }
.wp-notable a:visited { color: black; text-decoration: none; }

/* END WP NOTABLE */

Important note, with the “float: left” specified above it is important that you change the icon separator in the notable options to “no space”, otherwise you’re icons will all float to the left.

This CSS makes the icons 50% transparent in firefox and other browsers, turning them fully visible on mouse-over. For IE, however, they stay fully visible the whole time. I wasn’t able to get IEs alpha filter to work with the roll-over in the same manner, so I opted to make them always visible for IE.

I intend to submit my changes to the creator of Notable, but for now feel free to comment with questions or problems here.

-Tom

I found a WinAmp plug-in called Do-Something which looked promising, at the start of any new song it would do any (or any chain) of several actions. Most notable to me was submit a URL. The idea was simple enough, submit a url with the artist and song name (these it gets from the file tag), and a shared password, to a CGI script on the web server. The CGI would then update some file used in a SSI by the page, and poof, “Now Playing” would be up and running. Unfortunately, this simple method is not very secure…

Anyone able to sniff network traffic between the server and my computer could see the password in plain text and then submit anything they like to the CGI. Not only could this be used as method to post arbitrary code into my blog (XSS for instance), they could also do something really serious like post that I’m listening to John Tesh. In light of that, I set out to solve this old problem in the usual way: transmit a hash instead of the password. There is one additional step we will need to add for this method to be truly secure however, which I will discuss after I introduce the basics:

Take the ARTIST, the song TITLE, and your PASSWORD, and combine them together as follows:

Ex:
ARTIST: Weezer
TITLE: Freak Me Out
PASSWORD: ReplaceWithSecurePassword

OUTPUT: WeezerFreak Me OutReplaceWithSecurePassword

Now we take that OUTPUT, hash it with a strong hash function (say SHA1), and get:

HASHOUTPUT: 5c87ac46e7714c579c9e6401a049eb7fb635ad19

Now we send the TITLE, ARTIST, and HASHOUTPUT. The receiving CGI already knows the password, so it takes the ARTIST and TITLE you sent, and PASSWORD it knows, and hashes them and verifies that the HASHOUTPUT it calculates matches the HASHOUTPUT you sent. If it does, then all is good and it updates the “Now Playing” file, otherwise it ignores the request.

A few important things to note about this method:

• It does not reveal the password in plaintext as the original method did - Well that was the point wasn’t it?
• It uses a hash of the artist, song, and password, instead of just a hash of the password - this is important. If you don’t use the artist and title in the hash then the attacker doesn’t need the password anyway! The hash of the password alone won’t change. He can simply submit whatever artist, whatever title, and then use the same hash he captured from you earlier as it will not have changed. Concatennating the password with the other info serves to hide the password and ensure that a captured hash does no good to a would-be attackers.
• If you follow the second point carefully, it leads to a weakness in the above method. We can be (almost totally) certain that no two songs are going to give us the same hash output, but by the above method we are absolutely guaranteed that the same song will always give the same hash. This is a problem. This means that although an attacker can’t submit random songs/artists, he can resend previous submissions and they will be accepted. Essentially, any valid submission we send will ALWAYS be valid, and therefore always honored. This leads to what is called a “replay” attack: the attacker can resend any submission we’ve made and it will be successful.

The solution to a replay attack is an expiry (experation date), or in this case a timestamp. We make a slight modification to our previous method and include the current time:

Ex:
ARTIST: Weezer
TITLE: Freak Me Out
TIME: 1150106145 (in readable form 6/12/2006 02:55:45)
PASSWORD: ReplaceWithSecurePassword

OUTPUT: WeezerFreak Me Out1150106145ReplaceWithSecurePassword

Now we hash that output as before:
HASHOUTPUT: 269022a985c8df4dc343e007d4ae8c0340ee71e9

Because this new hash is time dependent, if we do this calculation one second later we will get a completely different result. By sending the timestamp along in the submission, the CGI can use it to check that its hash output matches and that the time is reasonably close to the current time (say within a few seconds to a few minutes depending on your time synchronization). After that time is up the captured hash does no good to the attacker, any replay he makes will be rejected as its valid time window has expired.

We now have a fully functional cryptographic method, but implementing it is now harder. The “Do Something!” plug-in does not support hashing, timestamps, etc… so we’re going to have to do that ourselves. What is does support is outputting a file with the ARTIST and TITLE at the start of each song, and it supports executing commands, so we’re going to have it output this file, then execute a program we write which will get the ARTIST and TITLE from that file, then do the required hashing and submit the information to our CGI.

We first set up the “Generate HTML Playlist” action in “Do Something!” This action asks for a template in and an output file. We first create a template containing simply %%CURRENTARTIST%%::%%CURRENTSONGTITLE%% and set the template in to that file. You can then choose any output file you want, just make sure you know where it is, you’ll need to put its location in the submission file so it knows where to get its info from. Be sure to “Add” this action when you finish setting it up.
Next we add a “Run A Command” action, containing simply the path to our submission program (submitsong.pl) posted below. Add this and hit “OK.” Set up the files below and you’re done!
The files:

submitsong.pl: - Client side perl script to submit info

use strict;
use warnings;

use Digest::SHA1 "sha1_hex";
use HTTP::Request;
use LWP::UserAgent;

my $file = 'c:\temp\songlist';

my $url = "http://www.yourblog.com/nowplaying/song.php?";

my $PSK = "ReplaceWithSecurePassword";

open(FILE, "<$file") or die "Unable to open input file!";

my $line = ;
chomp $line;

my ($artist, $song) = split(/::/, $line,2);

close FILE;

my $timestamp = time();

my $sha1sum = sha1_hex($artist . $song . $timestamp . $PSK);

&clean(\$artist);
&clean(\$song);

my $request = HTTP::Request->new(GET => $url . "a=$artist" . "&" . "s=$song" . "&" . "t=$timestamp" . "&" . "h=$sha1sum");
my $ua = LWP::UserAgent->new;
my $response = $ua->request($request);

if ($response->is_success) {
  print $response->content . "\n";
}
else {
	print $response->status_line . "\n";
}

exit();

sub clean {
	my $sr = shift;
	$$sr =~ s/#/%23/g;
	$$sr =~ s/\$/%24/g;
	$$sr =~ s/&/%26/g;
	$$sr =~ s/\+/%2B/g;
	$$sr =~ s/\,/%2C/g;
	$$sr =~ s/\//%2F/g;
	$$sr =~ s/:/%3A/g;
	$$sr =~ s/;/%3B/g;
	$$sr =~ s/=/%3D/g;
	$$sr =~ s/\?/%3F/g;
	$$sr =~ s/@/%40/g;
}

song.php: - Server side CGI to process and verify song submission

 $tolerance ) {
   print "Timestamp is outside tolerance\n";
   exit;
}

if (sha1($artist . $song . $timestamp . $PSK) != $sha1sum) {
   print "SHA1 sum did not match\n";
   exit;
}

if ( $logfp = @fopen("song.txt", "w") ) {
    fwrite($logfp, $artist . " - " . $song . "\n");
    fclose($logfp);
}

if ( $logfp = @fopen("artist.txt", "w") ) {
    fwrite($logfp, $artist);
    fclose($logfp);
}

if ( $logfp = @fopen("title.txt", "w") ) {
    fwrite($logfp, $song);
    fclose($logfp);
}

?>

If all goes well then song.php will make several files:

song.txt - Contains “ARTIST - TITLE”, useful if you want this common format.
artist.txt - Contains ARTIST
title.txt - Contains TITLE

These last two can be used to present them individually however you’d like.

Now all we need is to display them in the page and we are done. This can be done as:

SSI style:
;

Script style:
“; print file_get_contents(”title.txt”);?>

You now have your own secure “Now Playing” section!

A few notes:

• SHA1 is not truly secure anymore, but attacks on it are still hugely computationally intensive - much more work than breaking into your ‘Now Playing’ list would be worth. In the future, improvements and new attack vectors may make this a more realistic threat, but ostensibly by then you could simply use a different hash function in the files above (it would only be a line or two of code to change in each).
• DoSomething is not great. It only works with mp3s, only looks at version 1 ID3 tags, opens an annoying system console window, and is generally ill-suited to this application. If anyone knows of a better plug-in please let me know, and if I ever get really fed up with it I may just write my own.
• Should go without saying, but be sure to replace the password “ReplaceWithSecurePassword” with a secure password, and one roughly the same length (or longer).

Just thought I’d take a second to say -”I mean, SunMilk man! Wow. SunMilk… you know? Wow.”

Basically they take nonfat milk and add sunflower oil, and you end up with milk that tastes almost like whole milk but is much better for you (1% fat, unsaturated). I find that if I mix it ~3:1 with nonfat milk it still tastes better than normal 1% milk, and has: less sugar, less calories, less cholesterol, less fat (and it’s unsaturated vs. saturated), and more protein. Plus it tastes good.

The only downside is the cost, it’s kinda expensive (like $3.50 for a half gallon), which is actually the main reason I do the 3:1 thing, stretches it out.

If you have the means, I highly recommend picking some up. Find some in your area!

However, for remote access for employees, we need to assume the worst case, the worst case being Windows. Windows XP has an IPSEC implementation, I mean, in theory. In reality it is so craptacular that almost everyone uses either the SafeNet client or the Cisco client, both are quite good, both are not free. To be more specific, Cisco’s client is technically free, but only in combination with purchase of their hardware, which is significantly less free.

Enter OpenVPN, a free, open source, SSL based VPN solution for nearly any OS you can think, and of particular import to this discussion - a very good Windows client and a very good OpenBSD server. If you have any history with VPNs, then SSL may set off alarm bells for you as there are a number of crappy web-based SSL VPN solutions around. Don’t be worried, OpenVPN is NOT web based.

Here’s the basics:

• OpenVPN is an SSL VPN, again, please note that SSL != WEB BASED
• It works similarly to IPSEC, but is not compatible, as the cumbersome IKE algorithm is replaced with SSL/TLS
• Supports two-factor authentication (HIPAA compliance requirement)
• Relatively easy to install and manage
• It plays well with OpenBSD (ported at /usr/ports/net/openvpn)
• The Windows client GUI is solid and easy to use

Note: I love OpenBSD. I prefer to use it for any internet facing server unless there is a compelling reason not to, hence ability to play well with OpenBSD was a requirement for me.

Installation is a breeze, /usr/ports/net/openvpn/make install and you’re done.

Initial configuration is covered thoroughly in the very clear Official HOW-TO, but here’s the basics:

# mkdir -p /etc/openvpn/keys
# cp -r /usr/local/share/examples/openvpn/easy-rsa /etc/openvpn
# chown -R root:wheel /etc/openvpn
# chmod 700 /etc/openvpn/keys
# cd /etc/openvpn/easy-rsa
# . ./vars
# ./clean-all
# ./build-ca
# ./build-key-server server
# ./build-key client1
# ./build-key client2 etc.
# ./build-dh
# /usr/local/sbin/openvpn --genkey --secret ta.key
# cd keys
# mv ca.crt dh1024.pem server.crt server.key ta.key /etc/openvpn/keys
# chmod 644 /etc/openvpn/keys/{ca.crt,dh1024.pem,server.crt}
# chmod 600 /etc/openvpn/keys/{server.key,ta.key} 

ca.crt, ta.key, and your client.crts and client.keys should now be ready for secure distribution to your clients.

Next, we create the server configuration file /etc/server.conf:

daemon openvpn
writepid /var/openvpn/pid
status /var/openvpn/status 10
log-append /var/openvpn/openvpn.log
local YOUR_IP
port 1194
proto udp
dev tun0

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem

server 10.8.0.0 255.255.0.0
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS YOUR_DNS_SERVER"
push "dhcp-option WINS YOUR_WINS_SERVER"
push "redirect-gateway def1"
push "inactive 1800"

ifconfig-pool-persist /var/openvpn/ipp.txt
keepalive 10 120
inactive 1800
tls-auth /etc/openvpn/keys/ta.key 0
cipher BF-CBC
max-clients 8
user _openvpn
group _openvpn
persist-key
persist-tun
verb 6
mute 20
comp-lzo
tmp-dir /tmp
chroot /var/empty

replay-window 256
mssfix 1260
;fragment 1260

;Uncomment below if you are using openvpn-auth for two-factor authentication
;auth-user-pass-verify ./openvpn-auth via-file

Now we create the _openvpn user and group, the /var/openvpn directory, and the tunnel interface:

# groupadd -g 500 _openvpn
# useradd -u 500 -g 500 -c 'OpenVPN Server' -s /sbin/nologin -d /var/openvpn -m _openvpn
# echo 'link0 up' > /etc/hostname.tun0
# sh /etc/netstart tun0

We are now ready to try our OpenVPN server - launch by:

/usr/local/sbin/openvpn /etc/openvpn/server.conf

Check /var/log/daemon and /var/openvpn/openvpn.log for errors and add the following to /etc/rc.local to make OpenVPN start on boot:

if [ -x /usr/local/sbin/openvpn ]; then
    /usr/local/sbin/openvpn --config /etc/openvpn/server.conf
fi

The server should now be ready, so we just need a client, which we will cover in part two of this series.