Determining SSL/TLS capabilities of a mail server

Especially in Germany where the so called »NSA-leaks« by Edward Snowden caught a lot of public attention encryption is becoming more and more popular. Or at least everybody seems to talk about it. And everybody seems to know someone who knows someone who might have encrypted something … well, you get the picture.

In any way the largest ESPs in Germany (Disclaimer: Although I might be associated with one of those I am not in any way an official representative, so all the opinions stated here are my very own and not those of a specific company) have decided to start »Email made in Germany« (EmiG). One piece of EmiG is the promise of encrypted mail transport. In other words. Mail servers should talk with each other using SSL/TLS.

Everybody who had a chance to check out SSL/TLS has found a wonderful world full of security challenges: Each and every SSL/TLS version has different flaws, many, many different cipher suites have been proposed and afterwards broken. I won’t go into all the details here, you could write books about this. Wikipedia is a good place to start.

So I wanted to see a tool to determine the SSL/TLS capabilities of a mail server. At first I did not find one and started to investigate how to write my own.

You can find a lot of those tools for web servers but not for mail. I can only speculate about the reasons for this. Most probably the cause might be due to the fact that to start the SSL/TLS session you usually have to initiate the SMTP session unencrypted and change to an encrypted transmission using the STARTTLS command. Openssl supports this, but the scripting gets more complicated, as you still have to close the connection afterwards. Http is simpler in that regard.

The solution

And then I found this commit to Nmap. Dated just a few days ago. This script is so perfect, you just saved my day!

So, without any further distractions, THIS is what I was searching for.

First let us determine the correct mail server to test:
$ host -t MX gmx.de
gmx.de mail is handled by 10 mx01.emig.gmx.net.
gmx.de mail is handled by 10 mx00.emig.gmx.net.
$ host mx01.emig.gmx.net
mx01.emig.gmx.net has address 213.165.67.97
mx01.emig.gmx.net has address 213.165.67.115

And then … let the show begin:

# nmap --script ssl-enum-ciphers2 -p 25 213.165.67.97
Starting Nmap 6.40 ( http://nmap.org ) at 2014-04-28 22:01 CEST
Nmap scan report for mx01.emig.gmx.net (213.165.67.97)
Host is up (0.0079s latency).
PORT STATE SERVICE
25/tcp open smtp
| ssl-enum-ciphers2:
|   SSLv3:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.1:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|     compressors:
|       NULL
|_  least strength: strong
Nmap done: 1 IP address (1 host up) scanned in 2.57 seconds

The results for GMX and also the presentation by this tool: Pure beauty! Thanks a lot for this great piece of software. :-)

And this is how to make it work if your Nmap packages do not yet contain the latest version of this script:

$ mkdir -p ~/.nmap/scripts
$ cd ~/.nmap/scripts
$ wget http://code.metager.de/source/raw/nmap/nmap/scripts/ssl-enum-ciphers.nse
$ mv ssl-enum-ciphers.nse ssl-enum-ciphers2.nse
$ wget http://nmap.org/svn/nselib/tls.lua
$ sudo mv tls.lua /usr/share/nmap/nselib/
$ nmap --script-updatedb

Please note the changed name »ssl-enum-ciphers2.nse« so it does not overwrite the distributed script.

Speichere in deinen Favoriten diesen Permalink.

2 Responses to Determining SSL/TLS capabilities of a mail server

  1. Bernd sagt:

    Die Version des Scripts zeigt übrigens auch die prefered ciphers an (und es erkennt ECDHE was bei mir die FreeBSD version nicht tat):

    http://seclists.org/nmap-dev/2014/q3/237
    ->
    https://raw.githubusercontent.com/bojanisc/nmap-scripts/master/ssl-enum-ciphers.nse

  2. Bernd sagt:

    Und nur weil ich Mist erzählt habe hier die Korrektur, exim 4.85 kann noch kein ECDHE (auser bei Suse): https://bugs.exim.org/show_bug.cgi?id=1397

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

1 × 2 =