Bug 1429 - SSL fails in certain situations
Summary: SSL fails in certain situations
Status: RESOLVED FIXED
Alias: None
Product: TAO
Classification: Unclassified
Component: SSLIOP Pluggable Protocol (show other bugs)
Version: 1.3
Hardware: x86 Windows NT
: P3 blocker
Assignee: Ossama Othman
URL:
Depends on:
Blocks: 1277
  Show dependency tree
 
Reported: 2003-01-22 08:51 CST by Knut-Håvard Aksnes
Modified: 2004-03-26 16:37 CST (History)
0 users

See Also:

Attachments
Log with debug level 3 (8.74 KB, text/plain)
2003-01-22 08:54 CST, Knut-Håvard Aksnes 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Knut-Håvard Aksnes 2003-01-22 08:51:46 CST 
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.
Comment 1 Knut-Håvard Aksnes 2003-01-22 08:54:45 CST 
Created attachment 183 [details]
Log with debug level 3
Comment 2 Knut-Håvard Aksnes 2003-01-22 09:00:05 CST 
The message to look for is: 

ACE_SSL (1276|340) error code: 336195711 - error:1409F07F:SSL routines:SSL3_WRIT
E_PENDING:bad write retry
Comment 3 Ossama Othman 2003-01-22 10:28:36 CST 
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.
Comment 4 Ossama Othman 2004-03-26 16:37:42 CST 
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]
...