ESA - TLS Preferred Verify seems not working - Need Clarification and Help

[admincoco]

Hi,

I recently set up our ESA to communicate with TLS but It seems some partners are no longer able to send e-mails to me.

I have read this documentation

https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118955-Control-TLS-Negotiation-ESA-00.html

I have selected TLS Preferred (Verify)

And what I see for TLS Preferred (Verify) is 

TLS is negotiated from the ESA to the MTA(s) for the domain. The appliance attempts to verify the domain’s certificate.Three outcomes are possible:

TLS is negotiated and the certificate is verified. The mail is delivered via an encrypted session.
TLS is negotiated, but the certificate is not verified. The mail is delivered via an encrypted session.
No TLS connection is made and, subsequently the certificate is not verified. The email message is delivered in plain text.

That's weird and i do not understand. Here, (Verify) option on TLS Prefered means : If the certificate is wrong, the mail is delivered anyway ? So, what's the aim of Verify option ?

Can you clarify this point to me ? If certificate not verified, does the mail comes or not ?

This is an example of an email not received and visible in the tracking log:

Incoming connection (ICID 1041372) has sender_group: UNKNOWNLIST, sender_ip: 80.247.*.* and sbrs: 3.5
Protocol SMTP interface local-lan (IP 192.168.200.1) on incoming connection (ICID 1041372) from sender IP 80.247.*.*. Reverse DNS host smtp.*.co.uk verified yes.
(ICID 1041372) ACCEPT sender group UNKNOWNLIST match sbrs[-1.0:10.0] SBRS 3.5 sender IP 80.247.*.* country United Kingdom
(ICID 1041372) TLS failed. Reason: (336105606, 'error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed').
(ICID 1041372) Unknown command: \\x16\\x03\\x03\\x00F\\x10\\x00\\x00BA\\x04\\x9c\\xb8\\xe3\\xd2\\x19\\xbc\\xb9\\xaf\\xae\\xd6\\xa74\\xb8\\\\c;\\xa9\\xd7\\x10\\x8bZ\\xb6.
(ICID 1041372) Unknown command: \\xca\\xf9\\x16\\x03\\x03\\x01\\x08\\x0f\\x00\\x01\\x04\\x06\\x01\\x01\\x00.i\\xc6\\xd3.
(ICID 1041372) Unknown command: \\xe7\\xf7\\xcf.
(ICID 1041372) Unknown command: :\\xc6\\xd6tN\\xa4\\x8c\\xa3\\xca\\xa6'{\\xc2\\xf7{x\\x9a_\\x96\\x02\\xa5/\\xc3\\x16z\\x95\\xb0.
Message 898393 Sender Domain: maskeddomain.com
Start message 898393 on incoming connection (ICID 1041372).
Message 898393 enqueued on incoming connection (ICID 1041372) from prvs=6914fcd0d=john.doe@maskeddomain.com.
Message 898393 direction: incoming
Message 898393 aborted: Receiving aborted by sender
Incoming connection (ICID 1041372) lost.

Why is the mail aborted ? It should arrive anyway according to TLS Preferred (Verify), right ?

Another example is on mails that does not appear in the tracking log and seem to be dropped .

ESA error logs says 

Thu Mar 11 14:48:07 2021 Info: New SMTP ICID 1182493 interface local-lan (192.168.200.1) address 192.168.250.97 reverse dns host mail-srv-ldn01.local verified yes
Thu Mar 11 14:48:07 2021 Info: ICID 1182493 RELAY SG RELAYLIST match 192.168.250.97 SBRS rfc1918 country not applicable
Thu Mar 11 14:48:07 2021 Info: ICID 1182493 TLS failed: (336105606, 'error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed')
Thu Mar 11 14:48:07 2021 Info: ICID 1182493 lost
Thu Mar 11 14:48:07 2021 Info: ICID 1182493 close

Which I guess means, an email has been lost because TLS failed.

I don't understand something or Cisco says something wrong in the documentation about TLS PReferred (Verify).

What I want is :

Make TLS with partners who make TLS.

If the TLS negociation fails (because of certificate wrong), it doesn't matter, just accept the e-mail.

I don't want to lose e-mails.

Should I select the Verify option or not ?

Thank you for your help

[marc.luescherFRE]

Let me try to help you explain what the current options are :

I assume based on your mailogs that your focus is on outbound.

By default an ESA is setup with a policy of TLS prefered for all outgoing connection (mail Policies / Destination Controls /default) 

The best practice is to create domain specific connections for every destination domain , where something stringer then the default is required:

We run a SIEM script every week to update the 750 most used domains and create destination documents where we asked for enforced TLS.

We have about 20 domains where the domain owner asked us to enable TLS enforced with certificate validation.

We have about 5 domain where the domain owner asked us to enable TLS enforce and DANE enforcement.

Long story short, I would not enable TLS enforced with certificate validation unless asked for. We have seen many cases where the negociation is just failing, either because the intermidum certificates are not avilable or expired, the used key algorithms are not or no longer supported or secure etc. Usually companies which require this validation know what they are doing, this is not the case for most others.

I hope that helps

[admincoco]

Hi Marc,

Thank you for your answer.

What you say is clear and I agree with you.  TLS enforced with certificate validation should be enabled only with specific partners if asked for.

The issue occured for Inbound emails with TLS Preferred and certificate validation.

Cisco ESA guide says that : For TLS Preferred (Verify) 

TLS is negotiated, but the certificate is not verified. The mail is delivered via an encrypted session.

My understanding is :

Even if the certificate verification fails, the mail shoud be delivered with TLS.

Am I right ? Or am I misunderstanding ?

[Libin Varghese · Accepted solution]

With TLS Preferred Verify, the MGA takes the certificate that it receives and tries to chain back to a root CA for verification.

As long as the recipient domain presents a functional certificate and TLS negotiation is successful, the MGA should send mail in encrypted fashion regardless of whether the verification succeeds or fails.

The outcome of that verification is logged (success or failure).

If the recipient domain does not present a certificate and TLS negotiation is successful with TLS Preferred Verify is enabled, email should be sent in the clear.

Like Marc mentioned, it would be recommended to use TLS Preferred instead of TLS Preferred Verify or utilize packet captures and work with TAC to identify why TLS negotiation is failing for these emails.

Regards,

Libin

[admincoco]

That's clear. Thank you.

I have disabled certificate check for TLS Preferred.

Another question (last one )

Now, I can see in the logs such errors 

Wed Mar 17 08:44:40 2021 Info: ICID 1184217 TLS failed: (336027900, 'error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol')
Wed Mar 17 08:44:40 2021 Info: ICID 1184217 Unknown command: `Js'\x1e\xa8&\xe9o|\x9b@\x01\xcfmv|-\xb9\xc6
Wed Mar 17 08:44:40 2021 Info: ICID 1184217 Unknown command: \xc0
Wed Mar 17 08:44:40 2021 Info: ICID 1184217 Unknown command: \x00\x13\x00\x05\x00\x04\x01\x00\x00\x19\x00
Wed Mar 17 08:44:40 2021 Info: ICID 1184217 lost
Wed Mar 17 08:44:40 2021 Info: ICID 1184217 close

I have read on forums that means TLS 1.0 is disabled.

How can I see that error deals with TLS 1.0 ?   

What would be the error if it was another TLS issue ?

[Libin Varghese]

The unknown protocol would normally suggest both ends could not come to terms on a common protocol to use.

On the ESA, enabled TLS versions can be checked under System Administration -> SSL Configuration.

Enabling and using TLSv1 would come down to your business and security requirement and what domains you interact with use.

For troubleshooting the TLS negotiation in detail, you'll need to use packet captures at the time of these emails being sent.

Regards,

Libin

[admincoco]

Thank you Marc and Libin for your clarifications..