• Welcome to The Network People Support Forums. Please login or sign up.

TLS & SSL - improving security for the mail-toaster according to QualysGuard

Started by antoniop, May 29, 2007, 11:07:51 PM

Previous topic - Next topic

antoniop

Hi,

I have access to the Qualysguard security scanning tools and have been very proactive the last couple weeks using the tools to resolve some security issues on a FreeBSD box running the toaster to get a system up to Payment Card Industry standards.

After nights of research and trail n error I have finally locked down the mail-toaster according to Qualys (security company whom are commonly used by corporates, eg: New York Board of Trade, Payment Card Industry giants, Microsoft & many others).

Given I spent some time looking for this information and testing various configs on my test server I thought Matt might want to incorporate these in the toaster or you might also want to improve security on your server.

Here are some of the changes I have done to the files that the toaster doesn't watch so far as I know but doing this will improve security.  Be sure to test your config on a development / test server PRIOR to impliementing the changes on your own production server (the worst that can happen is after re-starting the daemons your users will get errors when trying to connect).

Lock down Q-Mail - create these files with the contents below

[root@test ~]# cat /var/qmail/control/tlsclientciphers
ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

[root@test ~]# cat /var/qmail/control/tlsclientciphers2
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:RC2-CBC-MD5:DHE-DSS-RC4-SHA:RC4-SHA:RC4-MD5:RC4-MD5:RC4-64-MD5:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-RC4-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-RC4-MD5
[root@mail /usr/local/etc/courier-imap]# cat /var/qmail/control/tlsserverciphers
ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

[root@test ~]# cat /var/qmail/control/tlsserverciphers2
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:RC2-CBC-MD5:DHE-DSS-RC4-SHA:RC4-SHA:RC4-MD5:RC4-MD5:RC4-64-MD5:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-RC4-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-RC4-MD5
[root@mail /usr/local/etc/courier-imap]#


Lock down Courier-Imap

[root@test ~]# cat /usr/local/etc/courier-imap/pop3d-ssl | grep CIPHER
TLS_CIPHER_LIST="ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXP:!NULL:!DES"

[root@test ~]# cat /usr/local/etc/courier-imap/imapd-ssl | grep CIPHER
TLS_CIPHER_LIST="ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXP:!NULL:!DES"


Lock down Apache   ( /usr/local/etc/apache/httpd.conf )

        SSLProtocol -ALL +SSLv3 +TLSv1
        SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:!SSLv2


---

AP   ;)

matt

These changes are very good, and I'd approve of them in most cases. However, requiring stronger SSL security in Apache has the potential to break a number of SSL clients. I'd like to have a documented list of those clients that break, as well as instructions on how to enable the weaker authentication for clients that need it.

Then I'd be quite happy to see a patch to Mail Toaster that sets this up automatically. I've added it to my TODO.

antoniop

I found a business case template regarding migrating to 128 Bit encryption instead of using the lower bit encryption schemes.

TLS v1 is an extension to SSL v3 which in turn was an extension of the SSL v2 encryption suite.

To display the ciphers on a *nix system use the command #/$ openssl cipherlist

Below is an informative webpage on ciphers:
http://www.openssl.org/docs/apps/ciphers.html#Additional_Export_1024_and_other

Netscape Navigator v2 supported TLSv1 way back in August 1996 over 10 years ago :)

Surprisingly Internet Explorer 3 and later support TLS v1.  Netscape Navigator 4 and later support TLS v1.  All versions of Opera support TLS v1 (I believe).  I know all versions of FireFox support TLS v1 as does all versions of Mac OS's Safari support TLS v1.  The vast majority of libraries and user agents support TLS v1 or SSL v3.

SSL v2 and any 40 bit encryption is not recommended for use on the internet.  I take this further to only permit 128 bit and stronger (disabling 56 bit) which 99% of browser's used on the Net support.

From personal experience I have not had any complaints from any (both Windows and Linux) users to date and I have used PC's with IE v3.0+, Netscape v4.0+ (on a Win95 PC), Mozilla v1+, Firefox v1+, Lynx v2+, Opera v7+, Safari v7 over the last year and did not experience any connectivity issues to the Apaches servers I administer with these encryption parameters.

Browser Statistics:
http://www.w3schools.com/browsers/browsers_stats.asp


2007      IE7  IE6  IE5  Fx  Moz  O
September 20.8% 34.9% 1.5% 35.4% 1.2% 1.6% 1.5%
August 20.5% 35.7% 1.5% 34.9% 1.3% 1.5% 1.7%
July 20.1% 36.9% 1.5% 34.5% 1.4% 1.5% 1.9%
June 19.7% 37.3% 1.5% 34.0% 1.4% 1.5% 1.8%
May 19.2% 38.1% 1.6% 33.7% 1.3% 1.5% 1.7%
April 19.1% 38.4% 1.7% 32.9% 1.3% 1.5% 1.6%
March 18.0% 38.7% 2.0% 31.8% 1.3% 1.6% 1.6%
February 16.4% 39.8% 2.5% 31.2% 1.4% 1.7% 1.5%
January 13.3% 42.3% 3.0% 31.0% 1.5% 1.7% 1.5%


Business Case (from ZDNet's website):

General Introduction
As companies rely more heavily on the Internet for transmitting sensitive data, protecting that information becomes increasingly important. In fact, industries with a strong regulatory presence, such as health care and financial services, demand the toughest security measures possible.

One of the standard bearers of secure Web-based messaging is the Secure Sockets Layer (SSL), which is a widely used protocol that encrypts data as it is transmitted between your end user and the corporate Web server.

In short, the SSL security protocol encrypts data, verifies server authentication, verifies message integrity, and provides an optional client authentication for a TCP/IP connection. All major browsers, including Mozilla and Internet Explorer, support SSL. On the Web server-side, administrators simply install a digital certificate and "flip the on-switch" for SSL functionality. Web users can tell that they have visited a secure site by the "https://" in their browser address bar versus the unsecured "http:// "connection."

SSL boast strong benefits that should help your site visitors and customers feel comfortable with their Web transaction.

•   Quickly identifies visitors. For tech savvy users that have personal digital certificates, the server recognizes them and facilitates the login.
•   Protects the integrity of the transaction. Warns users if there's a potential problem of unsecured element in the transaction.
•   Protects visitors' confidentiality.  Prevents unauthorized access to sensitive data, such as Social Security or credit card numbers during transmission.
•   Users have to take little additional action.  Depending on their browser and operating system, most users don't have to take any additional action to leverage SSL-backed communications with your Web server.

40-bit vs. 128-bit

Older browsers supported 40-bit encryptions, while some newer ones supported 56-bit.  With Netscape 4.0, support shifted to 128-bit encryption, making the security measures substantially more effective. The 128-bit indicates the length of the session key, and, as you might have guessed, the longer the session key the harder the encryption is to break. The encryption algorithm takes the message and a key and manipulates the data before it is transmitted. A decryption algorithm and key converts the message to a human-readable form. While a 40-bit encryption could be deciphered fairly easily, a 128-bit would take an extraordinary amount of computing power to de-code.

Impact and benefits from migrating 128-bit encryption:

Secure Web-based communications and transactions
Business Benefit: Leverage the Web as a means to transmit and receive sensitive data with your customers
•   Protects customer information, such as medical records, credit card information, and Social Security number
•   Authenticates user/site identity
•   Helps prevent fraudulent transactions
•   Prevents data tampering during transmission
•   Meets regulatory standards and compliance guidelines