Disable SSL/TLS Diffie-Hellman Modulus <= 1024 Bits (Logjam)

[Grumman]

We were doing some penentration tests on our systems and we found out that on our FortiGate 200D which has SSL VPN enabled it is susceptible to the LongJam attack.

In the SSL VPN Settings, the below values have been set:

    set algorithm high     set sslv2 disable     set sslv3 disable

In the Global COnfig, the below settings have been set:

    set strong-crypto enable

Yet, when we perform the test again, the below output is presented to us:

Vulnerable connection combinations :   SSL/TLS version : TLSv1.1   Cipher suite : TLS1_CK_DHE_RSA_WITH_AES_256_CBC_SHA   Diffie-Hellman MODP size (bits) : 1024     Warning - This is a known static Oakley Group2 modulus. This may make     the remote host more vulnerable to the Logjam attack.   Logjam attack difficulty : Hard (would require nation-state resources)   SSL/TLS version : TLSv1.1   Cipher suite : TLS1_CK_DHE_RSA_WITH_3DES_EDE_CBC_SHA   Diffie-Hellman MODP size (bits) : 1024     Warning - This is a known static Oakley Group2 modulus. This may make     the remote host more vulnerable to the Logjam attack.   Logjam attack difficulty : Hard (would require nation-state resources)   SSL/TLS version : TLSv1.1   Cipher suite : TLS1_CK_DHE_RSA_WITH_AES_128_CBC_SHA   Diffie-Hellman MODP size (bits) : 1024     Warning - This is a known static Oakley Group2 modulus. This may make     the remote host more vulnerable to the Logjam attack.   Logjam attack difficulty : Hard (would require nation-state resources)   SSL/TLS version : TLSv1.1   Cipher suite : TLS1_CK_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA   Diffie-Hellman MODP size (bits) : 1024     Warning - This is a known static Oakley Group2 modulus. This may make     the remote host more vulnerable to the Logjam attack.   Logjam attack difficulty : Hard (would require nation-state resources)   SSL/TLS version : TLSv1.1   Cipher suite : TLS1_CK_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA   Diffie-Hellman MODP size (bits) : 1024     Warning - This is a known static Oakley Group2 modulus. This may make     the remote host more vulnerable to the Logjam attack.   Logjam attack difficulty : Hard (would require nation-state resources)   SSL/TLS version : TLSv1.0   Cipher suite : TLS1_CK_DHE_RSA_WITH_AES_256_CBC_SHA   Diffie-Hellman MODP size (bits) : 1024     Warning - This is a known static Oakley Group2 modulus. This may make     the remote host more vulnerable to the Logjam attack.   Logjam attack difficulty : Hard (would require nation-state resources)   SSL/TLS version : TLSv1.0   Cipher suite : TLS1_CK_DHE_RSA_WITH_3DES_EDE_CBC_SHA   Diffie-Hellman MODP size (bits) : 1024     Warning - This is a known static Oakley Group2 modulus. This may make     the remote host more vulnerable to the Logjam attack.   Logjam attack difficulty : Hard (would require nation-state resources)   SSL/TLS version : TLSv1.0   Cipher suite : TLS1_CK_DHE_RSA_WITH_AES_128_CBC_SHA   Diffie-Hellman MODP size (bits) : 1024     Warning - This is a known static Oakley Group2 modulus. This may make     the remote host more vulnerable to the Logjam attack.   Logjam attack difficulty : Hard (would require nation-state resources)   SSL/TLS version : TLSv1.0   Cipher suite : TLS1_CK_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA   Diffie-Hellman MODP size (bits) : 1024     Warning - This is a known static Oakley Group2 modulus. This may make     the remote host more vulnerable to the Logjam attack.   Logjam attack difficulty : Hard (would require nation-state resources)   SSL/TLS version : TLSv1.0   Cipher suite : TLS1_CK_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA   Diffie-Hellman MODP size (bits) : 1024     Warning - This is a known static Oakley Group2 modulus. This may make     the remote host more vulnerable to the Logjam attack.   Logjam attack difficulty : Hard (would require nation-state resources)

Does anyone know how to disable the cipher in question or upgrade it to a 2048 bits?

Thank you in advance,

Thanasis

[denache · Accepted solution]

Try set ssl-dh-bits 2048 (see http://docs.fortinet.com/d/fortigate-cli-reference-pdf)

[emnoc · Accepted solution]

Did you kill off the sslvpn process and let it restart?

Also what version of  fortiOS are you running? And are you 100% sure the server-certificate is a 1k or 2k bit key?

Something don't sound right. Even 4.0MR3 supports 2k bit keys by default.

[BWiebe · Accepted solution]

Not that it will help immediately, but I am working through this with a client as well as their scans are showing the same thing.

I tested a few of my client sites using weakdh.org and confirmed the =1024 bit issue.  I have a test firewall on 5.4 Beta 3, and it passes with 2048 bit DH by default.

Now - if Fortinet would just give us a magic pill for 5.2.* I'd be happy.....

[dwilliams1979]

Well I wish you were correct but this is the output from the cert that I downloaded from my browser after visiting the IP address on the WAN1 interface of the Fortigate.

        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)

[dwilliams1979]

It would really be great if we stopped focusing on the cert and or private key.  The cipher suite is chosen before the cert is ever sent.  If the weakness is in the cipher suite, or the default implementation of the cipher suite, the vulnerability is exposed before the cert or keys are exchanged.  I have attached the output from part of the failed audit.  I hope we can track this down.  

As I understand it, and perhaps I am wrong, but the server starts with a cert/public key and a private key.  The key may use 2048 bit RSA cryptography and that influences which cipher suite is selected by the server during the SSL/TLS handshake but it doesn't determine which one it uses for key exchange.  A client can support any number of cipher suites that leverage RSA for authentication but that isn't the end of it.  If the client supports 5 cipher suites that use RSA for authentication then the server has to choose one to use for key exchange.  As I understand it the server usually picks whichever cipher suite that is most preferred by the client and uses the same cryptographic method for authentication that was used in its cert/key.  

This vulnerability isn't in RSA it is in the Diffie Hellmen portion of the cipher suite that is available for use.  The key exchange portion of the cipher suite.  It could use RSA but if DH is chosen the RSA public key (that we keep talking about) is only used to sign the keys chosen during the DH calculations. (The vulnerable part)  In most SSL equipment I can simply define which cipher suites to support.  I can't seem to do that with the Fortigate.  

The part that I find curious is the vulnerability seems to be due to the < 2048 bit implementation of DH which the default is 1024 I guess.  I wasn't aware that we could modify the bit modulus used by DH in SSL.  You can choose your DH group in IPSEC, I guess I didn't know it was a configurable option in SSL.   My initial thought is to simply exclude any of the DH cipher suites that the server can support.  In the fortigate I can't do that.  Neither can I seem to configure the DH group so the modulus is whatever is default.

Like I said, maybe I'm wrong, I'd just like a solution to the problem on the Fortigate that I do not have to wait 2 months for it to be released in the next minor version of software.  I'm fine being wrong...it wouldn't be the first time.

[BWiebe · Accepted solution]

Not that it will help immediately, but I am working through this with a client as well as their scans are showing the same thing.

I tested a few of my client sites using weakdh.org and confirmed the =1024 bit issue.  I have a test firewall on 5.4 Beta 3, and it passes with 2048 bit DH by default.

Now - if Fortinet would just give us a magic pill for 5.2.* I'd be happy.....

[dwilliams1979]

Thank you BWiebe,

It may not be the fix we are looking for but it is additional corroboration that the issue is real and posing a significant problem for people subject to these regulations.  I'm still searching for the magic pill for 5.2 and will update this if I ever find one.

[dwilliams1979]

For those who want to understand better how logjam affects SSL/TLS and what role your signed certificates play.  I thought this was a very easy to read explanation of situation.

https://blog.cloudflare.com/logjam-the-latest-tls-vulnerability-explained/

You never know what exploit is going to come out next and what it might affect.  Providing the ability to configure these things reduces the need to rush out a new code release and expect all devices be upgraded.  That gets difficult when there are hundreds of devices that need upgrading.

[emnoc]

Very good info , but  all of this can easily be mitigated by using a update browser and better yet controls on your webserver for those that manges webservers

( apache )

e.g

  SSLCipherSuite HIGH:!aNULL:!MD5

   SSL_CIPHER_EXPORT

or

SSLHonorCipherOrder On
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH 
SSLProtocol All -SSLv3 -SSLv2 

[dwilliams1979]

I absolutely agree that this should be easily configured on the web server.  The problem that is outlined in this forum post is that the Fortigate is the web server for this application and we are not given the same controls that we have on apache or IIS or nginx or the list goes on.  We just need to be able to configure this stuff in FortiOS.  Whether it is the administration page, sslvpn, or explicit proxy functions, control over the cipher suites would be incredible.  As of right now we have customers that still cannot pass PCI scans because the Fortigate can't do it.  Short of completely disabling sslvpn the Fortigate running the newest available GA code cannot pass PCI and the fix is not configurable.  Although, I'm guessing that it actually is the commands are just not exposed in the cli.  

[emnoc]

Have any one tried to work with the sslv3  ips rule that fortinet support drafted up and then block clients that offer up weaker ciphers? A  this was done in the snort community and a simple custom rule could be drafted to block export_ciphers.

You can test your fortigate VIP if you suspect exposre to export_ciphers at https://tools.keycdn.com/freak

aka the logjam checker  . Also it  doesn't hurt to read the CVE 2015-0204

FWIW: I personally never seen any problems with fortigate between server and clients..

[dwilliams1979]

I thought about IDS/IPS too but that won't fix the issue on the Fortigate itself.  It is offering secure web services using DH key exchange, which is ok, but it uses 1024 bit (Group 2) in the implementation and so far I have not found anyway to configure the SSLVPN service to use 2048 bit only. (Group 14)  IPS could potentially block sessions that use anything lower than group 2 but that would be all of them.