Administrators may be worried about the current reports of the so-called
"BEAST" attacks against SSL/TLS. This mail addresses the impact on Exim
as I currently understand the issues. I will use "TLS" below to mean
SSL and/or TLS, since most environments can be forced to degrade at
least down to SSL3.0.
Short version: not directly vulnerable to this threat model, but if you
use plaintext passwords over TLS to authenticate to a remote web-server,
or your clients authenticate to you in this way, then there are more
general issues to be aware of. There are TLS compatibility vs security
trade-offs that you might want to tune in this case. See the existing
documentation for the "openssl_options" variable and the documented
suggested alternate value; the option was added in Exim 4.73. Online
documentation:
http://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html
At this point, there are no plans to release a new version of Exim
specifically to address this issue, and whether to change the default
value of "openssl_options" is still open to debate. There are a couple
of other adjustments that will be made, most notably to our GnuTLS
configuration support.
In practice, my non-cryptographic-expert summary is: don't worry too
much right now.
Longer version follows. Much Longer. I aimed for completeness. Beware
that this was written in one sitting, so something may still be absent.
BEAST
- -----
The BEAST attack relies upon a "chosen plaintext", ie the attacker
chooses what data will be encrypted and can then look at what's sent, to
try to recover data. Now, it's fairly easy for an attacker to send
email through a mail-server if it's set up as a relay, or if they have
an account. Whether or not, in theory, the attacker can control matters
with sufficient precision to recover text is doubtful, but human
ingenuity is not to be underestimated.
At the current time though, the attacks depend upon one existing
connection being held open and authentication happening repeatedly on
client-server messages, with the attacker influencing the boundaries.
In HTTPS there is often a cookie, not exposed to JavaScript, which it
can be valuable to extract; once you've figured out how to control the
data being sent over HTTPS (via injecting script somehow), the attacker
can slowly manage to recover the cookie, at which point they can
directly access the web site as the signed-in user. This relies upon
the cookie being sent with each HTTP request over the HTTPS connection,
with persistent connections.
In SMTP, the equivalent data to recover would be a session password used
in SMTP AUTH. The ideal protection is to not treat TLS as sufficient
justification to send cleartext passwords (PLAIN or LOGIN mechanisms)
within the communication channel and instead to use CRAM-MD5, GSSAPI or
some other mechanism which proves possession of a password or token,
rather than disclosing it.
Ultimately, because there will always be new breaks in cryptography, the
very cautious folks will layer their defences and not use PLAIN or LOGIN
even within TLS. In practice, this might be difficult to achieve; in
balancing costs and benefits, it might not be worth mandating this
protection in most environments. This is into the realms of risk
management and policy-making.
In SMTP, the authentication happens once, at the beginning of an SMTP
connection. While 1 or more messages may be sent over an existing
session, the credentials are not re-sent, so a new session needs to be
opened to re-sent the credentials, so the current BEAST attack does not
apply, per my current understanding.
TLS & SMTP
- ----------
So, onwards to the more general issue of the security of TLS in email
and Exim, what might be attacked, CBC and clients.
In email, there are four modes to consider:
(1) No SMTP-level encryption; the bulk of email today is sent like
this, and so for security the sender should use an end-to-end
system such as PGP or S/MIME.
(2) Encryption from a mail-client to the mail-server, for mail
submission, typically on port 587 (or 465); some degree of identity
verification is performed here and there's an assumption of
security.
(3) Opportunistic encryption MX->MX, vulnerable to Man-in-the-middle
attack because there is no defined idea of what the "identity" of a
mail-server should be; that's a separate debate, but in short it's
highly likely that if you're sending passwords in this mode, you're
crazy.
(4) Encryption MX->MX by out-of-band established policy on identity
verification.
In mode 1, there's nothing to discuss. Similarly for mode 3.
In mode 2, the attack model is something on a client computer which can
send email through an MUA but not recover the MUA's configured password.
If this is malware, then it almost certainly can get the password anyway
and the BEAST-style attack is unnecessary. If it's software which can
be abused into sending email (automating mailto: submission?) then
perhaps there's an issue. At this point, the evidence left behind is
large (saved copies of sent mail). Nonetheless, those with particularly
sensitive data might conceivably care about this vector as often the
same password used to send email is used to access stored email, eg in
an IMAP store.
In mode 4, the attack model is someone trying to recover the
server-to-server password so that they can fraudulently send email; it's
unlikely that such as password will grant access to read existing mail.
The attacker might have an easier time here, since they might be able to
send email between two boxes they control.
In neither case does a vulnerability in TLS permit an attacker to
directly compromise data other than what they're sending; the issue is
entirely about access to credentials sent over the same sessions.
In mode 4, a reasonable approach to avoid these issues is to use TLS
client certificates; Exim supports that now. With this done, there is
no data within the session other than the attacker's own, and so nothing
to worry about the disclosure of. In mode 2 (MUAs), client certificates
are possible but client support becomes much more limited.
Note that overly broad selection of Certification Authorities may turn
mode 4 unexpectedly into mode 3.
So: most mail, there's nothing to protect against the person sending the
mail in the first place; there are ways to avoid having something to
protect, or to protect that data against even a TLS break; some people
are stuck using passwords via PLAIN or LOGIN SMTP AUTH mechanisms over
TLS right now, the above analysis of this particular attack does not
reassure them, and they want to make sure that the session encryption
being used is as strong as possible. Onwards.
CBC, OpenSSL & GnuTLS
- ---------------------
Cryptographic discussion follows; warning, I am not a professional
cryptographer.
In sending data securely in blocks, there are various ways that an
encryption key can be used to protect more than a small amount of data
without generating repeated patterns. One mode, which has been shown
for some time to have problems, is to use one "Initialisation Vector"
(or IV) at the start, and then for all blocks except the first to use
the previous _encrypted_ text as the IV for this block. When the
encrypted data is sent over the wire first, this means that the IV is
"known". That's how TLS is used -- the previous data is sent before the
current data, and the encrypted data is directly exposed.
This "implicit IV" can be avoided in three ways, but unfortunately
two are not available to current implementations and the one available
solution breaks some widely deployed software.
One way is to not use Cipher-Block-Chaining (CBC) encryption. This is
controlled in Exim with the "tls_require_ciphers" options; one in the
main configuration, used for incoming connections, and also on SMTP
Transports, used for outbound connections. More on this below.
The second way: TLS 1.1 introduces explicit IVs to protect against just
these attacks. This doesn't help us.
Some releases of GnuTLS support TLS 1.1 (and TLS 1.2). OpenSSL does
not. NSS, the third main TLS provider library, does not. So most
clients in use will not. Thus this currently could only help with
server-server communication where GnuTLS is used on both sides. (I
welcome hearing of a widespread MUA which uses GnuTLS). The
gnutls_require_protocols Exim option controls this, however current
releases of Exim only support "TLS1" and "SSL3" as values of this
option and by default constrain GnuTLS to these versions. This is
regrettable. A bug has been filed and future releases of Exim should
have support for configuring GnuTLS with support for higher protocol
versions.
So Exim can currently only support up to TLS 1.0, in part because our
GnuTLS support could do with more loving care. We are a volunteer
project and contributions are welcome. (For this one particular issue,
it _looks_ simple enough to fix even without knowing GnuTLS well, so
I'll give it a go).
The third way: tinkering with the TLS 1.0 protocol, and disabling SSL3.
OpenSSL introduced an adjustment to the protocol behaviour to defend
against exactly this attack, by (ab)using the protocol, sending empty
fragments and getting the IV to be non-predictable as a result of that.
Unfortunately, the adjustment breaks some other implementations. Most
notably, it is my understanding that it breaks the OS-provided TLS
implementation of Microsoft Windows, at least through Windows XP.
So OpenSSL included the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option to
disable this protection. Because of the breakage, a long time ago Exim
set this option by default.
Exim Configuration
- ------------------
As of Exim 4.73, the setting of the OpenSSL options was exposed to the
Exim configuration file, via the "openssl_options" option. Note that
because of an infelicity in how this option is managed, the default
value is shown as blank but that means that +dont_insert_empty_fragments
is set, as described in The Exim Specification. So:
$ exim -bP openssl_options
is misleading.
If you read the documentation for "openssl_options", the example use of
this option given is to set:
openssl_options = -all
Doing this will, loosely speaking, reset the options passed to OpenSSL
to be empty and take the OpenSSL defaults. That will provide the CBC
protection. Doing this may cause TLS breakage for some of your clients.
The value of the "tls_require_ciphers" option is interpreted by either
OpenSSL or GnuTLS, depending upon which TLS provider Exim was built
with:
* OpenSSL:
http://www.openssl.org/docs/apps/ciphers.html
* GnuTLS:
http://www.gnu.org/s/gnutls/manual/html_node/Priority-Strings.html
In addition, there are a number of gnutls_* options which may assist; as
noted above, gnutls_require_protocols does not currently support values
other than "TLS1" and "SSL3" (specified in a list in the usual Exim
manner).
Because the particular ciphers available vary depending upon the release
of the TLS provider in use, the best way to tell is to ask the library
what a given string means. I am not currently aware of a command-line
tool to do this with GnuTLS.
With OpenSSL, the "openssl ciphers -v $SPEC" command can be used to see
which ciphers are enabled for a given specification. If you remove all
the CBC cipher-based ciphersuites, you're left with some ECDH*
ciphersuites, some Camellia, and about six others.
The Exim maintainers are not qualified to give cryptographic advice as
to the security properties of these suites, to which of these suites are
suitable, nor to comment on how widely deployed they are and how this
will affect the ability of your installation to find a mutually
supported ciphersuite when talking to someone else.
That butt-covering said, with the understanding that it's not expert
advice, merely a pointer, note that one well known search provider and
free mail provider tends to use "RC4-SHA" both for web traffic and
SMTP/TLS. So as long as that remains in your list of available
ciphersuites, you'll _probably_ be good. [More butt-covering:
disclosure: said company is a former employer of mine and I still own
stock; I really don't think I just pimped them, though].
If you're reading this sentence after reading _all_ of the above without
skimming, congratulations. :)
- -Phil
