Sackville-West Clan Wiki/ tech/ Ikiwiki and SSL

Using SSL with Ikiwiki

As should be obvious, this wiki is run using ikiwiki. Now I know that wikis are supposed to be editable by anybody, but for our purposes, that's really not good. This is a family oriented wiki which is accessed by children and is also a repository for information we want to preserve, but still have public access available. Some kind of authentication is required to control access. And it needs to be simple to implement and control.

more...

Default Authentication (signinedit)

Ikiwiki comes with a default password authentication system that is pretty simple but effective. Users must login to make use of any editing features. Couple that with

account_creation_password => "super-secret-passphrase-that-you'll-never-guess"

in the ikiwiki.setup file and you've got a pretty simple, but reasonable way to control access to the wiki. You control who has access by requiring an administrator to enter the account creation password at the time an account is created. I haven't yet investigated what happens when you enter an incorrect accountcreationpassword, but I'm sure fail2ban can be configured to pick it up and shutdown access to someone trying to crack it. This is by no means a Fort Knox of security, but it seems pretty reasonable and like the bars on the window, will keep the honest folk honest. But there is still one major vulnerability that I wanted to get rid of: all this stuff happens in plaintext. This is not an issue for most of our access to this wiki as it happens from our LAN, and is properly firewalled and audited. However, we're getting ready for the trip of doom and want access from anywhere. The world abounds with packet sniffers and compromised network connections and sending cleartext authentications out into that world is not a pleasant thought.

mod_ssl

I spent a couple days trying to figure out how to get some kind of encryption involved without unnecessary complication or overhead. The first, simplest solution is to put the whole thing under mod_ssl with

<VirtualHost *:443>
    ServerName wiki.swclan.homelinux.org
    DocumentRoot /var/www/ikiwiki/
    SSLEngine on
...
</Virtualhost>

but these seems extreme to me. This would put the entire website under SSL and that's really not necessary. Plus, since I'm using self-signed certificates, could cause warnings to pop-up just for someone to view the site. Plus SSL slows down access...

mod_auth_digest

The next solution I considered was to turn over authentication to mod_auth_digest. My understanding is that this provides authentication without the clear text password. I'm sure its not all that secure (its and MD5 checksum of the username, password, requested URL and a couple other bits) but it at least removes the "clear text passwords floating through the air" problem. Its also dead simple to setup

<VirtualHost *:80>
   ...
   <Directory /cgi-bin/>
       AuthType Digest
       AuthName "restricted wiki"
       AuthUserFile /path/to/password/digest
       Require valid-user
    </Directory>
</VirtualHost>

along with using the htdigest program to setup passwords for your users. Finally, you have to setup

cgiurl => "http://wiki.swclan.homelinux.org/cgi-bin/ikiwiki.cgi",

and

wrappers -> [
....
    wrapper => "/var/www/ikiwiki/cgi-bin/ikiwiki.cgi",

in your ikiwiki.setup file so the wiki can point to all the right places.

This worked pretty well in that it allowed authentication with reasonable security from publicly accessible networks. But there are some problems:

  1. With the ikiwiki authentication (signinedit) still turned on, people have to actually autheticate twice -- not a great solution, escpecially since the kids want access too.
  2. With the ikiwiki authentication (signinedit) turned off, the commits become anonymous. Instead of AndrewSackville-West showed as the committer, you just get an IP address. This isn't a big deal other than I don't like it...

Rewriting

The next solution was an utter failure: Rewriting. Apache lets you do all kinds of fancy stuff with rewriting and redirecting requests. That's all cool, but in the final analysis was unworkable for me. Probably there is some awesome rewriting-fu that could make it work, but all I got was errors when trying to commit edits.

Final solution

The final solution to this problem was overwhelmingly simple. Isn't that always the way it is? I'm embarrassed at how simple it is, and how ridiculously obvious in hind-sight. The solution is to change ikiwiki.setup:

cgiurl => "https://wiki.swclan.homelinux.org/cgi-bin/ikiwiki.cgi",

note the https in the url. Also setup apache with:

<VirtualHost *:443>
    ServerName wiki.swclan.homelinux.org
    DocumentRoot /var/www/ikiwiki/
    SSLEngine on
    SSLCertificateFile 
    ....
</VirtualHost>

and it just magically works. The ikiwiki.setup change makes all links in the wiki that point to the cgi script point to an SSL version of the website. Dead simple. I'm sure I could tweak it so that only cgi requests are accessible through the SSL version of the site, but I'll leave that for another day. As it is, someone could access an SSL version of the site by manually entering an https:// URL, which puts us in the same situation as the original solution, but that's their problem. I suppose I could

RewriteEngine on
RewriteRule !^cgi-bin/(.*)$ http://wiki.swclan.homelinux.org/$1 [R,L]

or

<VirtualHost *:443>
    ServerName wiki.swclan.homelinux.org/cgi-bin  #not sure this works...
...
</VirtualHost>

but that's for another day.

Please let me know what you think.

hide