DescriptionSSLv3 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 supportedThe 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 supportedThe 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 2009Client-initiated renegotiation verificationReplace 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 itIt 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=0The 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 itTo 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
endAfter testing, the admin-https-ssl-versions setting must be set back to its original setting:
config system global
unset admin-https-ssl-versions
end
SolutionFortinet 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.