EldoS | Feel safer!

Software components for data protection, secure storage and transfer

RenegotiationAttackPreventionMode of rapmStrict - Indy HTTPS

Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages
#32082
Posted: 02/03/2015 10:26:42
by Darian Miller (Standard support level)
Joined: 06/27/2011
Posts: 48

In regards to preventing TLS renegotiation (https://www.eldos.com/security/articles/6437.php) I have set the IOHandler's RenegotiationAttackPreventionMode property to rapmStrict however SSLLabs is still reporting vulnerabilities.

The article states that "Attack prevention features are turned on. If the remote side does not support them, the connection will be terminated (client-side components), or cipher renegotiation features will be prohibited (server-side components)."

Does this setting apply to server side Indy base IOHandlers? It appears to be supported.

The new OnRenegotiationStart only applies to the TElSSLServer and not to the Indy HTTP server, but this shouldn't be needed if rapmStrict is set, correct?
#32084
Posted: 02/03/2015 10:53:20
by Ken Ivanov (EldoS Corp.)

Hi Darian,

Thank you for contacting us.

By setting RenegotiationAttackPreventionMode to rapmStrict you are enforcing safe renegotiation, so no renegotiation attack is possible. I am afraid we are not aware what criteria SSLLabs use to make assumptions about vulnerabilities. Is there any further information provided in their report?

In fact, I have an assumption about what might be causing it. Could you please try to set the IOHandler.Extensions.RenegotiationInfo.UseSignalingCipherSuite to true and check if it changes anything in the SSLLabs report?

Ken
#32089
Posted: 02/03/2015 12:47:22
by Darian Miller (Standard support level)
Joined: 06/27/2011
Posts: 48

I'll try the suggestion and report back more details, thanks!
#32090
Posted: 02/03/2015 13:04:56
by Darian Miller (Standard support level)
Joined: 06/27/2011
Posts: 48

That appears to be supported in Indy9 not Indy10
Extensions are in SBIndySSLServerIOHandler.pas but not SBIndyServerIOHandler10.pas

(If I remember right, the units with 10 suffix are for Indy10 and the other is for Indy9?)
#32091
Posted: 02/03/2015 14:24:19
by Ken Ivanov (EldoS Corp.)

Darian,

Right, so you were actually talking about the server-side IOHandler, not about the client-side one? As you were asking about the RenegotiationAttackPreventionMode property I concluded that you were asking about the client-side component. Sorry.

The RenegotiationAttackPreventionMode is only applicable to the client-side components. There are no benefits from tuning it on the server side, it does not affect the server-side protocol flow in any way.

Proper handling of renegotiation requests on the server side involves implementing a handler for the OnRenegotiationStart event. The Safe parameter passed down to the event handler indicates whether the renegotiation is 'safe' from the renegotiation attack viewpoint. It is up to the handling code to choose whether or not to proceed with such renegotiation. Returning Allow = false from the event handler instructs the component to terminate the renegotiation procedure.

Ken
#32092
Posted: 02/03/2015 14:29:36
by Darian Miller (Standard support level)
Joined: 06/27/2011
Posts: 48

Well, no wonder that property didn't do anything! : )

Since proper handling of renegotiation requests on the server side involves implementing a handler for the OnRenegotiationStart event... how should this be done when using the Indy IO Handlers as that event is not available?
#32093
Posted: 02/03/2015 14:30:38
by Darian Miller (Standard support level)
Joined: 06/27/2011
Posts: 48

And if it doesn't apply to the server side, why is there a RenegotiationAttackPreventionMode property in SBIndyServerIOHandler10?
#32094
Posted: 02/03/2015 14:46:22
by Ken Ivanov (EldoS Corp.)

Quote
Since proper handling of renegotiation requests on the server side involves implementing a handler for the OnRenegotiationStart event... how should this be done when using the Indy IO Handlers as that event is not available?

Hmm, I wonder why it isn't... The event should definitely be there. We'll check that out and get back to you shortly. It might be that the event was accidentally missed when extending the interface of the IOHandler with newer features.

Quote
And if it doesn't apply to the server side, why is there a RenegotiationAttackPreventionMode property in SBIndyServerIOHandler10?

The server 'connection instance' IOHandler component is inherited from the client 'connection instance' IOHandler component, following the specifics of the Indy architecture. That's why certain 'unnatural' client-side features are also available in the server component. We could probably move those to the 'protected' section in the derived server component. Will check what we can do in this regard.

Thank you for pointing us at the issues.

Ken
#32120
Posted: 02/05/2015 13:21:15
by Darian Miller (Standard support level)
Joined: 06/27/2011
Posts: 48

Any luck at options to secure the server side Indy IO handlers against this vulnerability?
#32123
Posted: 02/06/2015 05:12:20
by Ken Ivanov (EldoS Corp.)

Hi Darian,

Sorry for the delay. I have created a Helpdesk ticket for you where I will post the updated IO handler units shortly.

Please handle the OnRenegotiationStart event of the update handler as I described above and check if it makes the SSLLabs tool happy.

Ken
Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.

Reply

Statistics

Topic viewed 832 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!