SSL has long been the foundation of secure Internet communications. At the tail end of 2014, several vulnerability postings battered and bruised the SSL protocol and a POODLE was a primary wagger of that tail. Luckily SSL's stronger sibling, TLS, had already matured and was ready to step in where SSL was failing - but not without some lingering issues.
Secure Sockets Layer (SSL) and Transport Layer Security (TLS), are protocols that encrypt the traffic between two sites; they create a secure tunnel for data to flow through, shielded by the encryption. TLS 1.0 is essentially an updated version of SSL 3.0, but the two protocols are separated by lack of direct compatibility. The TLS RFC states (RFC2246, Section E):
"The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0)."
The POODLE vulnerability breaks SSL 3.0 security and opens the tunnel so that the transmitting data is no longer shielded. The primary response taken to address this vulnerability is to disallow SSL 3.0 altogether, and utilize only the TLS protocol. However, the backwards compatibility mechanism states that a client that wishes to potentially communicate with an SSL capable server must handshake with a Hello negotiation at the lowest desired potential version, and then proceed to the most secure compatible version. The end result is that most communications were already using TLS, though the conversation started with an SSL negotiation.
The lingering issues that have been seen variously across the Internet are related to the negotiation allowance between SSL 3.0 and TLS 1.0. In particular, Symantec Messaging Gateway support are seeing this occur with email transfers from a Mail Transfer Agent (MTA) that has not disabled SSL to one that has. In this situation, the receiving MTA will not allow the weaker handshake to take place and the communication will fail. The answer to this situation is to universally move away from SSL, as it is no longer secure.
This situation has been documented in the following KB article:
Symantec Messaging Gateway may fail to connect to mail servers utilizing strict TLS version 1 transport encryption.
http://www.symantec.com/docs/TECH215003
The Symantec Messaging Gateway has included a configuration option to disallow SSL in the recently release 10.5.3 version. For anyone who uses the Symantec Messaging Gateway, it is highly recommended to update the appliance to the latest version and disable the SSL protocols. More information is referenced in this KB article:
You wish to disable support for SSLv3 in the Symantec Messaging Gateway (SMG) from version 10.5.3
http://www.symantec.com/docs/TECH225622
Because much of the MTA population on the Internet has not historically utilized an encrypted transport*, many MTAs will use a connection method called opportunistic encryption. Opportunistic encryption is a configuration that will attempt to establish TLS encryption for all connections, but will fail over to a non-encrypted connection if TLS negotiation is not available or, in some configurations, if TLS negotiation fails. It is a one size fits all approach that eases the transition period to the adoption of strict TLS.
Currently, the Symantec Messaging Gateway has a design that affects its ability to take advantage of opportunistic encryption when there is a problem with TLS negotiation. With this design, failure to establish a TLS encrypted connection will not fail over to an open connection, resulting in messages being queued and continuing to attempt to establish a TLS connection until the message times out and a Non-Delivery Report (NDR) is generated. Symantec Messaging Gateway is designed in this way to preserve the secure transaction if it is offered, even if the transaction may fail.
This design only affects opportunistic encryption attempts when the receiving MTA offers a STARTTLS option on connection, meaning it is expecting to handle encrypted communications. It does not affect connections to MTAs that do not support TLS.
Unfortunately, with the changes to the SSL/TLS landscape due to the POODLE vulnerability and the compatibility issues between the two protocols, TLS negotiation failures are being seen much more often and the design to not fail over to an open connection when a TLS connection is expected is taking some administrators by surprise.
Possible changes to this design are currently under consideration and the issue is documented in the following KB:
Messages queued after enabling opportunistic TLS
http://www.symantec.com/docs/TECH223776
If this issue impacts you, be sure to subscribe to the KB to keep updated.
* As the realities of potential Internet attacks are becoming discussed in the media, it is quickly becoming a general stance that all communication channels should be encrypted. However, moving away from legacy configurations is often a long and tedious journey.
References:
TLS protodcol: http://en.wikipedia.org/wiki/Transport_Layer_Security
POODLE vulnerability: http://en.wikipedia.org/wiki/POODLE