KSSL session reuse bugs

[George Staikos]

On Wednesday 22 October 2003 15:14, Jason Keirstead wrote:
> > > Right now, I feel tempted to move SSL session handling to KIO::Job, so
> > > that we have only one transparent implementation for all applications.
> > > This is a real world benefit, our SMTP server at work f.e. uses TLS and
> > > client certificates to authorize relaying. I'll keep the list posted on
> > > the results.
> >
> >     This might be a good idea, but I'd like to see the implementation
> > first and also have David comment on it since he seems to always know the
> > best place for things in KIO. :-)
>
> I don't know how far OT this is, but I just want to jump in with my current
> SSL-related annoyance :P
>
> I am working on implementing SSL support for Kopete IRC, and have had to
> struggle with the poor implementation of KSSL re integration with
> KExtendedSocket  I was very surprised there wasn't a "KSecureSocket" or

  It predates KExtendedSocket, and it is in a library that is linked after 
kextendedsocket.  What do you expect?

> similar that just extended KExendedSocket with SSL capabilities. The

   There would be if someone wrote one, but it is not so simple.  See below.

> current KSSL just seems like a very lightweight wrapper around OpenSSL, in

   It's two layers around OpenSSL, one very lightweight, the other powerful 
but also fairly light in many respects.  This is important for I/O.  IRC may 
only transmit small amounts of data but a big expensive class for http 
requests is just not good.  I spent much time trying to optimize tcpslavebase 
and KSSL.

> that there are no usefull signals emitted from it when data is ready to be
> read, etc. I have my code almost working now, but it would have been much
> simpler and cleaner if I could have just dropped in a KSecureSocket and
> have it "just work".
>
> Just thought I would bring that up since you're talking about re-working
> stuff into KIO::Job, just that a lower-level solution at the socket layer
> itself is also needed IMO.

   This is where the problem arises.  In general with SSL, if you just "drop" 
something in and expect it to "just work", you will most likely end up with 
no security.  A class in kdecore can't contain and depend on complex dialogs, 
especially one that is not GUI related.   In this case it would need to have 
signals for all the different SSL events and conditions.  This requires at 
least 2 components now, assuming we were to make a second part for it to 
communicate with.  TCPSlaveBase is effectively the result of integrating SSL, 
a socket, and the application.  Have a look at how much code is in there and 
understand that it is by no means complete yet.

   As an alternative, there is the SSL I/O device in kdelibs/kio/kssl.  It is 
not yet complete nor is it fully integrated into KDE's SSL trust system.  It 
is basically functional though.  I think this is what you really wanted.  I 
am very hesitant to install the header and commit to SC/BC for 3.2 though.  

   If you want SSL support, you should consider the idea of an irc kioslave 
instead I think.  Then you can use tcpslavebase and your SSL setup is 
literally one function call.

   How did you implement the certificate database support?

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/