Skip to main content
Grumman
New Member
September 23, 2015
Solved

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

  • September 23, 2015
  • 10 replies
  • 71821 views

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

    Best answer by djwilliams

    jaustgen wrote:

    Was there ever any resolution to this?

    The 5.2.5 upgrade did fix this.  I had this escalated up to the executive level through my sales team.  A formal response never came.  I have tested 5.2.5 and they have fixed the default DH group by setting it to 14.  It appears they were using group 5 before.

    10 replies

    denache
    New Member
    September 23, 2015
    Grumman
    GrummanAuthor
    New Member
    September 23, 2015

    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
    New Member
    September 23, 2015

    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
    GrummanAuthor
    New Member
    September 23, 2015

    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
    New Member
    September 23, 2015

    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
    GrummanAuthor
    New Member
    September 23, 2015

    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
    New Member
    September 23, 2015

    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
    New Member
    September 24, 2015

    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
    New Member
    September 25, 2015

    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

    dwilliams1979
    New Member
    September 25, 2015

    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
    New Member
    September 25, 2015

    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.

    emnoc
    New Member
    September 25, 2015

     

     

     

    BWiebe
    New Member
    September 28, 2015

    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
    New Member
    September 28, 2015

    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
    New Member
    October 16, 2015

    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
    New Member
    October 16, 2015

    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