Cisco ESA incoming TLS

[ikanolux2012]

Hi

We are using Cisco ESA with AsyncOS 9.7.1-066 and I have to force TLS inbound/outbound for many email domains.

TLS configuration is fine and working, but currently I have to:

- Add a new line in destination controls with the email domain to have TLS forced for outgoing messages

- Add a new IP or MTA hostname or domain to have TLS forced for incoming messages (very annoying, I have to find the MTA's name or IP for each single email domain!)

So the question is Hhw can I use ONE address list to force TLS incoming and outgoing ? The feature in mail flow policies "TLS is Mandatory for Address List" does not seem to work at all, or is not reflected correctly in the logs (domains do not appear in TLS Required statistics)

Please advice

Thanks

[Libin Varghese]

Hi,

Currently address lists cannot be used to control outgoing TLS connections, it would require you to add individual destination controls entries.

Similarly, we add the sending IP/hostname for incoming TLS connections.

The feature "TLS is Mandatory for Address List" should work as long as the connections match the appropriate sender group the mail flow policy is associated with, if the reports do not reflect this correctly I would recommend reviewing the message tracking for such emails to confirm if TLS was used.

Thanks

Libin Varghese 

[ikanolux2012]

Hi,

Thanks for your replies, that's unfortunately what I thought. Definitely, this needs to be improved..

Anyway I would like to use 'TLS is Mandatory for Address List' , it will easier for me than identify the MTAs for all domains

In my case, I have TLS as Preferred by default. So in the mail tracking, when I use the 'TLS is Mandatory for Address List' I will only see that TLS has been used for this domain, but it does not mean that this was forced.

How can I check and provide evidences that the TLS connection was forced and that the message will not be sent in clear text if TLS negotiation fails?

Thanks

David

[Libin Varghese]

Hi David,

We will only be able to determine that the communication was done via TLS. With TLS preferred, if the appliance for every connections with another appliance sees the STARTTLS within the banner then we will try to negotiation via TLS however, if we cannot establish the secure socket (be it cipher negotiation , protocol incompatibility, or even no STARTTLS within the banner, etc.)then we will revert back to plain text.

There is no real way that I know of that can be used from the appliance's perspective to determine if this was via opportunistic vs required unless the connection fails.

The reason you will know this is because the message will not be delivered and you will receive a TLS was required but failed... notification.

Thanks
Libin Varghese

[ikanolux2012]

OK thank you.

So the only way for me to confirm that this is working as expected would be to define a test domain/gateway without TLS capability, put this domain in the 'TLS is Mandatory for Address List' and see if I receive notifications that the TLS negotiation failed.

And then I could tell my client that TLS is forced even if it as Preferred only in the reports.

Sounds a bit weird complicated, let's see if I am able to sell this..

And I really hope this will be sorted out in future releases as mentioned by dmccabej

Thanks for your help

[dmccabej]

Hello,

You're very welcome! :)

That is one way you could test ...Another way would be to enter in a bogus domain into the mandatory address list, and then perform a manual telnet test using that as your mail-from. It should look something like this if everything is setup properly (Note that it will not let you proceed without first issuing STARTTLS) :

+++

telnet x.x.x.x 25

Trying x.x.x.x...
Connected to x.x.x.x.
Escape character is '^]'.
220 test.example.local ESMTP
helo localhost
250 test.example.local
mail from: <test@gmail.com>
530 #5.7.0 This sender must issue a STARTTLS command first

+++

[dmccabej · Accepted solution]

Hello,

There is currently no singular way to manage TLS connections. You will need to continue adding additional TLS domains either via the Sender Group / Mail Flow Policies (for Incoming) or Destination Controls (for Outgoing/Delivery). If you wish, like you stated, you can also manage incoming TLS using the 'Mail-From / Envelope Sender' domain via the 'TLS is Mandatory for Address List'.

Unfortunately, when using the 'TLS is Mandatory for Address List' option, this will not properly populate the 'TLS Connections' reporting page the way you're hoping. You would instead need to look up the TLS Connections report by using the sending server hostname or IP address.

I've ran into this previously with another customer and created an enhancement to change this behavior : ENH: Include Envelope Sender Domain in 'TLS Connections Details' Report

Thanks!

-Dennis M.

[integritysolutions]

I have tested this solution.

I note that outgoing TLS domain report for a domain reports the number of TLS Req. Success and the last TLS status.  The incoming TLS domain report is only TLS Pref success. 

I have configured the address list with the domain in question and used the pull down TLS is Mandatory for address list. Also TLS is preferred by default.