Re: Interop problem with SMTP STARTTLS and Cisco PIX firewall

In your email below you state that the primary problems are that the Cisco
PIX is not RFC compliant and that Exchange 5.5 advertises STARTTLS even if
no certificate is configured.  I do not have PIX so I will not comment
regarding the problems it might have. I would like to comment on your
opinion that a server that has a problem with its certificate should not
advertise STARTTLS.

If the SMTP Server is not configured with a certificate, or it has expired,
or it is using an invalid certificate the TLS Client will STILL fail during
the TLS negotiation. If the SMTP Server did not advertise STARTTLS, due to
an invalid or absence of a certificate, the TLS Client might return the
message to the sender stating that the server does not support TLS even
though the server was configured to do so. If the SMTP Server, with no
certificate, advertised STARTTLS the negotiation would fail but the TLS
Client would be aware that the server supports TLS and attempt to send the
message at a later time in hopes that the certificate issue will be
resolved. The issue is not with the product itself but with our opinions on
what is expected by the SMTP server when there is an issue with the
certificate and if it should advertise STARTTLS or not.

Scott
Standard Disclaimer:
<my views and opinions are mine and not directly the views or statements of
the corporation I work for>



-----Original Message-----
From: Chris Newman <[email protected]>
To: Application Use of TLS IETF List <[email protected]>;
[email protected] <[email protected]>
Date: Wednesday, March 24, 1999 7:58 PM
Subject: Interop problem with SMTP STARTTLS and Cisco PIX firewall




A major interoperability problem has shown up which results from an
egregious firewall implementation interacting with an insufficiently
flexible STARTTLS implementation.

The clear standards violator here is the Cisco PIX firewall -- there is a
case where it advertises STARTTLS, but totally violates RFC 2487.  The
problem is it passes the EHLO response from the backend host unaltered,
but the firewall responds with a success response to any unknown command
(a clear violation of RFC 821).

Exchange 5.5 service pack 2 always advertises STARTTLS (although it
generates a failure response to the STARTTLS command if no cert is
configured).  This is technically standards compliant, but wasteful in the
common case and dangerously inflexable in this case.

Thus a Cisco PIX firewall front-ending for Exchange 5.5 SP2 will fail to
interoperate with any standards compliant TLS-enabled SMTP client.

ATTENTION SMTP STARTTLS IMPLEMENTERS:

Make sure there is at least a mode where STARTTLS is not advertised.  A
quality implementation will only advertise STARTTLS if a valid server cert
is correctly configured.

ATTENTION USERS OF CISCO PIX + EXCHANGE 5.5:

Don't install Exchange SP 2 until your broken firewall is replaced with a
functional one.

My personal opinion: If you must have an application-level firewall, I
recommend getting one from a vendor specializing in that application; buy
a filtering proxy for HTTP, a filtering proxy for LDAP, and an SMTP server
with firewall mode for email, etc.  Generic firewall products have
repeatedly caused interoperability and security problems due to inadequate
understanding of application protocols.


Feel free to forward this message to appropriate people who can get things
fixed.

- Chris