Format of SSL Ciphers under System Administration> SSL Configuration

[keithsauer507]

We have a vendor for PCI compliance is requiring all emails to be sent or recieved to be TLS 1.2 by June 30th.  We came up in their system as not being compliant so they want to work with us.  The issue seems to be that when we send email to them, it is fully TLS 1.2 encrypted.  When they send email to us, its is unencrypted and sent in plain text.  This doesn't make sense to me at all because we have TLS 1.0, 1.1 and 1.2 enabled.  Their server should first try the strongest encryption, TLS 1.2, which is enabled and other incoming emails are working with TLS preferred encryption.

The only thing I can think of is perhaps the SSL Ciphers to use? For GUI, Inbound SMTP and Outbound SMTP we have this : RC4-SHA:RC4-MD5:ALL:-aNULL:-EXPORT.

The IT rep at the other company stated this:

We have removed weak ciphers over the years including those that were SWEET Vulnerable

And our Appliance also uses the following Ciphers
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (brainpoolP256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (brainpoolP256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (brainpoolP256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (brainpoolP256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (brainpoolP256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (brainpoolP256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) -

Could this be the issue?
I have a case open with TAC, but usually someone from this forum responds quickly because they have been just recently working on somethign like this.  I appreacate the assistance!

[Ken Stieers]

Look at the logs for this mail.

What Sender group is it hitting?

eg:   (ICID 6901376) ACCEPT sender group SUSPECTLIST match sbrs[none] SBRS None country United Kingdom

Go to Mail Policies/HAT Overview and click on the Mail Flow Policy that Sendergroup is using.

Make sure that TLS is on.

You do need to tighten up your cipher strings, start here:

MEDIUM:HIGH:!RC4:!aNULL:!MD5:!DSS:!EXPORT:@STRENGTH

Some add !DES:

Then check your logs and make sure stuff that needs to be encrypted is coming in encrypted.

Eventually you'll want to remove "MEDIUM:" too.

Then start unchecking the TLS1.0, TLS1.1

[keithsauer507]

It is going to ACCEPT-TLS which is set to TLS(Preferred).

Ok So I think its the ciphers.  They turned off weak ones, they can't mutually negotiate one, so it falls back to cleartext.

I'm having them check again, though checktls.com looked good before, it looks like stronger ciphers are allowed now.  

I changed just for Incoming and Outgoing (did not touch the GUI one yet) to this:

HIGH:-SSLv2:-SSLv3:-aNULL:@STRENGTH

My understanding is that users high ciphers, minus sslv2, minus sslv3 and no null authentications, and they are initiated by the cipher strength.

I'm still keeping an eye on our TLS connections and I'm not noticing any unusually high failure rate or change.  I was able to sucessfully test to my gmail account, to and from, and also successfully test with checktls.  I responded to the company who will be requiring TLS1.2 June 30th so I am awaiting their testing as well.  Just for kicks, I put their email server into a higher up sender group in the HAT Overview to a new Mail Flow Policy TLSREQUIRED, which instead of TLS Preferred, its TLS Required.  Cisco CRES was already using this , I just ordered this directly underneath Cisco CRES (a 2 in our list).

Thanks again for your participation Ken.  Its always greatly appreciated.

[marc.luescherFRE]

We have gone thru a similar exercise a while back
For now we opted to use for in and outbound SMTP
MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:-EDH-RSA-DES-CBC3-SHA:-EDH-DSS-DES-CBC3-SHA:-DES-CBC3-SHA:-EXPORT
And we have a 100% TLS success rate for incoming

Hope that helps
Marc

[marc.luescherFRE]

daily break down on TLS messages using indicated settings:

TLS Version	TLS Cipher	Count	Percentage
TLSv1	AES128-SHA	3221	1.02
TLSv1	AES256-SHA	323	0.1
TLSv1	DHE-RSA-AES128-SHA	1017	0.32
TLSv1	DHE-RSA-AES256-SHA	7464	2.35
TLSv1	DHE-RSA-CAMELLIA256-SHA	324	0.1
TLSv1	DHE-RSA-SEED-SHA	9	0
TLSv1.1	DHE-RSA-AES256-SHA	194	0.06
TLSv1.2	AES128-GCM-SHA256	11225	3.54
TLSv1.2	AES128-SHA	223	0.07
TLSv1.2	AES128-SHA256	318	0.1
TLSv1.2	AES256-GCM-SHA384	19027	6
TLSv1.2	AES256-SHA	1122	0.35
TLSv1.2	AES256-SHA256	30002	9.46
TLSv1.2	DHE-RSA-AES128-GCM-SHA256	14673	4.63
TLSv1.2	DHE-RSA-AES128-SHA	419	0.13
TLSv1.2	DHE-RSA-AES256-GCM-SHA384	164078	51.74
TLSv1.2	DHE-RSA-AES256-SHA	109	0.03
TLSv1.2	DHE-RSA-AES256-SHA256	3938	1.24
TLSv1.2	DHE-RSA-SEED-SHA	95	0.03
TLSv1.2	ECDHE-RSA-AES128-GCM-SHA256	585	0.18
TLSv1.2	ECDHE-RSA-AES256-GCM-SHA384	875	0.28
TLSv1.2	ECDHE-RSA-AES256-SHA	11	0
TLSv1.2	ECDHE-RSA-AES256-SHA384	57856	18.24

[keithsauer507]

Marc, that does help because at the HIGH settings, the vendor still was not able to negotiate tls 1.2.  We can send to them and it negotiates tls 1.2, but they can't send to us.

So I tried your suggestion verbatim....

The vendor still cannot get tls 1.2 negotiated.  He claims its trying to send with this cipher ECDHE-RSA-AES128-GCM-SHA256.  I ran checktls.com and the only 4 ciphers it shows is:
x9f DHE-RSA-AES256-GCM-SHA384 DH 2048 AESGCM 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 available

x6b DHE-RSA-AES256-SHA256 DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 available

x9e DHE-RSA-AES128-GCM-SHA256 DH 2048 AESGCM 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 available

x67 DHE-RSA-AES128-SHA256 DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 available

Not sure how to add in the correct cipher, or if all this cipher change madness requires an appliance reload or kick.  I replied this information to TAC and I am very patiently waiting.

[marc.luescherFRE]

just checking medium:high implies the follwing ciphers are supported :

ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5
IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
IDEA-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5
RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5
RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1
ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
ADH-DES-CBC3-SHA SSLv3 Kx=DH Au=None Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
DES-CBC3-MD5 SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5

and
and we remove the following patterns from the list

-EDH-RSA-DES-CBC3-SHA
-EDH-DSS-DES-CBC3-SHA
-DES-CBC3-SHA:

The ones used are still allowed so I guess it is time to run a packet trace so you can see what the sender is advertising , definitely not what he is telling you.

[keithsauer507]

Ok the other company is only issuing the HELO command upon connection to SMTP port 25.  Usually when you issue the updated EHLO command, the Ironport will respond with STARTTLS.

If the sending server issues HELO, the Ironport will still accept TLS, but the sending server must FIRST issue the STARTTLS command.

So we went back to the other company and they consulted with their vendor.  They came back to us saying because our SMTP hostname is not in the SMTP banner, their server is not issuing the EHLO command.  He says to check our firewall for any filtering.

We have an ASA5525x pair and in it is the inspect esmtp command, but also this additional code according to a KB article is supposed to fix TLS issues in SMTP:

policy-map type inspect esmtp esmtp_map
  parameters
     allow-tls action log

Unfortunately that doesn't do it for us.

I had to go into policy-map global_policy, class inspection_default then issue no inspect esmtp.

Now its working perfectly!

[Mathew Huynh]

Glad to see you had it sorted Keith.

On the note of ESMTP - I generally suggest to always ensure it's disabled as ESMTP inspection on the ASA (and older PIX) would cause the 220 hostname banner to appear as 220 XXXXXXXXX
Also changing start TLS to 250 XXXXXXX

When this occurs, servers will not offer STARTTLS; and there is also instances of servers timing out a connection where 220 XXXXXXXXXX is seen.
Going through your setup, it looks like you did indeed turn this off; so this would be a good thing going forward for future connections.

With regards to the cipher usages - it's always good to run a 'verify' on the cipher string chosen to see the list - obviously a pcap is best to see what ciphers are offered and negotiated to use to get more finite information, but so far it seems to have worked for you.

Keep the thread updated if there was anything else.

Regards,
Matthew