axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Preston <PREST...@uk.ibm.com>
Subject Fw: Closing a secure channel
Date Fri, 05 Aug 2005 12:44:20 GMT
Hi Bruce,
        Using your own SSL puts your problem too far out of scope for me 
to really know what is going on and to be able to provide useful support. 
It sounds like you are doing the right sort of things, but as I do not 
have your environment or bespoke transport/channel code I feel that there 
is not a lot more I can help you with at this time...

Best regards,

Fred Preston.





Bruce McHaffie <bruce.mchaffie@entrust.com>
07/25/2005 06:23 PM
Please respond to "Apache AXIS C User List"
 
        To:     "'Apache AXIS C User List'" <axis-c-user@ws.apache.org>
        cc: 
        Subject:        RE: Closing a secure channel

 

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 <bruce.mchaffie@entrust.com> 
06/20/2005 03:38 PM 
Please respond to "Apache AXIS C User List" 
        
        To:        "'Apache AXIS C User List'" <axis-c-user@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 <bruce.mchaffie@entrust.com> 
06/16/2005 04:24 PM 
Please respond to "Apache AXIS C User List" 
        
       To:        "'Apache AXIS C User List'" <axis-c-user@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 <bruce.mchaffie@entrust.com> 
06/15/2005 08:30 PM 
Please respond to "Apache AXIS C User List" 
        
      To:        "'Apache AXIS C User List'" <axis-c-user@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. 

Mime
View raw message