Forum Discussion

GavinW_29074's avatar
Icon for Nimbostratus rankNimbostratus
May 24, 2012

SSL 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 - 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 ( 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 (, which covers RFC5746 and suggests that the F5's should now support Secure Renegotiation only...



However running a check using SSLLabs ( 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...







7 Replies

  • Ah, 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:






    If you get an error:




    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:




    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.



  • Also, since you're on 11.1.0, you should have:


  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?





  • Josh

    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:

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


  • Gavin,



    Aha, ok so:


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



  • Gavin,



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





    I am wondering if there is a lack of maturity in the tool that was used to test.



  • Josh



    Cheers for checking...


    So as far as your concerned, the f5 is working as it should?



    Cheers again.


  • Gav,



    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.