Improving STARTTLS authentication in the Sendmail MTA

After having worked on what I think is the right way to setup X.509 certificates for use in SMTP STARTTLS transactions , I am continuing my work on how we can improve the way the Sendmail MTA handles STARTTLS authentication. This article explains how the Sendmail MTA handles this and what the limitations are. We will  finally make some suggestions on how we could improve our implementation, and of course your comments to this article are not only welcome, but they will be particularly useful.
Opportunistic TLS or mandatory TLS?
In most cases, mail platforms use opportunistic TLS, sometimes even without the mail administrator knowing this. For example a default setup of the Sendmail Opensource MTA is likely to use opportunistic TLS as a client (when sending mail), and you don’t need to do anything for this. Opportunistic TLS brings encryption of your communication up to the next hop. It does not provide any form of authentication: you may still be sending your mail to the wrong server, just that the communication will be encrypted!
On the other hand, mandatory TLS is when you need to ensure you’re speaking to the right server, and this works both ways: inbound and outbound. Policy configuration will ensure that you speak to the right server, i.e. when the MTA has decided to send a message to, say, the host relay.wolfhugel.eu, you want to make sure that this host shows a X.509 certificate which is adequate and which you trust.
Mandatory TLS makes sense from the moment you need to be sure who you’re talking to, or who is connecting to your mail server. This policy enforcement can be partial: most real life situations use standard Internet mail routing (MX records), eventually opportunistic TLS, and mandatory TLS to/from just a few remote sites.
Current implementation in the Sendmail MTA
Thanks to the use of rulesets to handle TLS enforcement, site administrators have a vast choice of what they can do with respect to validating a TLS connection. The only limitations are:

• The information coming from the certificate and provided by the MTA to the ruleset engine
• The ability of the rulesets to do things (and this is quite a large set of things).

Most users will even not use these rules and prefer the existing methods which are part of the MTA package, mostly by ways of using entries in the “access_db” file.
The TLS_Srv and TLS_Clt tags are used respectivement when the Sendmail MTA sends (TLS_Srv) or receives (TLS_Clt) mail and it allows defining one or several actions. These filters apply when selecting the actual name of the server we’re talking to (or the domain of it), this means whatever appears in the MX. For fining control based on the recipient’s address there is a TLS_Rcpt keyword which is applied per recipient, regardless of the server we’re talking to. There is no such rule, sender address based, for incoming mail.
A few examples:

TLS_Srv:wolfhugel.eu      VERIFY:128+CN
TLS_Rcpt:wolfhugel.eu     VERIFY:128+CN++CI:/C=GB/.../O=MyCA

The first line means that when talking to any server called “wolfhugel.eu” or within this domain (mail.wolfhugel.eu, relay.wolfhugel.eu, …), we want the TLS connection to be shown with a certificate whose Certification Authority is trusted by our system, with at least a 128 bit encryption algorithm and in addition we will check the CN of the presented certificate to ensure it corresponds to the one we’re actually talking to. So if our MX record is “relay.wolfhugel.eu” and we send a mail to this server, we want the certificate to be trusted and to have “relay.wolfhugel.eu” in its CN field.
The second line applies to any mail going to someone within the wolfhugel.eu domain, regardless of the mail server we’re actually sending the mail to. We do all verifications described above and in addition we want that the Certificate Issuer (this can be an intermediate certification authority) has a Subject line of “/C=GB/…/O=MyCA”, i.e. we indicate clearly which CA we trust for this domain.
Full documentation is provided in the Opensource Sendmail MTA package in the cf/README file.
Another use of TLS authentication is to permit, or not, relaying, i.e. the goal is to say that if you show a given certificate you may use this SMTP server to send mail anywhere (typically you would use the MSA submission port, 587/tcp). I do use this when I’m roaming: regardless of the IP address I show, my home MTA with allow me to send messages to anyone if I can prove, by ways of the adequate certificate, it’s me.
The verification is again done in two steps by using the “access_db” map: first we check if the certificate issuer is authorized, and then eventually we check the certificate itself, like in following example:

CertIssuer:/C=GB/.../O=MyCA        RELAY
CertIssuer:/C=GB/.../O=AnotherCA   SUBJECT
CertSubject:/C=GB/.../CN=CWOLF     RELAY

The first line means that we will trust anyone showing a certificate issued by the certification authority “/C=GB/…/O=MyCA” (which again can be an intermediate authority). The second line says that if a certificate is presented signed by “/C=GB/…/O=AnotherCA” then we’ll check the Subject of the certificate itself, and we will authorize any listed entry with the adequate “CertSubject” entry.
Anything else? Just write your own rules, and this article won’t go into this. You can write any rules using the “sendmail.cf” language and the values provided for certificates. Following macros are available (taken from the documentation):

• ${cert_issuer} holds the DN of the CA (the cert issuer).
• ${cert_subject} holds the DN of the cert (called the cert subject).
• ${cn_issuer} holds the CN of the CA (the cert issuer).
• ${cn_subject} holds the CN of the cert (called the cert subject).
• ${tls_version} the TLS/SSL version used for the connection, e.g., TLSv1, TLSv1/SSLv3, SSLv3, SSLv2.
• ${cipher} the cipher used for the connection, e.g., EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC-SHA, DES-CBC-MD5, DES-CBC3-SHA.
• ${cipher_bits} the keylength (in bits) of the symmetric encryption algorithm used for the connection.
• ${verify} holds the result of the verification of the presented cert.
  Possible values are:

  OK	verification succeeded.
  NO	no cert presented.
  NOT	no cert requested.
  FAIL	cert presented but could not be verified, e.g., the cert of the signing CA is missing.
  NONE	STARTTLS has not been performed.
  TEMP	temporary error occurred.
  PROTOCOL	protocol error occurred (SMTP level).
  SOFTWARE	STARTTLS handshake failed.

• ${server_name} the name of the server of the current outgoing SMTP connection.
• ${server_addr} the address of the server of the current outgoing SMTP connection.

Limitations in the current implementation
The provided primitives already allow a lot of flexibility, but I feel there are a few limitations which are worth being discussed and which could lead to improvements.
An important limitation I came across when setting up TLS recently is that the Sendmail MTA does not handle the X509v3 “Subject Alternative Name” extension which allows specifying more than one host name in a certificate: my certificate could have a CN=tea.wolfhugel.eu and the extension would list this and all other names I do use the certificate for (“DNS:mail.wolfhugel.eu”, “DNS:relay.wolfhugel.eu”, …). Also one could argue that when doing name matching in certificate validation the current rules do not support the use of wildcard certificates (i.e. “CN=*.wolfhugel.eu”, “DNS:*.wolfhugel.eu”).
It seems like the Sendmail MTA it is somewhat difficult to define rules with intermediary certification authorities when trusting or accepting certificates.
Some proposals to improve the current handling in Sendmail MTA

Here are a few proposals to hopefully improve the way the Sendmail MTA uses certificates in STARTTLS connections and how to decide about giving, or not, authorization to connect or to relay. Comments on this are more than welcome, as users’ feedback is essential for improving the product!
Implement X509v3 Subject Alternative Names
This is a significant change and it requires source code changes in the MTA, but I feel it is probably the most needed extension: the Sendmail MTA would extract the DNS Subject Alternative Names from the presented certificates and expose them to the configuration file in macros $&{altname_subject} and $&{altname_issuer}. These macros can later be used in any rule where they are available for deciding to give, or not, access to the SMTP service.
Create new rules to use the Subject Alternative Names
The two new macros defined with the new names extracted from the certificates can be used to extend the current way the MTA gives authorization. Here is a proposal to extend the current rules.
For the TLS_Srv/TLS_Rcpt entries in the access DB we would add a new attribute called “CA” (as Cert Altnames) who behaves identically to the “CN” attribute but would mean match the CN or any alternative name, and the example given in the beginning of this article would become:

TLS_Srv:wolfhugel.eu      VERIFY:128+CA
TLS_Rcpt:wolfhugel.eu     VERIFY:128+CA++CI:/C=GB/.../O=MyCA

This would mean the the host we’re connecting to must be found either in the CN of the certificate or in any DNS value of the alternative names for the verification to be successful.
Similarly when authorizing a remote party to relay, with the CertIssuer/CertSubject tags, we would add a new value to the access database: “ALTNAMES:xxx” would create an indirection telling to search for a key called “SubjAltName:xxx:value” in the access map which in turn would authorize or prevent access as shown in this example:

CertIssuer:/C=GB/.../O=MyCA         ALTNAMES:SMI
SubjAltName:SMI:cwolf@sendmail.com  RELAY

The meaning of the above would be that whenever a connection is made with a certificate issues by “/C=GB/…/O=MyCA” we will be checking the alternative names and our key for the lookup is “SMI”. If any of the alternative names is “cwolf@sendmail.com” relaying will be authorized, and yes here we do allow Email addresses as alternative names.
Implement the wildcard certificates
Another point which has not been implemented in supporting wildcard certificates, i.e. a certificate whose CN or alternative name contains a star, like “*.wolfhugel.eu” meaning this certificate covers any host within the “wolfhugel.eu” domain name. This implementation would be transparent, i.e. no changes in the access map would be required.

What is next generation firewall - NGFW

A class of firewalls designed to filter network and Internet traffic based upon the applications or traffic types using specific ports. The application-specific granular security policies provided by Next Generation Firewalls help them detect application-specific attacks, giving them the potential to catch more malicious activity than more traditional firewalls.

Next Generation Firewalls (NGFWs) blend the features of a standard firewall with quality of service (QoS) functionalities in order to provide smarter and deeper inspection. In many ways a Next Generation Firewall combines the capabilities of first-generation network firewalls and network intrusion prevention systems (IPS), while also offering additional features such as SSL and SSH inspection, reputation-based malware filtering and Active Directory integration support.

Manufacturers of enterprise-grade and commercial-grade NGFWs include Barracuda Networks (Barracuda NG Firewall series), Juniper Networks (AppSecure Suite), Palo Alto Networks and WatchGuard

Key Sourcefire NGFW Capabilities

Stateful firewall inspection	NGIPS threat prevention
Switching, routing & NAT	Automated impact assessment & policy tuning
Application control	Network behavior analysis
FireSIGHT® network and user intelligence	File type determination
IT policy compliance whitelists	URL filtering (optional)
User and User Group control	Advanced Malware Protection (optional)

What is VMware vCenter Multi-Hypervisor Manager 1.0

VMware vCenter Multi-Hypervisor Manager is a component that enables support for heterogeneous hypervisors in VMware vCenter Server. It provides the following benefits to your virtual environment:

• An integrated platform for managing VMware and third-party hypervisors from a single interface.
• A hypervisor choice for the different business units in your organization to accommodate their specific needs.
• No single hypervisor vendor lock-in.

When you add a third-party host to vCenter Server, all virtual machines that exist on the host are discovered automatically, and are added to the third-party hosts inventory.

Key Capabilities

vCenter Multi-Hypervisor Manager 1.0 introduces the following set of basic management capabilities over third-party hosts:

• Third-party host management including add, remove, connect, disconnect and view the host configuration.
• Ability to provision virtual machines on third-party hosts.
• Ability to edit virtual machine settings.
• Integrated vCenter Server authorization mechanism across ESX and third-party hosts inventories for privileges, roles, and users.
• Automatic discovery of pre-existing third-party virtual machines
• Ability to perform power operations with hosts and virtual machines.
• Ability to connect and disconnect DVD, CD-ROM, and floppy drives and images to install operating systems.

MySQL Backup Script under Linux

#!/bin/bash

# The path the backups will be dumped to
DUMP_DIR="/home/backups/mysql/"

# SQL user who can access the db
SQL_USER="SQL_USERNAME"

# SQL password for above user
SQL_PASS="SQL_PASSWORD"

# SQL host
SQL_HOST="localhost"

# SQL database
SQL_DB="DATABASE_NAME"

# Back up folder name (mmddyyyy)
BACKUP_DIR="`date +%m%d%Y`"

# SQL dump file name
DUMP_FILE="`date +%m_%d_%Y_%H_%M_%S`_example.com"

# SL container name
CONTAINER="mysql_backups"

# Create backup dir if doesn't exist
if [ ! -d $DUMP_DIR$BACKUP_DIR ]; then
        mkdir -p $DUMP_DIR$BACKUP_DIR
fi

# Dump the database to /tmp/...
mysqldump -u $SQL_USER -p$SQL_PASS --host=$SQL_HOST $SQL_DB > /tmp/$DUMP_FILE.sql

tar -zcvpf $DUMP_DIR$BACKUP_DIR/$DUMP_FILE.sql.gz /tmp/$DUMP_FILE.sql

# No reason to keep the dump file
rm -rf /tmp/$DUMP_FILE.sql

# Make sure the archive exists
if [ -f $DUMP_DIR$BACKUP_DIR/$DUMP_FILE.sql.gz ]; then
        /root/slbackup.py -s $DUMP_DIR$BACKUP_DIR/ -o "$CONTAINER"

        # Remove the backup stored locally
        rm -rf $DUMP_DIR$BACKUP_DIR

        # Success
        exit 0
else
        echo "$DUMP_DIR$BACKUP_DIR/$DUMP_FILE.sq.gz does not exist."
        exit 1
fi