Differentiate between client-initiated and server-initiated SSL renegotiations

Hi!

I'm trying to configure my F5 LTM 11.3 to be able to allow server-initiated SSL renegotiations but reject client-initiated SSL renegotiations. In the clientssl profile I've configured a renegotiation period of 600 seconds as I want to be able to renegotiate with the client, but only if I ask for it (Hello Request message sent from the F5 to the client) and after that I've unchecked the Renegotiate checkbox as I don't want to accept the client-initiated renegotiations.

The problem is that it seems that the SSL renegotiation options in the sslclient profile doesn't allow me to differentiate between client and server initiated renegotiations. If I uncheck the Renegotiation option then I can't renegotiate with the client when I ask for it because the Hello sent from the client in answer to my Hello Request message is rejected, and I'd like to be accepted as I've asked for it.

It'd be nice to have two options, client-initiated renegotiation and server-initiated renegotiation so I could check or uncheck the specific behaviour that I want to allow or reject.

Knowing of this limitation, I'm now exploring if I could solve it with an iRule, but I guess I can't as the CLIENTSSL_HANDSHAKE event is called when the handshake is finished and I'd need to be able to abort the handshake before it's made.

So... any way to detect the "Hello Request" message in my iRule to manage the CLIENTSSL_HANDSHAKE accordingly. Anyone has solved this problem of differentiate between client/server initiated renegotiations?

Thanks! Looking forward to hearing your thoughts!

12 Replies

gbbaus_104974
Historic F5 Account
Mar 26, 2014
Im not sure I follow.

Im not in front of the BigIP GUI right now, but Im pretty sure you can set the renegotiation different for the clientssl profile an the serverssl profile, and then on the VIP don't use the same SSL profile for Client and Server, ie use different (custom ones) for the respective client and server side.

Did you try that already ?
Angel_Lopez_116
Altostratus
Mar 27, 2014
My explanation maybe is a bit confusing because of the use of the word "server" when I really mean the BigIP.

Think in the SSL connection established between the client and the BigIP. In this SSL connection the renegotiation can be initiated from the client (that's what I want to reject) or the BigIP (that's what I want to allow and forc every 600 seconds).

If I uncheck the Renegotiation checkbox in my sslclient profile, then I don't allow any kind of renegotiaton, neither client initiated nor BigIP initiated.

In a SSL dialog between client and BigIP, there's a way to differentiate when the BigIP has initiated the negetotiation, and that's the "Hello Request" message sent from the BigIP when it's requesting the "Hello" from the client to start the new handshake, and that's what I thought I could manage from an iRule, but I guess I can't.

Maybe it's more clear now my problem... can I allow BigIP initiated renegotiations while rejecting client initiated renegotiations?

Just using my clientssl profile that manages the SSL connection between client and BigIP as the connection between BigIP and internal pool node is HTTP, I don't use SSL here, just with the Internet clients that connect to my VIP.

Thanks!

gbbaus_104974

Historic F5 Account

Mar 27, 2014

OK..

Maybe look at

Mitigating the THC SSL DoS Threat
http://devcentral.f5.com/weblogs/macvittie/archive/2011/10/28/f5-friday-mitigating-the-thc-ssl-dos-threat.aspx

and

SSL Renegotiation DOS attack – an iRule Countermeasure : 
https://devcentral.f5.com/articles/ssl-renegotiation-dos-attack-ndash-an-irule-countermeasure

and here

SSL Renegotiation, Execution Halting and HTTP Rewriting : 
https://devcentral.f5.com/articles/20-lines-or-less-49-ssl-renegotiation-execution-halting-and-http-rewriting

I am sure these might be able to assist

Angel_Lopez_116
Altostratus
Mar 28, 2014
Thanks, I'll have a look to all those links.
- Filip_Verlaeckt
  Historic F5 Account
  May 22, 2014
  Hello, I want to achieve the same thing as described ny Angel Lopez. The point is that I need to block client-to-BIGIP initiated renegotiations while allowing BIGIP-to-client initiated ones (these renegotiations are triggered by an iRule). Although the SSL reneg rate limiting iRule is a good solution it is not good enough for my usecase. Let me explain. Customer is using SSLlabs (https://www.ssllabs.com/ssltest/) to get a summary of the SSL security posture of their site. The use this result to help differentiate their service from competition. This test merely checks if the site allows ssl reneg. As the result is positive it marks this as a negative result. The way around would be to block these client initiated renegs but therefore I need to be able to differentiate.
Kevin_Stewart
Employee
May 23, 2014
It may be worth asking why SSL renegotiation is such a bad thing. The initial handshake of an SSL/TLS dialog is used to generate a session encryption key. The longer that key is used the easier it becomes to attack it, so semi-frequent renegotiations are actually a good idea. Now, there is an issue with regular SSL renegotiation, detailed in CVE-2009-3555, that would allow an attacker to insert data into an existing session. This vulnerability has been addressed with RFC 5746, and "secure renegotiation" is a native function of the F5 BIG-IP. I would certainly question whether or not the finding is specific to all SSL renegotiation, or just (insecure) pre-5746 SSL renegotiation.
nitass
Employee
May 26, 2014
In a SSL dialog between client and BigIP, there's a way to differentiate when the BigIP has initiated the negetotiation, and that's the "Hello Request" message sent from the BigIP when it's requesting the "Hello" from the client to start the new handshake, and that's what I thought I could manage from an iRule, but I guess I can't.

is CLIENTSSL_CLIENTHELLO event useful?

CLIENTSSL_CLIENTHELLO

https://devcentral.f5.com/wiki/iRules.CLIENTSSL_CLIENTHELLO.ashx
- Brett_Prucha
  Nimbostratus
  Jul 29, 2019
  I followed the iRule as described in:
  
  https://devcentral.f5.com/articles/ssl-renegotiation-dos-attack-ndash-an-irule-countermeasure
  
  Except I used the code in the CLIENTSSL_HANDSHAKE event in the CLIENTSSL_CLIENTHELLO event instead. Also instead of using the maxquery variable of 5 I set it to 1 and added an additional flag in the if condition that references that variable that I set when I request renegotiation on the server side. That ensures renegotiation only occurs when initiated by the server.
  
  I tested it using SSLyze --reneg and confirmed it blocked client side renegotiation.
  
  https://github.com/nabla-c0d3/sslyze
  - Brett_Prucha
    Nimbostratus
    Jul 29, 2019
    when CLIENT_ACCEPTED { set rand [expr { int(10000000 * rand()) }] } when CLIENTSSL_CLIENTHELLO { set reqno [table incr "reqs$rand"] table set -subtable "reqrate:$rand" $reqno "ignored" indefinite $static::seconds if { ![info exists server_renegotiate] and [table keys -count -subtable "reqrate:$rand"] > 1 } { after 5000 drop } } when CLIENT_CLOSED { table delete reqs$rand table delete –subtable reqrate:$rand –all }