Re: Interop problem with SMTP STARTTLS and Cisco PIX firewall

Dan Wing <[email protected]> Fri, 26 Mar 1999 16:39:21 -0800 (PST)
Newsgroups gmane.ietf.apps-tls
Message-ID <[email protected]>
First, I am _not_ affiliated with the PIX group, but I have had my hand in
getting this PIX misbehavior fixed a little over a year ago (in
conjunction with broken PIX behavior related to DSN support reported on
the Notifications mailing list by Matti Aarnio).  The Cisco defect number
for the broken behavior is CSCdk22371.

As of PIX software version 4.2(2), the problem described below by Chris
(and by CSCdk22371) has been fixed.  Version 4.2(2) has been shipping
since approximately September 1998.

In PIX 4.2(2) the EHLO verb is treated as an invalid verb and causes a 550
response -- thus the SMTP client won't see the list of SMTP service
extensions supported by the SMTP server and won't try to use SMTP verbs
outside of the set of required-to-implement verbs in RFC821.

This issue was also recently mentioned by Joel Snyder, [email protected],
in his Messaging Focus newsletter published by NetworkWorld Fusion.  I
believe he, too, was using an old version of the PIX software.

If this problem exists in a version of the PIX software after 4.2(2),
please let me know directly and I will escalate the issue.

Sorry for the inconvenience to readers of this IETF list for this
message.

-Dan Wing

>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