RE: Closing a secure channel

[Bruce McHaffie <br...@entrust.com>]

Hi Fred, very sorry for not replying sooner. I bought a dog and then went on
vacation, and then went to the JavaOne conference. :-)
 
A1. Yes, I am using a different (not OpenSSL) library for this. I had to
write an adapter layer to match your API.
 
A2. Let me describe my application first: In my scenario the Axis client is
being called by a multithreaded application. libaxis_cpp.so gets loaded once
at startup, then multiple call objects are instantiated simultaneously on
different threads (all pointing to the same web service). If the target
protocol is https, then each call object loads my SSL channel module, which
in effect is only loaded once, and passes in the socket it wants protected.
Then the call objects start writing to and reading from their respective
sockets.
 
So, I guess what you say to avoid ("do not try to have simultaneous SSL
communication on different threads") is exactly what I am doing :-(. But
unlike OpenSSL, the SSL library I am using (from Entrust) does support
multithreading. Am I right in thinking that the Axis client (and the Axis2
transport layer) supports multithreading against a single web service? If it
does, then shouldn't I be able to use a threadsafe SSL library to set up
multiple simultaneous SSL connections? Or am I just inviting problems with
this design?
 
As for the pool -- the issue for me was that when the call object passes
data to the SSL library (or reads data from it), I need to know which
instance is making the call. It would be nice if I could rely on the socket
descriptor, but that is not passed in the call to SSLRead (or
closeSSLChannel for that matter). So my workaround is to keep a list of
thread IDs and open sockets in my SSL library. When a thread comes in to
read or write I use the thread ID to fish out the correct socket descriptor.
This list of socket descriptors indexed by thread IDs is what I call the
"pool". Probably not a good term for it.
 
As an aside I actually started out nailing up a single SSL connection and
synchronizing access to it, but ran into problems with the Apache connector,
which seemed unable to keep both sides of its connection (one to the client
and one to the app server) alive.
 
Also the socket==0 idea didn't work because the pSock variable I was holding
onto gets released when the call is destroyed. Instead I changed the
destructor of the SecureChannel class to close the channel.
 
Bruce.
 
 
 
 

-----Original Message-----
From: Fred Preston [mailto:PRESTONF@uk.ibm.com] 
Sent: June 22, 2005 6:23 AM
To: Apache AXIS C User List
Subject: RE: Closing a secure channel



Hi Bruce, 
        Just reading your email.  I'm having difficulty trying to get my
head around your solution...  I was wondering if you could explain in more
detail the following bits:- 

'my SSL library' 
Q1. Do you have your own SSLLibrary (i.e. different from OpenSSL?) 

'socket == 0 on all existing connection objects (which I keep in a pool)' 
Q2. To have access to the socket (m_Sock) you need to have added code in
channel.cpp/SecureChannel.cpp.  In the base code, there can only be one
socket open per instance of the channel object.  Every time that
Axis2Transport::flushOutput() is called, the open() method will be called in
the channel instance (normal or secure).  SecureChannel::open() ends up
calling Channel::open() that will close down the previously open socket
before creating a new socket of the appropriate type.  Thus there is no need
to keep a pool of sockets for a channel, because only one will ever be
active. (Where are you keeping the 'pool' and what are connection objects?)
If you have more than one web service active then you can have multiple
instances of a channel object.  Each object will have its own active socket.
In this case you will have multiple active sockets.  I believe that OpenSSL
is not multi-threaded and requires mutexes.  These have not been used on
Axis2 so you will have to be careful that you do not try to have
simultaneous SSL communication on different threads as this may lead to
unexpected behaviour. 

Regards,

Fred Preston.




	Bruce McHaffie <br...@entrust.com> 


06/20/2005 03:38 PM 
Please respond to "Apache AXIS C User List" 

        
        To:        "'Apache AXIS C User List'" <ax...@ws.apache.org> 
        cc:         
        Subject:        RE: Closing a secure channel 

       


Thanks Fred. I will fix up the destructor. My original problem was that my
SSL library didn't get notified when the channel closed a socket. I'm
working around that now by testing for socket == 0 on all existing
connection objects (which I keep in a pool) whenever openSSLConnection()
gets called. It's not pretty, but seems to work so far. If you can think of
a reason why this would fail embarassingly please let me know :-). 
  
Bruce. 
  
-----Original Message-----
From: Fred Preston [mailto:PRESTONF@uk.ibm.com] 
Sent: June 17, 2005 6:23 AM
To: Apache AXIS C User List
Subject: RE: Closing a secure channel


Hi Bruce, 
       You're right.  Axis2 SSL was a bit of a mess and that's why it was
dropped.  It works, but is untidy and unfinished.  Looking at the
Axis2Transport code, the currently loaded channel will be deleted (and it's
destructor called) when the Axis2Transport is deleted (i.e when the web
service is deleted).  The openConnection and closeConnection do very little
in Axis2Transport and unfortunately do not communicate with the underlying
channel.  I was hoping that there might be a 'back door' to getting the
channel object and then be able to call methods on it, but there is not... 

Just to recap, all of the channel close socket communication happens on the
destructor (as it does in channel::~Channel()).  This is missing from the
SSL channel.  Thus, when the web service is deleted, the Axis2Transport will
delete the currently active channel (before being deleted itself).  This
will call the channel destructor and if it is an SSL channel nothing happens
because the destructor is empty.  This will leave the SSL library open
causing memory leaks. 

The only solution to your problem is, if you have the OpenSSLChannel
project, add 'closeSecureSocket();' to the empty destructor method and
rebuild. 

Regards,

Fred Preston.



	Bruce McHaffie <br...@entrust.com> 


06/16/2005 04:24 PM 
Please respond to "Apache AXIS C User List" 

        
       To:        "'Apache AXIS C User List'" <ax...@ws.apache.org> 
       cc:         
       Subject:        RE: Closing a secure channel 

      



Hi Fred, thanks for the reply. That would work, except the destructor for
the secure channel object (derived from Channel) is empty too. So when the
channel object is destroyed in the transport destructor, the secure channel
destructor gets called but doesn't do anything. So closeSSLChannel() doesn't
get called when the transport object disappears. Neither does
destroySSLChannelObject(), which is a shame because it would give my SSL
library a chance to clean up after itself. In fact I'm not sure the SSL
library gets unloaded at all. Or again, maybe I'm missing something. 

Bruce. 
 
PS: I'm looking at 1.5 now, but for this release I'm stuck with 1.4. 
 
-----Original Message-----
From: Fred Preston [mailto:PRESTONF@uk.ibm.com] 
Sent: June 16, 2005 6:08 AM
To: Apache AXIS C User List
Subject: Re: Closing a secure channel


Hi Bruce, 
      You should now be using AXIS3 transport.  The reason why the method is
empty is because the socket was not closed until you deleted the web service
which in turn would call the destructor on the transport object, closing and
then deleting the channel object. 

Regards,

Fred Preston.


	Bruce McHaffie <br...@entrust.com> 


06/15/2005 08:30 PM 
Please respond to "Apache AXIS C User List" 

        
      To:        "'Apache AXIS C User List'" <ax...@ws.apache.org> 
      cc:         
      Subject:        Closing a secure channel 

     




A 1.4 question for you: in axis2/SecureChannel.cpp the close() method
doesn't do anything. Shouldn't it at least close the connection that is
opened in the open() method? For instance: 

void SecureChannel::close() 
{ 
     m_pSSLChannel->closeSSLChannel() 
} 


Or am I missing something here? 


Thanks, 


Bruce.