EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Problem with Indy sample program

Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.
#22820
Posted: 12/14/2012 12:23:59
by Remy Lebeau (Basic support level)
Joined: 12/14/2012
Posts: 1

Quote
Eugene Mayevski wrote:
Damned indy with its overcomplicated design sometimes outsmarts itself. The problem is with SSL alerts and particular usage scenario - the application polls for data, and if *at this moment* *only an SSL alert* is present in the spool buffer, the alert is consumed by the IOHandler itself, and Indy thinks that if it received 0 bytes, then it should close connection. We have to add a workaround for this particular case. Hope to give you something on monday (maybe we manage to fix it even tomorrow).


I am on the Indy development team. What is the actual problem with the way Indy handles SSL alerts?

Indy is not the one consuming the alerts directly, the underlying SSL provider is, whether that be OpenSSL, Eldos SecureBlackbox, Microsoft CryptoAPI, etc. When Indy asks an IOHandler for data, there are only 3 possible outcomes that Indy is expecting:

1) If an error occurs, < 0 bytes must be returned, then Indy prompts the IOHandler to perform further error handling and will close the connection if the IOHAndler does not raise an exception.

2) If a graceful disconnect occurs (or in the case of file/stream IOHandlers, if EOF is reached), 0 bytes must be returned with no exception raised. This signals Indy to close the connection immediately.

3) Application data is returned and placed in the IOHandler's InputBuffer for consumption.

Indy's IOHandler framework is designed to work this way regardless of whether SSL is used or not. This keeps the interface simplier and centralized so core code does not have to account for higher-level differences between SSL and non-SSL connections (we did that in the earlier days, and it didn't work out so well). The individual IOHandler implementations handle the dirty protocol details and then let the rest of Indy know what the final outcome is.

An SSL 'close' alert signals a graceful disconnect so 0 bytes must be returned. Any other SSL alert signals a communication error that must be reported to Indy. Indy's native OpenSSL IOHandler is implemented to work this way, because the OpenSSL API provides different error codes for those conditions that the OpenSSL IOHandler can look for and act accordingly.

If Eldos's SSL IOHandler is not implemented to work this way, then that is a bug on Eldos's part by breaking Indy's interface contract. However, I am curious to know what "workaround" Eldos ended up implementing to solve this problem so Indy would operate correctly.
#22821
Posted: 12/14/2012 12:35:54
by Eugene Mayevski (EldoS Corp.)

That's a problem with indy breaking everything between builds. We've added a workaround for that issue and I have no intention to discuss it further. Sorry, Remy.


Sincerely yours
Eugene Mayevski

Reply

Statistics

Topic viewed 3157 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!