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

["John Oligario" <joligario@xxxxxxxxxxxxxxx>]

Sounds like Marjolein needs a new boy friend!

-----Original Message-----
From: owner-vps-mail@xxxxxxxxxxxx [mailto:owner-vps-mail@xxxxxxxxxxxx] On
Behalf Of Marjolein Katsma
Sent: Friday, April 23, 2004 2:20 PM
To: vps-mail@xxxxxxxxxxxx
Subject: [vps-mail] Setting up a secure SquirrelMail system on VPS1 in more
than 5 minutes

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).

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