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.....

[denache · Accepted solution]

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

[Grumman]

denache wrote:

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

Thank you for this!

Unfortunately it did not help...

It still comes up as the same vulnerability...

[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.

[Grumman]

emnoc wrote:

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.

Thank you for the swift reply!

I have restarted the process but it is still coming up in the scan....

The fortiOS version is: v5.2.3,build670 (GA) and the Certificate has a 2K bit key...

[denache]

According to http://kb.fortinet.com/kb/documentLink.do?externalID=FD36915 when you enable strong-crypto you should not see CAMELLIA cipher suite.

Maybe you didn't set ssl-dh-bits in config wanopt ssl-server or maybe in config firewall ssl setting

[Grumman]

denache wrote:

According to http://kb.fortinet.com/kb/documentLink.do?externalID=FD36915 when you enable strong-crypto you should not see CAMELLIA cipher suite.

Maybe you didn't set ssl-dh-bits in config wanopt ssl-server or maybe in config firewall ssl setting

I have set the ssl-dh-bits to 2048 and restarted the service on a previous step above but it did not help....

Issue and vulnerability still exists....

[emnoc]

can you run some diag against the https and sslvpn daemons

i.e

diag debug reset

diag debug en

diag debug application httpsd -1

diag debug application sslvpn -1

Some thing is wrong in the approach your taking. Concentrate on the last diag command

[dwilliams1979]

We have someone that is seeing the exact same thing.  I escalated up through sales channels because support said "You will have to wait for 5.2.5"  The super smarties who replied told me the same thing you were told. 

config global settings
set strong-crypto enable

When that didn't work they said we had to regenerate the certs even though we are using a 2048 bit RSA sign cert.  I also fail to see how the cert affects the supported cipher suites negotiated with the end points.  I thought that was more a function of what version of SSL/TLS you were supporting.  

I had the greatest hope for the following command

config firewall ssl setting
    set ssl-dh-bits 2048

but that didn't seem to affect the sslvpn ssl process.  

I too am at a loss and would love a real answer from someone about why our security appliance, that is running latest code, is failing a PCI audit.  I will be running the debug commands suggested shortly.  I hope the shed some light on this.  Is there anything in particular I should be looking for?

debug output from a scan detecting the vulnerability

[118:root:994849]SSL state:before/accept initialization (141.212.120.165)
[118:root:994849]SSL state:SSLv3 read client hello A (141.212.120.165)
[118:root:994849]SSL state:SSLv3 write server hello A (141.212.120.165)
[118:root:994849]SSL state:SSLv3 write certificate A (141.212.120.165)
[117:root:994848]SSL state:before/accept initialization (141.212.120.165)
[117:root:994848]SSL state:fatal handshake failure (141.212.120.165)
SSL state:before/accept initialization (141.212.120.165)
[117:root:994848][116:root:994849]SSL state:SSLv3 read client hello A (141.212.120.165)
[117:root:994848][116:root:994849]SSL state:SSLv3 read client hello C:(null)(141.212.120.165)
SSL state:SSLv3 write server hello A (141.212.120.165)
[117:root:994848]SSL_accept failed, 1:no shared cipher
[117:root:994848]Destroy sconn 0x2a98c4f800, connSize=4.
[116:root:994849]SSL state:SSLv3 write certificate A (141.212.120.165)
[118:root:994849]SSL state:SSLv3 write key exchange A (141.212.120.165)
[118:root:994849]SSL state:SSLv3 write server done A (141.212.120.165)
[118:root:994849]SSL state:SSLv3 flush data (141.212.120.165)
[118:root:994849]SSL state:SSLv3 read client certificate A:system lib(141.212.120.165)
[118:root:994849][116:root:994849]SSL state:SSLv3 read client certificate A:system lib(141.212.120.165)
SSL state:SSLv3 write key exchange A (141.212.120.165)
[116:root:994849]SSL state:SSLv3 write server done A (141.212.120.165)
[116:root:994849]SSL state:SSLv3 flush data (141.212.120.165)
[116:root:994849]SSL state:SSLv3 read client certificate A:system lib(141.212.120.165)
[116:root:994849]SSL state:SSLv3 read client certificate A:system lib(141.212.120.165)
[118:root:994849]SSL state:fatal handshake failure (141.212.120.165)
[118:root:994849]SSL state:sslv3 alert handshake failure(141.212.120.165)
[118:root:994849]SSL_accept returned 0.

[118:root:994849]Destroy sconn 0x2a98c49000, connSize=4.

[emnoc]

but that didn't seem to affect the sslvpn ssl process.    

I think that's for the  ssl-explicit proxy btw.

So on the debug, the  output shows the client  connecting with sslvpn and negotiated . Was any details draft on the cert and such.  Also if you  pull the certificate from the   Fortigate what does it show you on the key-size? I still believe you  server-crt is a  1k bit certification or the wrong cert deployed or your mistaken on what you have installed.

I would double,  and triple check by grabbing the serial# and reviewing what certificates you have installed.

e.g ( to see what you have )

   diag hardware certificate

e.g (i.e checking goog-gmail for a example  )

openssl s_client -connect www.gmail.com:443 | openssl x509  -dates -serial -noout  -text | grep "RSA Public"

E.g ( see attached of  the keysize from a download certificate from a FGT100D )

Ken