You are here: Home » NewsFeeds » SMTP Strict Transport Security

SMTP Strict Transport Security

By Nathan Willis
April 20, 2016

It is no secret that email has been a weak point in the security of
the standard Internet protocol suite for quite some time. While
improvements to HTTP and TLS have resulted in more robust web
security, mail transfer has lagged behind. Now, a new draft RFC has
been submitted to the Internet Engineering Task Force (IETF) that may
make SMTP connections substantially more secure, closing loopholes
that have made mail transfer vulnerable to
man-in-the-middle and cryptographic-downgrade attacks.

The draft is called SMTP
Strict Transport Security
(SMTP STS), and it was first posted on
March 18. The authors work for a variety of well-known
technology companies and ISPs, including Google, Yahoo, Comcast,
Microsoft, LinkedIn, and 1&1 Internet. It sets out a standard by
which a mail server can publish an STS Policy that defines how mail
transfer agents (MTAs) can connect using TLS, how they can validate
the server’s TLS certificate, and what they should do in the case that
a TLS session cannot be correctly established. As the name implies,
SMTP STS is similar in design to HTTP Strict Transport
Security (HSTS), defined in RFC6797.

SMTP was originally defined in RFC821, long before TLS
(or SSL) were invented, and sent
all messages in the clear. The STARTTLS extension (RFC3207) added support
for TLS transport in 2002. Although reports are that STARTTLS has
proven popular with mail providers, it suffers from some severe
shortcomings.

First, the TLS session is subject to downgrade
attacks. In the SMTP session-establishment handshake, the
STARTTLS command is sent from one machine to the other, in
the clear. Upon receipt, the remote machine is intended to respond by
initiating a TLS handshake before the SMTP session continues. But an
attacker sitting in between the two machines can simply intercept and
drop the STARTTLS command (or overwrite it with garbage), in
which case the SMTP session will continue in plaintext.

The second shortcoming is that, in a STARTTLS handshake, client
machines do not attempt to verify that the TLS certificate presented
by the server actually belongs to the expected domain. Here again, an
attacker in the middle can intercept the genuine certificate and
replace it with a fraudulent one, without the client knowing the difference.

SMTP STS defines a way for a mail server to publish a public record
that TLS is available and that SMTP clients should thus use it when making
connections. This record is the STS Policy, and has seven mandatory
fields:

  • v – the SMTP STS version. Only a value of STS1
    is supported.
  • to – a boolean indicating whether the server is “TLS
    Only.” If true, then clients who encounter errors in the TLS setup
    must not deliver any mail to the server.
  • mx – a comma-separated list of domains for which the
    policy applies.
  • a – the authentication mechanism clients should use to
    verify that the policy is authentic. The supported mechanisms are
    DNSSEC and an HTTPS URI at which the client can separately request the
    policy and verify that the two copies are identical.
  • c – the validation method clients should use to verify
    the authenticity of the server’s TLS certificate. The supported
    methods are DANE TLSA (RFC7672) and verifying the PKI trust chain on the certificate
    back to a root certificate authority (that is, traditional TLS
    identity checking as specified in RFC6125).
  • e – the maximum lifetime of the policy.
  • rua – the address to which feedback and errors may be reported by the
    client.

A server can publish its STS Policy at
https://example.com/.well-known/smtp-sts or via DNS as a TXT record
under the name _smtp_sts.example.com. The draft document further
specifies that any errors reported to a server by clients should
contain details about where unexpected results were encountered: an
expired certificate, a DNSSEC failure, a certificate that does not
match the server’s domain, and so forth.

As Lucian Constantin at InfoWorld pointed
out
, one possible security loophole is that the first time a
client connects to a server, it has no cached copy of the server’s STS
Policy to compare, so a man-in-the-middle attacker could, in theory,
intercept the first request and return a forged policy instead. That
forged policy would, by necessity, include an a field
similarly doctored to direct the client to an attacker-controlled
server when authenticating the policy.

The draft’s support for DNS-based policy publishing provides the
means for some additional robustness against man-in-the-middle attacks
over what is offered by TLS identity checking. If a server’s STS Policy is
published as a TXT record in a DNSSEC-protected zone, clients can verify its authenticity. Furthermore, the c field can be used to specify that
a DANE TLSA record for the server’s TLS certificate is required for
validation. Thus, an attacker would have to compromise the DNSSEC
server in addition to intercepting the SMTP handshake.

The draft also notes that clients are not obligated to accept STS
Policies the first time they retrieve them from a server. Instead,
they are permitted to use the rua reporting mechanism to tell
the server’s administrators what they saw. That report can be sent “offline”
or during a different session, potentially allowing failures and suspicious reports to be
routed around a man-in-the-middle attack. Such a reporting feature is
not found in HSTS; nevertheless, SMTP STS is still a “trust on first
use” system.

The authors of the draft list
two other options to be considered for future inclusion in STMP
STS as well. They are certificate pinning, in which a policy could
specify specific certificates that must appear in the
certificate-validation chain, and policy distribution, in which sites’
policies could be recorded and publicly tracked.

The draft also speculates that it could be worthwhile for a policy
to specify the list of cryptographic ciphers and TLS versions that the
server accepts, and perhaps to specify that all mail received
from
the server’s domain should be expected to arrive over TLS.
The latter feature would, in theory, allow a mail server to check for an STS
Policy for incoming mail domains and, thus, reject mail that is “supposed to”
arrive over TLS but does not. The draft notes, however, that such
a policy would come with its share or potential man-in-the-middle
attacks to be guarded against, and may not offer significant gains.

STARTTLS has, no doubt, improved the security of e-mail transfer,
but it is far from complete. SMTP STS hopefully closes some of the
more egregious holes.

(Log in to post comments)


 

Original article