New Member

Solved

Choosing outbound SMTP cipher

Forum|Forum|11 years ago
April 29, 2015
17 replies
36024 views

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?

Best answer by abelio

emnoc wrote:

execute fips

Be careful with this; all your current config settings is lost after enter it.

Beside of that, it's valid only if you have installed a FIPS-certified firmware build provided by TAC

regards

Bromont_FTNT

Staff

try at CLI:

config system global

set strong-crypto enable

end

theglossy1Author

New Member

@Bromont_FTNT: That only sets the administrative interface to stronger crypto, not the outbound MTA. It was already set.

Bromont_FTNT

Staff

on my system with a test to gmail:

With strong-crypto disabled: (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);

With strong-crypto enabled: (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);

emnoc

New Member

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.

abelioAnswer

SuperUser

emnoc wrote:

execute fips

Be careful with this; all your current config settings is lost after enter it.

Beside of that, it's valid only if you have installed a FIPS-certified firmware build provided by TAC

regards

theglossy1Author

New Member

Okay, I think the answer is running

execute fips

from the cli. The fact that it requires a special build and resets the whole configuration is ridiculous though. How about a command like

mta encryption aes128 hash sha256

... or even an option within the GUI that simply changes it rather than all the complexity and disruption that "execute fips" entails. If somebody from the FortiMail development team is reading this, I think this would be worthy of considering for the next version of software.

emnoc

New Member

Also keep in mind that no matter what you do,the both parties have to "Negotiated" the cipher used. I'll check here today on a old FML appliance but I believe the current versions are fips supported. But you can ask support.

fwiw, I got worried when I seen the OP original post and I check a few mails headers and seen none that used RC4 over TLS. I believe this was also striked by a current RFC for denying RC4 over TLS connections. I would still raise a support ticket with TAC if you suspect this is a issue.

theglossy1Author

New Member

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

New Member

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

New Member

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.

ciphers.jpg

Bromont_FTNT

Staff

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

New Member

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

2ndfile.jpg

emnoc

New Member

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

Staff

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

Staff

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.

Sign up

Login with SSO

Login to the community

Login with SSO