KSSL session reuse bugs

[George Staikos]

On Wednesday 22 October 2003 04:54, Stefan Rompf wrote:
> >   I'm not surprised. :-)  Client certificates still don't work right in
> > general anyways.  I just don't have the time or motivation to fix it yet.
>
> Ok, then I'll work on fixing this. On the first step I'll commit the fix to
> tcpslavebase.cxx, KSSLCertificateHome optimization will follow during next
> two weeks. I prefer a process local certificate cache over KSSLD to avoid
> the additional turnaround time that would be needed for every SSL
> connection otherwise.

  We used to have this but we had to get rid of it due to synchronization 
issues (ca. KDE 2.2).  Too many slaves and apps concurrently accessing and 
modifying the database was a problem.

> > > b) When session reusage fails and a new session is created by class
> > > KSSL, it won't be saved.
> >
> >    Ouch, can you file a bug report against this one please?   I can try
> > to fix it over the next week or two.  Alternatively if you want to work
> > on and commit fixes to these things, feel free to.
>
> The reason is that KHTMLPart often forgets to set the ssl_session_id
> metadata field so the ID sent to the KIO slave is not updated. I tried to

   That's a bug on my part of course.

> change this yesterday and also implemented a cache that would fix problem
> c, however this did not help for IMG-links and http redirects as they are
> handled without enough KHTMLPart interaction.

   This is a more generic problem.  I think it goes to show that we need a 
slightly different approach for sessions.  Nevertheless, the current 
implementation certainly shows big performance improvements over KDE 3.1.  I 
think it's quite worthy in that respect. :)

> 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. :-)

> >    Does the book explicitly say if you have a session for server:port,
> > you can 
 use it for all other concurrent or subsequent connections to
> > server:port?
>
> Yes, the author is very clean about this, and also about using host and
> port as key on the client side. You can have multiple connections for a
> session, even in parallel, until the server decides the renegotiate. A
> client can also have multiple sessions to a server.

   Ok that's good to know.  Let's go ahead with this and move towards a better 
session id caching. Feel free to commit patches for this as you like.  I 
don't know when I'll have time to do it, though if I get time and I don't see 
anything done yet I'll hack something up.

> > There is one other bug.  I notice crashes if the user switches from SSLv2
> > to or from SSLv3 in the middle of a session.  Not too critical IMHO but
> > worth fixing one day.
>
> I try to reproduce this when I'm done with the stuff above.

   Yes it's really not critical.  Don't worry about it too much. :)

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