cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5686
Views
5
Helpful
1
Replies

Cisco ESA configuration to allow SSL/TLS without STARTTLS

CG_UNIL
Level 1
Level 1

Dear community,

 

We're in the process of configuration our ESA setup and have a question with regards to encrypting SMTP transactions.

 

Our current SMTP setup required users to select "SSL/TLS" in their (for example) Thunderbird config: the SMTP transaction is encrypted from the get to, the TLS connection being negotiated first.

With the ESA, we have only managed to get an encrypted SMTP transaction working via STARTTLS: the transaction starts out in the clear, before the TLS connection is negotiated.

 

My question is, can we set up the ESA to require a TLS connection without using STARTTLS? This would mean not having to reconfigure all our users SMTP configurations...

Thanks for your advice!

1 Accepted Solution

Accepted Solutions

ppreenja
Cisco Employee
Cisco Employee
Hi CG_UNIL,

To my understanding, STARTTLS command is required while having the encrypted TLS communication with the ESA appliance. The STARTTLS keyword is used to tell the SMTP client that the SMTP server is currently able to negotiate the use of TLS.

To answer your query, I believe TLS encrypted connection without STARTTLS command can't be setup with ESA.

After the client gives the STARTTLS command, the server responds with one of the following reply codes:

220 Ready to start TLS
501 Syntax error (no parameters allowed)
454 TLS not available due to temporary reason

One of the most commonly used email encryption extensions is STARTTLS. It is a TLS (SSL) layer over the plaintext communication, allowing email servers to upgrade their plaintext communication to encrypted communication. STARTTLS is a valid ESMTP extension when used on the Submission port, as defined in [RFC2476].

Cisco AsyncOS for Email Security supports the STARTTLS extension to Simple Mail Transfer Protocol (SMTP) (Secure SMTP over TLS).

Also, with regards to thunderbird, I was able to find below information on the internet that might be helpful to you:

some email software incorrectly uses the term TLS when they should have used STARTTLS. Older versions of Thunderbird, in particular, used "TLS" to mean "enforce use of STARTTLS to upgrade the connection, and fail if STARTTLS is not supported" and "TLS, if available" to mean "use STARTTLS to upgrade the connection if the server advertises support for it, otherwise just use an insecure connection".

Referred internet link: https://www.fastmail.com/help/technical/ssltlsstarttls.html

Also, I would like to share with you below additional information:

In order to activate TLS for inbound sessions, connect to the web GUI, choose Mail Policies > Mail Flow Policies for the configured inbound listener, and then complete these steps:
Choose a listener for which the policies must be modified.
Click the link for the name of the policy in order to edit it.

In the Security Features section, choose one of these Encryption and Authentication options in order to set the level of TLS that is required for that listener and mail flow policy:

Off - When this option is chosen, TLS is not used.
Preferred - When this option is chosen, TLS can negotiate from the remote MTA to the ESA. However, if the remote MTA does not negotiate (prior to the reception of a 220 response), the SMTP transaction continues in the clear (not encrypted). No attempt is made in order to verify whether the certificate originates from a trusted certificate authority. If an error occurs after the 220 response is received, then the SMTP transaction does not fall back to clear text.
Required - When this option is chosen, TLS can be negotiated from the remote MTA to the ESA. No attempt is made in order to verify the certificate of the domain. If the negotiation fails, no email is sent through the connection. If the negotiation succeeds, then the mail is delivered via an encrypted session.

Click Submit.
Click the Commit Changes button. You can add an optional comment at this time if desired.
Click Commit Changes in order to save the changes.
The mail flow policy for the listener is now updated with the TLS settings that you have chosen.

Complete these steps in order to activate TLS for inbound sessions that arrive from a select set of domains:
Connect to the web GUI and choose Mail Policies > HAT Overview.
Add the sender(s) to the appropriate Sender Group.
Edit the TLS settings of the mail flow policy that is associated with the Sender Group that you modified in the previous step.
Click Submit.
Click the Commit Changes button. You can add an optional comment at this time if desired.
Click Commit Changes in order to save the changes.

The mail flow policy for the Sender Group is now updated with the TLS settings that you have chosen.

You may check the below articles that contain more information about TLS:
https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118844-technote-esa-00.html
https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118954-config-esa-00.html

RFC Article:
https://www.ietf.org/rfc/rfc3207.txt
https://www.ietf.org/rfc/rfc2476.txt

I hope the above information provides you some insight on your query rather than making you confused :)

BR,
Pratham

View solution in original post

1 Reply 1

ppreenja
Cisco Employee
Cisco Employee
Hi CG_UNIL,

To my understanding, STARTTLS command is required while having the encrypted TLS communication with the ESA appliance. The STARTTLS keyword is used to tell the SMTP client that the SMTP server is currently able to negotiate the use of TLS.

To answer your query, I believe TLS encrypted connection without STARTTLS command can't be setup with ESA.

After the client gives the STARTTLS command, the server responds with one of the following reply codes:

220 Ready to start TLS
501 Syntax error (no parameters allowed)
454 TLS not available due to temporary reason

One of the most commonly used email encryption extensions is STARTTLS. It is a TLS (SSL) layer over the plaintext communication, allowing email servers to upgrade their plaintext communication to encrypted communication. STARTTLS is a valid ESMTP extension when used on the Submission port, as defined in [RFC2476].

Cisco AsyncOS for Email Security supports the STARTTLS extension to Simple Mail Transfer Protocol (SMTP) (Secure SMTP over TLS).

Also, with regards to thunderbird, I was able to find below information on the internet that might be helpful to you:

some email software incorrectly uses the term TLS when they should have used STARTTLS. Older versions of Thunderbird, in particular, used "TLS" to mean "enforce use of STARTTLS to upgrade the connection, and fail if STARTTLS is not supported" and "TLS, if available" to mean "use STARTTLS to upgrade the connection if the server advertises support for it, otherwise just use an insecure connection".

Referred internet link: https://www.fastmail.com/help/technical/ssltlsstarttls.html

Also, I would like to share with you below additional information:

In order to activate TLS for inbound sessions, connect to the web GUI, choose Mail Policies > Mail Flow Policies for the configured inbound listener, and then complete these steps:
Choose a listener for which the policies must be modified.
Click the link for the name of the policy in order to edit it.

In the Security Features section, choose one of these Encryption and Authentication options in order to set the level of TLS that is required for that listener and mail flow policy:

Off - When this option is chosen, TLS is not used.
Preferred - When this option is chosen, TLS can negotiate from the remote MTA to the ESA. However, if the remote MTA does not negotiate (prior to the reception of a 220 response), the SMTP transaction continues in the clear (not encrypted). No attempt is made in order to verify whether the certificate originates from a trusted certificate authority. If an error occurs after the 220 response is received, then the SMTP transaction does not fall back to clear text.
Required - When this option is chosen, TLS can be negotiated from the remote MTA to the ESA. No attempt is made in order to verify the certificate of the domain. If the negotiation fails, no email is sent through the connection. If the negotiation succeeds, then the mail is delivered via an encrypted session.

Click Submit.
Click the Commit Changes button. You can add an optional comment at this time if desired.
Click Commit Changes in order to save the changes.
The mail flow policy for the listener is now updated with the TLS settings that you have chosen.

Complete these steps in order to activate TLS for inbound sessions that arrive from a select set of domains:
Connect to the web GUI and choose Mail Policies > HAT Overview.
Add the sender(s) to the appropriate Sender Group.
Edit the TLS settings of the mail flow policy that is associated with the Sender Group that you modified in the previous step.
Click Submit.
Click the Commit Changes button. You can add an optional comment at this time if desired.
Click Commit Changes in order to save the changes.

The mail flow policy for the Sender Group is now updated with the TLS settings that you have chosen.

You may check the below articles that contain more information about TLS:
https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118844-technote-esa-00.html
https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118954-config-esa-00.html

RFC Article:
https://www.ietf.org/rfc/rfc3207.txt
https://www.ietf.org/rfc/rfc2476.txt

I hope the above information provides you some insight on your query rather than making you confused :)

BR,
Pratham