[vps-mail] Setting up a secure SquirrelMail system on VPS1 in more than 5 minutes

[Marjolein Katsma <tfyj8lv02@xxxxxxxxxxxxxx>]

All,

The 'more than 5 minutes' in the subject (while true) is a little private 
joke - sorry, I couldn't resist...

[For later reference, this report is also available from the web - but (so 
far) as plain text only; download from http://iamback.com/doc/SM_story.txt 
for more comfortable reading.]


Setting up a secure SquirrelMail system on VPS1 in more than 5 minutes
----------------------------------------------------------------------

A report of my adventures... hoping that my experiences will provide some 
useful ideas for others. My path wasn't as straight as described below, and 
involved a number of dead ends, wrong turns, and stones to trip over. May 
your path be smooth and straight.

For some subjects I made separate notes, which I put on my website; I'm 
simply referring to them here to make this email a litlle "shorter". All 
just plain text, I'm afraid, no time to make it into pretty web pages. Just 
download the files if they don't read well in your browser - sorry.

Here goes with the report:


(1) The use case.

I'm going to make a long trip, all across Asia. I'd like to keep a 
"travelblog" on a website for those who stay at home: a blogging system 
where I can easily add my travel notes from Internet cafes I may find along 
the way.

Since working from an Internet cafe is inherently insecure (port sniffers, 
key loggers and other spyware may be installed) I didn't want to set up my 
blogging system so it could be directly used from a web interface: better 
not expose a maintenance interface and password for the travelblog website 
in a "public place", so I devised a system where I send an email to a 
special mailbox, and a background PHP script pulls out the mails and adds 
the content to the database. Designing and setting up the database was easy 
enough. The script to read (and validate) mails and fill the database 
(archiving everything) needs some tidying up but is essentially ready.

Then I started looking at emailing from Internet cafes. Discussions in 
various locations... My original idea was to set up a string of (free) 
webmail accounts, discarding each after use, so as not to "leave anything 
behind" on the computer used. That idea essentially fell flat: FastMail 
(FM) doesn't even allow multiple free accounts; TMicha does, but like FM 
will discard an account that hasn't been used for 45 days - and I'll be 
gone for 65. A combination of the two might work but would be complicated. 
Other solutions came up: a USB stick with a pre-installed email application 
(will work only where a USB connection is present and allowed to be used - 
not guaranteed); using an anonymous email web form that doesn't require 
login (I'm keeping that as a backup). After long discussions the brilliant 
idea (thanks SikaSpam!): install SquirrelMail on your own VPS system; there 
is a nice virtual keyboard plugin that can protect your login password from 
keyloggers. While continuing other discussions, I decided to explore that.

Meanwhile the public end of the travelblog system (displaying the data from 
the database in various ways) is nearly ready as well, but needs a little 
refinement; and I have some wishes for extra features if I still have time 
left before I leave.


(2) Installing SquirrelMail

"It takes only 5 minutes". Well, not for me (hence the "5 minutes" in the 
subject :)). SM is a PHP application; while some will automatically assume 
that means it needs to be installed in the webserver's the document root, 
my assumption is the opposite: only a user interface needs to be visible to 
a browser, everything else needs to be found by PHP, not the webserver, so 
it can be installed *away* from the webserver, which is more secure. That's 
how I design my own PHP apps, and my experience with others as well.

The INSTALL file in the SM archive states: "Untar (...) SquirrelMail in a 
directory that is readable for your webserver." Well, OK. So it put it in 
the server root - not the document root. Oops. It actually needs to be 
installed in the *document* root.

SM also has requirements; apart from PHP (no problem) and Perl (not 
strictly needed, but no problem anyway) it needs an IMAP server. I've only 
ever used IMAP against my will, and know next to nothing about it  in fact, 
I didn't know it was provided with a VPS account. OK, so IMAP is provided. 
I don't know *which* IMAP server is installed though, nor do I know how to 
find out...

The same INSTALL file also has some instructions about data directories to 
be created and their ownership. That confused me, since I found the 
commands given did not work. Ignore those instructions: you can actually 
configure these directories to be invisible from the browser or even the 
webserver: a complete path can be defined using SM's configuration. As long 
as SM can find it, it's secure enough when you just put those directories 
outside of the webserver's view. See Configuring SquirrelMail below.

Simple install: create a directory (which I'll call [SUB] in the rest of 
this story) and untar SM into that. Move the data directory somewhere else 
if you wish. Configure.


(3) Configuring SquirrelMail

SM provides a Perl script (to be run from the command line) for 
configuration; it's a nice menu system but the menu choices *themselves* 
don't tell you very much about what they are for: the explanation appears 
only when you choose a menu option. I found this very confusing at first. 
An alternative is to copy config_default.php to config.php and directly 
edit that: it is well-commented and thus provides a better overview of 
configuration options. It also provides a way to directly specify the 
location of the data directory and the directory to be used for storing 
attachments to be sent. (Using the Perl script will also create this file.) 
After a while though much-used configuration options become easy to do from 
the Perl config.pl script, reducing the chance of typos and syntax errors. 
I find I use both now. :)

I created a new user (as instructed, with both FTP and mail, though I don't 
know why FTP is needed for IMAP!). Then, after what I "judged" was minimal 
configuration, I proceeded to test SM with my main account, as well as with 
the newly-created user. No problems with the latter, but with the main 
account I found that using the "Folders" menu from the web interface 
invariably leads to a running out of memory error. Worse, after that 
happens, SM is completely inoperational until Apache is restarted... I 
almost gave up at this point: I can't telnet into my server from an 
insecure Internet cafe!

Searching a bit, I found such errors in fact are known, and can have 
different causes, but there is no single solution or workaround. This page 
lists some memory problems similar to what I encountered:
	http://www.squirrelmail.org/wiki/en_US/LowMemoryProblem
I suspect (after a lot of poking and digging) that the problem has 
something to do with the fact that the 'special' mail folders SENT, DRAFTS 
and TRASH for the main account are in a different location from those for 
other users. A possible workaround (suggested on that page) may be to set 
up SM for a particular IMAP server of which it "knows" a few. Can't do that 
since I don't know which IMAP server is running on VPS accounts, let alone 
whether it's one of the ones SM knows about.

In the end, I decided to ignore this (still unsolved!) problem since it 
didn't occur with my newly-created user. All I need is to *send* email and 
that's best done with a special user account anyway.

I've put together some configuration hints in a separate note:

	==> http://iamback.com/doc/SM_config_hints.txt


(4) Setting up SSL

Looking at my phpinfo(), I found that not only OpenSSL is present and 
active; and Apache has the Apache_SSL module loaded as well. Seems I'm all set.

So off I go (RTFM idjit that I am) and read up on setting up SSL on Apache. 
I learn that I can actually sign my own certificate (useful: for using 
webmail from an Internet cafe all I need is encryption, after all); I learn 
that to use SSL you need IP -based virtual hosts (the IP address needs to 
be resolved first, or something) and this also means you can use only a 
single certificate for a single IP address; I learn that there is actually 
a way around that, by telling the server to listen not only to port 443 
(the default SSL HTTP port) but others as well, and defining each virtual 
host that needs its own certificate with one of those ports. And I learned 
that Apache is more usually combined with mod_ssl which isn't the same as 
apache_ssl and actually uses some different directives in httpd.conf.

All useful knowledge - but, it seems, not for VPS. Whatever I tried in 
httpd.conf, I either got internal server errors (500) indicating the SSL 
directives were not understood, or 'no connect' from the browser, seemingly 
indicating port 443 wasn't listened to, regardless what I put in 
httpd.conf. A mail to my (reseller) hoster's support explained it (more or 
less): you don't need to make *any* change in httpd.conf at all - all you 
need is to request that SSL is activated. Which turns out to cost me $55. 
YMMV, but it seems SSL does need to be "set up" on a VPS system, regardless 
whether Apache has apache_ssl alreday loaded.

Oh, well. It works now. So much for RTFM. :)

The details of how to create your own "self-signed" certificate, and how to 
set it up on a VPS(1) system, can be read here:

	==> http://iamback.com/doc/SSL_certificate.txt

Note that VPS is doing things differently than you'd deduce from all the 
information found on the web about using SSL with Apache. I suspect this 
has to do with the fact you're not (actually) running your own server, but 
a virtual one. There are both pros and cons with this. Major con is that 
you *cannot* use the "different ports" trick to use different certificates; 
if you run several domains and use anything but a wildcard certificate 
($$$!) any domain that doesn't match the domain the certificate is *for* 
will result in a "domain mismatch" in the browser. Major pro is that it's 
very easy to set up a new certificate (no changes needed in httpd.conf): 
just put the files with the correct (VPS-specific) names in the correct 
(VPS-specific) directory, restart Apache (restart_apache), and you're set.

For encryption-only, for my own use, this is certainly good enough.


(5) Setting up Squirrel Mail to use the secure server.

The next step is to make sure Squirrel Mail (at least) uses the secure 
server. One potential problem with that: the certificate uses 128-bit 
encryption. In most Western countries certainly no problem (not any more) 
but I'm not sure that will be the case in all Asian countries I'm going to 
visit. So what I need is a way to *preferably* use Squirrelmail with SSL, 
but provide a way around that as well.

Since we've already concluded that I cannot really define to use *only* on 
SSL on a particular subdomain with httpd.conf, enforcing it that way is not 
feasible anyway. I'll try a more gentle approach by only "suggesting" using 
SSL where possible.

And if I do encounter a situation where I cannot use SSL and would also 
want to avoid "exposing" my SquirrelMail password, there are some 
"anonymous" webmail forms that allow sending an email without any login 
necessary. Not for general email purposes, but good enough to be able to 
send a mail to my travelblog.

Configuration (httpd.conf) details, as well as some anonymous webmail 
addresses, here:

	==> http://iamback.com/doc/SM_secure_subdomain.txt


(6) Securing SquirrelMail

Finally, SquirrelMail itself can be made more secure, not just with respect 
to using SSL, but also to defeat keyloggers, and other potential pitfalls. 
I've put together a package of SM plugins that make it more secure to use 
on the road, as well as a few that come in handy for my particular usage 
for my travelblog system.

An annotated list of the plugins I installed (as well as a few I 
UNinstalled after testing!) can be found here:

	==> http://iamback.com/doc/SM_security_plugins.txt



-----------------------------------------------
Marjolein Katsma, 2004-04-23

--
Marjolein Katsma

======================================================================
This is <vps-mail@xxxxxxxxxxxx>       <http://www.perlcode.org/lists/>
Before posting a question, please search the archives (see above URL).