Subject: IBM response to support issue about TLS and SMTP
For those of you who’ve been following, I’ve had many back and forths with IBM about the failure of inbound secure SMTP connections after implementing TLS 1.0. Their latest reply was to say they removed all SSLv2 support when the TLS hotfix was rolled out as per http://www-10.lotus.com/ldd/dominowiki.nsf/dx/SSLv2 http://www-10.lotus.com/ldd/dominowiki.nsf/dx/SSLv2
If you look at the RFC’s cited, however, you’ll note that SSLv2 CLIENT-HELLO message formats CAN be accepted by servers that only support TLS. It is perfectly legal. The way they are handled is constrained, and the server isn’t allowed to actually negotiate SSLv2 traffic, but the connection attempt and hello are NOT supposed to be rejected out of hand.
Here is my full email response to IBM support. We’ll see what happens.
My interpretation of this response is that it says my Domino server is working as designed given the Fix Pack, and Interim Fix it is running.
I was already aware of the referenced information with regards to SSLv2 Handshake Messages. If this is the rationale being used to explain why my server can’t accept various secured incoming SMTP connections (so that it, ironically, must run SMTP in the clear to function), I believe the RFC cited is possibly being misinterpreted. From RFC 6167 https://tools.ietf.org/html/rfc6176in the section “3. Changes to TLS” it says:
- Changes to TLS
Because of the deficiencies noted in the previous section:
o TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-
HELLO message format. Clients MUST NOT send any ClientHello
message that specifies a protocol version less than
{ 0x03, 0x00 }. As previously stated by the definitions of all
previous versions of TLS, the client SHOULD specify the highest
protocol version it supports.
o TLS servers MAY continue to accept ClientHello messages in the
version 2 CLIENT-HELLO format as specified in RFC 5246 [TLS1.2],
Appendix E.2. Note that this does not contradict the prohibition
against actually negotiating the use of SSL 2.0.
o TLS servers MUST NOT reply with an SSL 2.0 SERVER-HELLO with a
protocol version that is less than { 0x03, 0x00 } and instead MUST
abort the connection, i.e., when the highest protocol version
offered by the client is { 0x02, 0x00 }, the TLS connection will
be refused.
Yes, clients are not supposed to send SSLv2 compatible CLIENT-HELLO message format. But, as stated in the second bullet point the server can continue to accept these SSLv2 CLIENT-HELLO message formats so long as it doesn’t negotiate a SSLv2 connection. The server should respond with an allowed protocol version AND it should only abort the connection when the highest protocol version offered by the client is insufficient.
So SSLv2 CLIENT-HELLOs are not supposed to be simply rejected out of hand, but the response type is restricted and the connection refused only if the client doesn’t offer a high enough protocol version.
It appears to me from the IBM statement that possible TLS 1.0 connections are being refused simply because the client sent a SSLv2 CLIENT-HELLO, something that is allowed by the RFC.
I’d also like to reference RFC 5246 Appendix E https://tools.ietf.org/html/rfc6176#appendix-E.2which says, among other things:
Note: some server implementations are known to implement version
negotiation incorrectly. For example, there are buggy TLS 1.0
servers that simply close the connection when the client offers a
version newer than TLS 1.0. Also, it is known that some servers will
refuse the connection if any TLS extensions are included in
ClientHello. Interoperability with such buggy servers is a complex
topic beyond the scope of this document, and may require multiple
connection attempts by the client.
AND
However, even TLS servers that do not support SSL 2.0 MAY accept
version 2.0 CLIENT-HELLO messages.
So, what am I dealing with here? Since currently IBM Domino 9.0.1, even when fully patched, only supports up to TLS 1.0, is it one of these “buggy TLS 1.0 servers” as described in RFC 5246?
As you know, I currently have little choice but to run SMTP without any encryption at all because if the current TLS 1.0 encryption is turned on I can’t accept secure SMTP server connections from a variety of clients of ours – as well as that little $23-billion company named Twitter.
Is the conclusion here that Twitter only sends mail with SSLv2? Or is it that such senders support higher encryption but that my Domino server cuts the connection when it sees an SSLv2 CLIENT-HELLO, which actually is allowed by RFC?
