FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
fropert_FTNT
Staff
Staff
Article Id 194883
Description
SSLv3 and TLS do not properly associate renegotiation handshakes with an existing connection, which can allow man-in-the-middle attacks on every application/protocol that implements SSLv3 or TLS.  This has been mentioned by the Mitre Corporation in CVE-2009-3555.

When the vulnerability was initially disclosed the only available protection was to reject the renegotiation when the server receives a new ClientHello in an existing SSL/TLS connection.  However this mitigation technique may not be possible if the server requires a client certificate.

Later on the RFC5746 - TLS renegotiation indication extension was published and introduced the renegotiation_info extension.  It is the correct solution to address CVE-2009-3555 and it is implemented in all Fortinet products.

It has been observed that automatic vulnerability scanners may generate a false positive alert regarding insecure SSL/TLS session renegotiation.

It is suggested to use either SSLyze or OpenSSL if a vulnerability scanner reports an alert about CVE-2009-3555.

SSLyze method

See https://github.com/nabla-c0d3/sslyze for download and install instructions.
Replace DUT by the device under test IP address.

Client-initiated renegotiations rejected and secure renegotiation supported

The service under test is a FortiWeb 5.3.4 and its HTTPS GUI webadmin.

python sslyze.py DUT --reneg

SCAN RESULTS FOR DUT:443 - DUT:443
 ----------------------------------------------------

  * Session Renegotiation:
      Client-initiated Renegotiations:   OK - Rejected
      Secure Renegotiation:              OK - Supported

The target host rejects all client-initiated renegotiations including legitimate usages like client certificates or change of encryption strength.
The relevant information is the secure renegotiation support. It must be OK - Supported.


Client-initiated renegotiations allowed and secure renegotiation supported

The service under test is a FortiGate with FortiOS 5.2.3 and its HTTPS GUI webadmin.

python sslyze.py DUT --reneg

SCAN RESULTS FOR DUT:443 - DUT:443
 ----------------------------------------------------

  * Session Renegotiation:
      Client-initiated Renegotiations:   VULNERABLE - Server honors client-initiated renegotiations
      Secure Renegotiation:              OK - Supported

The "Client-initiated renegotiation:  VULNERABLE - Server honors client-initiated renegotiations" message is not a valuable proof that the device is vulnerable because secure renegotiation is supported.
As an information, FortiGate, FortiMail and probably other products offers a PKI user authentication feature based on client certificate which may requires a client-initiation renegotiation to be operational.

OpenSSL method

One OpenSSL version that support secure renegotiation and another that does not support it must be used.
Latest OpenSSL version installed in the operating system should support secure renegotiation.
OpenSSL 0.9.8k is suggested as the version that does not support secure renegotiation.

OpenSSL 0.9.8k installation

wget https://www.openssl.org/source/old/0.9.x/openssl-0.9.8k.tar.gz -O /tmp/openssl-0.9.8k.tar.gz
cd /tmp
tar xzvf openssl-0.9.8k.tar.gz
cd openssl-0.9.8k
./config
make
cd apps
./openssl version
OpenSSL 0.9.8k 25 Mar 2009


Client-initiated renegotiation verification

Replace DUT by the device under test IP address.
Type R once connected.
If a certificate information is returned after the RENEGOTIATING line by the device then it means that a renegotiation can be initiated from client- side.
A man-in-the-middle attacker could try to initiate a renegotiate but it doesn't confirm the server side which is a Fortinet product is vulnerable.


Client-initiated renegotiation is allowed:

The service under test is a FortiGate with FortiOS 5.2.3 and its HTTPS GUI webadmin.

openssl s_client -connect DUT:443
CONNECTED(00000003)
...
R
RENEGOTIATING
depth=1 C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = support, emailAddress = support@fortinet.com
verify error:num=19:self signed certificate in certificate chain
verify return:0
read:errno=0


Client-initiated renegotiation is rejected:

The service under test is a FortiWeb 5.3.4 and its HTTPS GUI webadmin.

openssl s_client -connect DUT:443
CONNECTED(00000003)
...
R
RENEGOTIATING
3071092512:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:617:



Secure renegotiation verification - Client support it and server (Fortinet device) support it

It is common usage that today all recent SSLv3/TLS clients including all well-known browsers have RFC5746 support.
By default OpenSSL is compiled with implicit secure negotiation enabled.

Replace DUT by the device under test IP address.
Type R once connected.

openssl s_client -connect DUT:443 -tlsextdebug
CONNECTED(00000003)
...
R
RENEGOTIATING
TLS server extension "renegotiation info" (id=65281), len=25
0000 - 18 8a a0 95 d7 28 4b d2-c5 79 7e da 4a b4 8f 8c   .....(K..y~.J...
0010 - ca 3e a5 bc af b0 23 35-3a                        .>....#5:
...
depth=1 C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = support, emailAddress = support@fortinet.com
verify error:num=19:self signed certificate in certificate chain
verify return:0
read:errno=0


The RFC5746 secure renegotiation has been negotiated as per the line "TLS server extension "renegotiation info" (id=65281), len=25" which is a proof that the Fortinet product is protected.

Secure renegotiation verification - Client does not support it and server (Fortinet device) support it

To perform this verification the openssl version 0.9.8k must be used client-side.
The server-side is a FortiGate with FortiOS 5.2.3 and its HTTPS GUI webadmin.

Replace DUT by the device under test IP address.
Type R once connected.

cd /tmp/openssl-0.9.8k/apps
./openssl s_client -connect DUT:443 -tls1
CONNECTED(00000003)
R
RENEGOTIATING

The device under test should trigger a TLS alert or return the following error after timeout:
6221:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:

The handshake failure messages indicates the server-side device which is a Fortinet product has rejected the client request as the secure_renegotation extension wasn't asked by the client.

As an information, by default FortiOS 5.2.3 HTTPS GUI webadmin allows only TLSv1.1 and TLS1.2.
For unsafe legacy renegotiation testing purpose only, the admin-https-ssl-versions setting could be changed to allow TLSv1.0 to allow old openssl 0.9.8k to be able to connect to the FortiGate:

config system global
set admin-https-ssl-versions tlsv1-0 tlsv1-1 tlsv1-2
end


After testing, the admin-https-ssl-versions setting must be set back to its original setting:

config system global
unset admin-https-ssl-versions
end


Solution
Fortinet products should be upgraded to the following patch release to address CVE-2009-3555:
  • FortiOS 4.2.0 GA Release and later
  • FortiManager 4.2.0 GA Release and later
  • FortiAnalyzer 4.3.0 GA Release and later
  • FortiMail 4.0.4 GA Release and later
  • FortiAP 5.0.8 GA Release and later
  • FortiClient 4.2.0 GA Release and later
Assessment of products which are not mentioned here could be performed with the manual testing procedure available in this document.

Contributors