The mail server clusterX.XX.messagelabs.com still maintains enabled weak (TLS 1.1, TLS 1.0, SSL 3.0) TLS Protocols

Products

• Email Security.cloud

Issue/Introduction

This knowledge base explains known weaknesses in TLS protocols and ciphers, details how cipher negotiation works during opportunistic TLS, and shows how enforced TLS influences encryption standards. It highlights the control customers and sending servers have over TLS use, addresses concerns about weak ciphers, and outlines how Email Security Cloud promotes secure encryption negotiation while balancing security with third-party compatibility. 

Environment

Email Security.Cloud 

Resolution

1. The mail server clusterX.XX.messagelabs.com still maintains enabled weak TLS Protocols (TLS 1.1, TLS 1.0, SSL 3.0) and possesses activated weak TLS ciphers.

Offered Protocols and Ciphers:

• A variety of protocols and ciphers are available. The strongest combinations are offered first.
• The sending mail server can negotiate stronger protocols and ciphers if capable, or opt for plain text if it lacks support for TLS.
• Some senders, unable to support TLS 1.2, may choose TLS 1.0 over plain text for encryption.

Opportunistic TLS for Mail Forwarding:

• During the forwarding of received mail over opportunistic TLS, the negotiation aims for the strongest encryption supported by the receiving server (typically TLS 1.2, but could be TLS 1.0).
• If the receiving server lacks TLS support, the mail is delivered in plain text due to the opportunistic nature of encryption.

Boundary Encryption Service (Enforced TLS):

• In cases where a customer configures a specific communication path for enforced TLS (Boundary Encryption service), plain text delivery is disallowed.
• Forwarding messages also requires a higher encryption standard, with no fallback to plain text allowed.
• If a message cannot meet the minimum TLS version configured by the customer, it will not be delivered.

Customer and Sending Server Control Over TLS 1.0 Usage:

• Both the customer and the sending server collectively exert control over whether TLS 1.0 or TLS 1.2 is employed.
• Enforced TLS configurations empower the customer and sending server with complete control over TLS 1.0 and TLS 1.2 usage in communication paths.

 

2. Is it possible to disable the weak ciphers?

Diverse Cipher Options in Email Security.cloud:

• Email Security.cloud provides a variety of ciphers, with the strongest ones prioritized at the top of the list.

Cipher Suite Selection by Sending Servers:

• The decision on the cipher suite used is made by the sending mail server, whether it belongs to the customer or is a third-party server.
• Preference is typically given to the strongest cipher available.

Lack of Control Over Sending Servers:

• Email Security.cloud has no control over sending servers, whether owned by customers or third parties.
• The platform intentionally allows sending servers the flexibility to choose the cipher suite, maximizing the chances of negotiating encryption.

Encouraging Encryption Negotiation:

• The deliberate strategy is to provide sending servers with ample opportunities to negotiate some level of encryption over SMTP with the Email Security.cloud service.
• Systems with up-to-date capabilities are likely to negotiate with strong ciphers.

SMTP Availability in Clear-Text and Encrypted Forms:

• SMTP is accessible in both clear-text and encrypted forms within the Email Security.cloud environment.
• In cases where a third party cannot negotiate encryption with the service, they automatically revert to sending messages without any encryption, unless the customer has configured Enforced TLS.

Balancing Security and Third-Party Compatibility:

• Rather than disabling weaker ciphers outright, Email Security.cloud opts to offer them as an option.
• The rationale is to maintain some level of encryption even with weaker ciphers, rather than risking a situation where some third parties might shift from weak encryption to no encryption if weaker ciphers are removed.

 

 

Additional information:

The new enhanced TLS Options and Controls allow customers to specify a specific encryption level for non-enforced connections. With Enforced TLS, customers can choose whether encryption is required on a domain-by-domain basis, and if so, what the minimum TLS version should be. Additionally, a "default" can now be specified, which applies to all other (non-enforced) connections. This means that customers can prevent plain text and weak ciphers for all connections, including opportunistic.

It's important to note that testing this can be tricky, especially when it comes to the Singapore CSA. Since this is shared infrastructure, we don't know who the sender or recipient for the connection will be ahead of time. As a result, we always offer weak ciphers, even if strong ones are configured. To prove that only strong ciphers are allowed, it's necessary to get to the next part of the SMTP conversation (MAIL FROM / RCPT TO). Once we have that information, we will reject the command if the encryption negotiated doesn't meet the level configured by the relevant customers. Testing what ciphers we allow without getting to this part of the conversation is invalid.