8. Security

This chapter should discuss some security aspects of your SquirrelMail installation.

Used terms:

TLS - Transport Layer Security

Transport Layer Security is cryptographic protocol which provides secure communications on the Internet. It is the successor to SSL v.3.0 protocol. The term "SSL" often applies to both TLS and SSL protocols. The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0). TLS v.1.0 protocol is refined in RFC 2246.

SSL - Secure Sockets Layer

Secure Sockets Layer is cryptographic protocol which provides secure communications on the Internet. Protocol runs on layers beneath application protocols such as HTTP, SMTP and NNTP and above the TCP transport protocol, which forms part of the TCP/IP protocol suite. SSL v.3.0 protocol is refined by Netscape Corporation. http://wp.netscape.com/eng/ssl3/

STARTTLS

STARTTLS is special extension to standard plain text communication protocols. STARTTLS extensions offer a way to upgrade to TLS from a plaintext connection, rather than use a separate port for encrypted communications. SMTP STARTTLS extension is refined in RFC 2487. IMAP STARTTLS extension is refined in RFC 2595. The Internet Engineering Task Force recommends use of STARTTLS instead of a separate port for encrypted communications.

8.1 Main SquirrelMail attack vectors

SquirrelMail is webmail interface written in PHP. Webmail interface could be attacked through specifically crafted emails, interface programming mistakes and user information hijacking. It can be used to send unsolicited email messages from a hijacked or abused email account.

In order to prevent crafted email exploits SquirrelMail uses special htmlfilter library to filter dangerous html code and prevents loading of remote web data. Htmlfilter code needs constant updates because crackers discover various design problems in web browser and can try exploiting them in webmail interfaces. If you want to be safe, make sure that you are running latest secured web browser version and SquirrelMail scripts are not outdated.

Interface programming mistakes usually can exploited only by authenticated user. They can lead to hijacking of other users' data or executing scripts with web server user privileges. SquirrelMail developers are trying to prevent such exploits. If you find some way to security of SquirrelMail scripts, inform about it SquirrelMail developers.

User's login information can be hijacked in communications between IMAP and web servers, session and data storage facilities on web server, communications between web server and web browser and with tracking tools on user's machine.

In order to track emails sent through webmail interface SquirrelMail automatically adds own Received: headers with sender's IP address, detected information about used proxies and used username. This information can be hidden by encrypting it. Webmail administrators can completely remove username and address information by editing class/deliver/Deliver.class.php file. You should not remove user information from email headers unless you make sure that you can retrieve information with other tools or user forging is not possible in your SquirrelMail setup. SquirrelMail developers don't support interface that removes user information and should not be blamed when such interface is abused.

8.2 Securing the connection to your IMAP server

SquirrelMail provides the option to connect to a remote IMAP server over an encrypted connection: Transport Layer Security (TLS and STARTTLS), or to connect with only encrypted user credentials (CRAM-MD5 and DIGEST-MD5).

Note: There is no point in using TLS if your IMAP server is localhost. You need root to sniff the loopback interface, and if you don't trust root, or an attacker already has root, the game is over. You've got a lot more to worry about beyond having the loopback interface sniffed.

Requirements

CRAM/DIGEST-MD5

• Digest-MD5 authentication needs PHP XML extension.
• If you have the mhash extension to PHP, it will automatically be used, which may help performance on heavily loaded servers.
• IMAP server support for these methods.

TLS

• PHP 4.3.0 or higher (Check Release Notes for PHP 4.3.x information)
• The server you wish to use TLS on must have a dedicated port listening for TLS connections. (ie. port 993 for IMAP, 465 for SMTP).
• If you use PHP 4.3.x, OpenSSL support must be compiled staticly. See PHP bug #29934.

STARTTLS

• Available since SquirrelMail 1.5.1.
• PHP 5.1.0rc1 or higher (stream_socket_enable_crypto() function)
• Server with STARTTLS extension support

Configuration

All configuration is done using conf.pl, under main menu option #2. conf.pl can now attempt to detect which mechanisms your servers support. You must have set the host and port before attempting to detect, or you may get inaccurate results, or a long wait while the connection times out.

Known Issues

DIGEST-MD5 has three different methods of operation. (qop options "auth", "auth-int" and "auth-conf"). This implementation currently supports "auth" only. Work is being done to add the other two modes.

8.3 HTTP vs HTTPS

SquirrelMail interface consists of dynamically generated HTML pages. These pages are transfered to user's browser using HTTP protocol. HTTP protocol does not have any built-in encryption functions. Information is transfered in plain text. HTTP traffic contains login passwords and any information viewed or entered in browser.

If you want to secure web traffic, you should use HTTP protocol with SSL encryption. Check your web server documentation about SSL support.

If you have SquirrelMail install in unsecured HTTP and secured HTTPS servers, SquirrelMail secure_login and show_ssl_link plugins can be used to warn users about insecure connections and/or provide automatic redirection to a secured server.

In the Apache web server, redirection can be implemented with Redirect directives and the mod_rewrite module. For example:

# Redirect /squirrelmail link to secured server
Redirect permanent /squirrelmail https://secured.example.org/squirrelmail

# simple mod_rewrite example
<Location /squirrelmail>
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</Location>

HTTP over SSL communications prevent "man in the middle" attacks between user's machine and webmail server. SSL encryption makes it difficult to sniff web traffic. Use of signed SSL certificates might prevent hostname spoofing attacks.

8.4 Session data security

Information about OTP and other information stored in session.

8.5 Data directory security

About data directory security.

8.6 Keyloggers

vkeyboard plugin.