| Summary: | SSL fails in certain situations | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Knut-Håvard Aksnes <knut> |
| Component: | SSLIOP Pluggable Protocol | Assignee: | Ossama Othman <ossama.othman> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | ||
| Priority: | P3 | ||
| Version: | 1.3 | ||
| Hardware: | x86 | ||
| OS: | Windows NT | ||
| Bug Depends on: | |||
| Bug Blocks: | 1277 | ||
| Attachments: | Log with debug level 3 | ||
Created attachment 183 [details]
Log with debug level 3
The message to look for is: ACE_SSL (1276|340) error code: 336195711 - error:1409F07F:SSL routines:SSL3_WRIT E_PENDING:bad write retry This same problem is exhibited by TAO's `orbsvcs/tests/SSLIOP/Big_Request' test. After some quick/preliminary debugging, it appears that a full SSL record is not completely read prior to attempting a write on the same SSL stream. In particular, there is still some data pending in OpenSSL's internal buffers that must be processed/flushed before attempting a new read/write. This is necessary since SSL is a record-oriented protocol. I'm still not sure if this is a problem with the ACE_SSL_SOCK_Stream class or the TAO_SSLIOP_Transport class. I tend to think it is a problem with the former, but I'll run the issue by Steve Huston of Riverace and get his opinion. Fixed. Fri Mar 26 14:32:35 2004 Ossama Othman <ossama@dre.vanderbilt.edu> ... * orbsvcs/orbsvcs/SSLIOP/SSLIOP_Connection_Handler.cpp (open): By default, OpenSSL attempts to send the entire chunk of data. This is fine for relatively small chunks of data. However, if SSL_write() returns with an SSL_ERROR_WANT_WRITE (basically an EWOULDBLOCK) when using non-blocking I/O, TAO may attempt to resend the same data with a potentially different buffer address. Such a scenario is prone to happen when sending large chunks of data that cause flow control to occur. For most protocol implementations this is fine. OpenSSL, on the other hand, requires that the same arguments be passed to SSL_write() if an SSL_ERROR_WANT_WRITE error occured on a previous SSL_write() attempt, which cannot be guaranteed by TAO's current message queuing/construction code, often resulting in a "bad write retry" OpenSSL error. To work around this issue, we enable partial SSL_write()s in SSL/TLS connections created by TAO's SSLIOP pluggable protocol. Doing so makes SSL_write() behave like write(2). Note that this isn't an issue when using blocking I/O. This fixes the SSLIOP "Big_Request" test failure. [Bug 1429] ... |
A simplified version of one of our interfaces follows // Relevant parts of an old interface (don't blame me for the method signature) module ElWebSessionModule { struct MarketReport { string sTimestamp; string sDate; string sReport; }; interface ElWebSession { exception ErrorGettingInfo { string sReason; }; exception NotLoggedIn { string sReason; }; boolean // returns true if report available GetMarketReport(out MarketReport pMarketReport) raises(NotLoggedIn, ErrorGettingInfo); }; }; GetMarketReport is repeatedly polled when a report is available it is returned using the out variable. For small messages this works well for a sReport size of 52k everything is OK when sReport is 67k we get into trouble. a log file will be attached We use openssl-0.9.6g compiled with NO_IDEA to avoid patent issues.