Forum Discussion
GavinW_29074
Nimbostratus
NimbostratusSSL Renegotiation on PEN Test???
Hi there
We're currently getting some of our sites which are served through our F5's pen tested...
Our F5's are currently running v11.1.0 HF2.
The PEN test report has flagged the F5's as being vulnerable to http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 - An SSL Renegotiation vulnerability...
I've had a search on AskF5 and have come up with a couple of Articles that seem to give differing stances...
SOL10737 (http://support.f5.com/kb/en-us/solutions/public/10000/700/sol10737.html) suggests that the vulnerability has been patched and therefore we shouldn't be affected. It also states that the default value for 'Renegotiation' on the ClientSSL profile should be Disabled. However on checking our F5's, the default clientssl profile appears to have SSL Renegotiation enabled.
I then found SOL13512 (http://support.f5.com/kb/en-us/solutions/public/13000/500/sol13512.html?sr=21445394), which covers RFC5746 and suggests that the F5's should now support Secure Renegotiation only...
However running a check using SSLLabs (https://www.ssllabs.com/ssltest) I get a warning that says Secure Renegotiation is 'Not Supported'.
So who's right?
And what, if any steps, should I take against the PEN test report???
Swift response appreciated as we're running some more tests over the next few days so can retest if required...
Cheers
Gavin
7 Replies
jwham20Ah, the pen test circle of death. It's like an elementry school game of he said, she said.... who do you believe? Believe your own eyes.
Snag a Linux box and run the following test:
openssl s_client -connect :
It will connect, you'll see some cert data, then a blinking cursor. Type a capitol R and hit enter, soon you'll see:
RENEGOTIATING
If you get an error:
RENEGOTIATING
13627:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1102:SSL alert number 40
13627:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:539:
If you get:
RENEGOTIATING
depth=0 /C=US/ST=WA/L=S/O=MyCompany/OU=IT/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=WA/L=S/O=MyCompany/OU=IT/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
verify return:1
You have renegotiation turned on.
13618:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:539:
Hope it helps.
-Joshm- jwham20Also, since you're on 11.1.0, you should have:
http://tools.ietf.org/html/rfc5746 Transport Layer Security (TLS) Renegotiation Indication Extension
Which was the fix for the reneg issue. It might be that the Pen test did not check for the secure_renegotiation flag
You happen to know the tool they were using?
-Joshm 
GavinW_29074Josh
Cheers for your response...
I found a similar test on one of the sites I stumbled upon, and in order to get the error response, I had to disable the Renegotiation option in the clientssl profile...
So that to me suggests that insecure client renegotiation is enabled by default...
I got similar results on this site: http://netsekure.org/2009/11/tls-renegotiation-test/
Running against one of our sites with 'Renegotiation' enabled in the ClientSSL profile, I get:
Connecting to x:443
Site supports secure renegotiation!
Sending partial HTTP request
Trying to renegotiate
Site allows client initiated renegotiation!
Unpatched servers allowing client initiated renegotitation are vulnerable to a variation of the TLS MiTM attack.
Disabling 'Renegotiation' on the same site gives:
Connecting to x:443
Site supports secure renegotiation!
Sending partial HTTP request
Trying to renegotiate
Failed to renegotiate, site is not vulnerable
So I'm mighty confused at the moment...
It also appears that SSLabs does test for Secure Negotiation, but it claims that it's Not Supported on the F5's with either 'Renegotiation' enabled OR disabled...
Our default clientssl currently looks like:list /ltm profile client-ssl clientssl ltm profile client-ssl clientssl { alert-timeout 60 allow-non-ssl disabled app-service none authenticate once authenticate-depth 9 ca-file none cache-size 262144 cache-timeout 3600 cert default.crt chain none ciphers DEFAULT client-cert-ca none crl-file none handshake-timeout 60 key default.key mod-ssl-methods disabled mode enabled options { dont-insert-empty-fragments } passphrase none peer-cert-mode ignore proxy-ssl disabled renegotiate-max-record-delay 10 renegotiate-period indefinite renegotiate-size indefinite renegotiation disabled secure-renegotiation require server-name none sni-default false sni-require false strict-resume disabled unclean-shutdown enabled }
Will try and find out what software they're using for the Pen test and post back...
Cheers
Gavin- jwham20Gavin,
Aha, ok so:
http://support.f5.com/kb/en-us/solutions/public/13000/500/sol13512.html - secure renegotiation setting.
I'm going to take a look at a tcpdump from version 11. The packets don't lie, so it should show if the secure renegotiation flag is set or not.
-joshm - jwham20Gavin,
Looking at a capture from an 11.1.0 system, it would appear the SSL handshake has the correct flags set:
ClientHello is received, the server MUST check
-if it includes the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV.
If it does, set the secure_renegotiation flag to TRUE.
-if the "renegotiation_info" extension is included in the ClientHello.
If the extension is present, set secure_renegotiation flag to TRUE.
The server MUST then verify that the length of the "renegotiated_connection" field is zero, and if it is not, MUST abort the handshake.
----------
If the secure_renegotiation flag is set to TRUE, the server MUST include an empty "renegotiation_info" extension in the ServerHello
message.
I am wondering if there is a lack of maturity in the tool that was used to test.
-Joshm - GavinW_29074Josh
Cheers for checking...
So as far as your concerned, the f5 is working as it should?
Cheers again.
Gav - jwham20Gav,
You know.. whenever i go to say something like that.. I always think "This is gonna come back and bite me in the behind"
But yep, it looks like it does have all the magic to do secure renegotiation.
You could confirm in your environment with a packet capture of the connection, just make sure to get the iniitial handshake.
-joshm
