Choosing outbound SMTP cipher

[theglossy1]

I notice that when the FortiMail sends outbound mail, it's using the RC4 cipher: it looks like (version=TLSv1.2 cipher=RC4-SHA bits=128/128) when I view headers for a message sent from the FortiMail. We're using version 5.2. I'm sure it can be set to AES128 or something better, but I'm not sure how to achieve this. Any thoughts?

[emnoc · Accepted solution]

But there's another means . It's called FIPS mode, just be aware of the limits within FIPS mode of operation.

execute fips

That would be the correct means. I believe  set srtong-crypto does nothing for TLS connections between MTAs.

[theglossy1]

Yes, I'm aware of negotiating. I'm checking the headers in my Gmail account which show the following:

Received: from somewhere.example.com (somewhere.example.com [1.1.1.1])
 by mx.google.com with ESMTPS id f192si290559iof.16.2015.04.29.14.58.53
 for <someguy@gmail.com>
 (version=TLSv1.2 cipher=RC4-SHA bits=128/128);
 Wed, 29 Apr 2015 14:58:54 -0700 (PDT)

Interestingly, when I get messages from Fortinet indicating that I have a new forum message, I see these headers:

Received: from smtp.fortinet.com (smtp.fortinet.com. [208.91.113.81])
 by mx.google.com with ESMTPS id gl1si2655455pbd.121.2015.04.30.02.26.49
 for <someguy@gmail.com>
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
 Thu, 30 Apr 2015 02:26:50 -0700 (PDT)

I'm guessing that Fortinet is using their own product, but they must have FIPS support enabled or something else magical because they are sending another cipher...

[emnoc]

Interestingly, when I get messages from Fortinet indicating that I have a new forum message, I see these headers:

The latter is because the following was negoiated as ECDHE-RSA-AES128-SHA , the funny tho Ijust did the same thing to my personal gmail account and got the following; version=TLSv1.2 cipher=RC4-SHA bits=128/128 also.But if I send from gmail, I get the same ( version=TLSv1.2 cipher=RC4-SHA bits=128 verify=CAFAIL) ) .So this might be   gmail doing this ans restricted to this cipher all others MTA are using  AEAS128 or 256 as the cipher of choice

I agreed that RC4 is not a suitable cipher by all means and this is very disturbing ;) I'm writing up some  new fortimail documents and going to reference this in my mail.

[emnoc]

Like I stated earlier, your mis-understanding strong-crypto enable/disable  the services. The above has NOTHING to do w/TLS and SMTP services.

See the screenshot attached. enabling FIPS is a sure 100% way to eliminate RC4-SHA/MD5. In the OP case google is supporting RC4 in it's tls offerings.

[Bromont_FTNT]

run the following on your Fortimail with both strong-crypto enabled and disabled:

openssl s_client -cipher RC4-MD5 -connect 192.168.113.202:25 -starttls smtp

[emnoc]

Can't figure out how to load 2files,  but either way here the webGUI admin access with and witout strong-crypto. FIPS mode is your friend

http://socpuppet.blogspot.com.es/2013/02/testing-for-tls-support-wwwsmtp-with.html

ken@socpuppets

Enjoy

[emnoc]

But STARTTLS has to be in the EHLO ;)

Repeat after me;

The global command strong crypto enabled does not stop "your fortimail" from using RC4 if the far end supports and  negotiate  the use of RC4-MD5|SHA" , which is the case of  gmail.com and quite a few others mail systems I just tested.

 Here's the  RFC about this, but again it's just a RFC and not ever thing follows the RFCs.

https://tools.ietf.org/html/rfc7465

I also notice on the date it's quite new 2015. So obvious the fortimail and gmail for example, has ignored this.

:)

[Bromont_FTNT]

That's why I said I'd contact dev about this as RC4 should also be removed when strong-cryto is disabled.

[Carl_Windsor_FTNT]

When strong crypto is enabled, RC4 is disabled in non-mail protocols.  RC4 is however still included for SMTP to support legacy MS Exchange Servers and Outlook clients which do not support other cypher suites due to bugs e.g. https://support.microsoft.com/en-us/kb/938857

In all cases, the receiving server should negotiate with FortiMail the strongest possible mutually supported method.  As Bromont tested (and I have reproduced), GMail is negotiating version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA in the majority of cases.  If you are seeing differently, let us know which Google IP as it may be a badly configured server somewhere or an Exchange server as per the MS bug referenced above.

Whilst RC4 might mot be the most secure method, the alternative if we were to disable it totally would be to fall back to plaintext SMTP, so this is considered an acceptable compromise in this instance.