KSSL session reuse bugs

[Stefan Rompf]

Hi,

I've tracked down a number of bugs with SSL session reuse in KDE. I
don't present a complete fixes right now as I see need for additional
discussion.


a) Session reusage doesn't take client certificates into account

This one is quite hard to reproduce as konqueror is very conservative in
reusing sessions. It needs a html document that consist of two frames.
One frame must contain a link to reload the other frame.

When these pages are put on a server that requires client certificates
and the cached session times out, connections to the server will be
impossible until the complete page is reloaded. The error message on the
receivers' end is "error:140890C7:SSL
routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate".
This can be reproduced with apache by simply clearing the cache with a
server restart.

While reviewing TCPSlaveBase::doSSLHandShake() I found that openssl
requires setting up the client certificate even if the session can be
reused. So the code is a little "over-optimized" ;-) The following
change helps:

if (hasMetaData("ssl_session_id")) {
    ....
}
certificatePrompt();   <- Always setup client cert

However, this leads to more file parsing and also more certificate
prompting than before if the user does not select to save settings for
the host, and KSSLCertificateHome (used to retrieve certificates) is not
really optimized right now. There are some possibilities:

-The decoded client certificate could be sent as metaData() to the
application. I don't like this because of security implications
-certificatePrompt() caches the last certificate addressed by host:port
for some seconds. This should be good enough for most applications
-KSSLCertificateHome is optimized to cache certificates so that
certificatePrompt() runs faster. May be quite intrusive as KDE3.2 alpha
is out, but I'd prefer this


b) When session reusage fails and a new session is created by class
KSSL, it won't be saved.

I leave this someone who understands the KIO slaves better than I do
now. Again doSSLHandShake(), after connect the new session should be
saved. However, it does not work:

 kdDebug(7029) <<"saved session " <<d->kssl->session()->toString()
<<endl;
 setMetaData("ssl_session_id", d->kssl->session()->toString());
 kdDebug(7029) <<"stored session " <<metaData("ssl_session_id") <<endl;
 setMetaData("ssl_in_use", "TRUE");

shows "saved session <new session>" "stored session <expired session>"
on my system, so the new, working session is never saved and complete
negotiation has to take place on every connect. I have no idea why, may
be someone else can help.


c) Session reusage in konqueror is too conservative

According to SSL literature (*) one SSL session can be used by multiple
connections in parallel and therefore be adressed by "server:port".
Different to that, konqueror uses new sessions in most cases, but on the
good side this makes a) so hard to trigger ;-)

I think we should associate SSL sessions application-wide by
"server:port". From the technical side, KDE-wide should be possible,
too, but I wouldn't recommend that for security reasons.


d) Last but not least...

...there is a small dangling pointer bug at the end of
certificatePrompt(). Fixing that should not raise too much discussion.



Opinions on what should be fixed first/when and how?

Cheers, Stefan



(*) Eric Rescorla: SSL and TLS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 1691 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20031020/21fc10dc/attachment.bin>