On Tue, 23 Jan 2001, Ben Laurie wrote:
> IIRC the client certificate is _not_ stored in the session (at least, it
> used not to be - Apache-SSL has to work around this in its own caching).
I believe it is ... when I wrote the shmcb cache I noticed that things
behaved very differently in client-authenticated setups. What was
happening is that I had a sanity check on the size of encoded sessions
that was actually clipping at a size slightly higher than an encoded
session with one test client-cert and slightly lower than those for
another test client-cert. Given that I'd not realised that the two certs
were in fact different this looked, for all money, "random". This was an
extremely humourous debugging experience for me, the humour of which is
too emotionally overwhelming for me to describe in detail right now.
<grin> (yes, I think I temporary exceeded the "hacker-horizon", a point at
which debugging spirals off into convoluted and obscure directions,
preventing you from returning to check for trivial stupid mistakes).
A "standard" (eg. RC4-SHA, 1024-bit RSA, no client-authentication) SSL
session typically encodes to around 130-150 bytes. Introduce
client-certificate authentication into the picture (with no cert-chains,
just a single CA-signed client cert for 1024-bit RSA) and the sessions can
go up around the 1K mark (the certificate components/fields can determine
the actual encoding length which is why I had a slight but disastrous
variance between two different test certs). Introduce client cert chains,
and ... well ... you get the picture. This is one of the reasons that it
is difficult to optimise a cache - your sessions may vary greatly in size,
and different SSL hosts (if sharing the same cache) may have big variances
in expiry times, etc. A R-PITA basically ... (R=='Royal' of course)
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
