Difficult real world ssl problem

Hi,

we encounter a strange ssl client behaviour on a high load web site. The
setup is as follows:

The webserver is Apache 1.3.26 with mod_ssl 2.8.10 and openssl 0.9.6e. It
has a VeriSign certificate with strong encryption enabled (GlobalID,
corrsponding to SGC in MSIE and Internal SteUp in Netscape) and the
hardware ist based on a Sun Solaris E420R, 4 CPUs and NCipher Crypto
accelerator. mod_ssl uses shmht-session cache. No Keep-Alive is used.

The whole site worked very good for more than a year. Then unfortunately
too many configurations were changed at the same time (Webserver config,
load-balancers, virtual hosts, firewalls).

Now we can see a lot of requests which are no longer able to negotiate
strong encryption. In fact, initially the browsers successfully connect and
some requests work, but suddenly we can see requests from the same clients
using weak encryption, which then is rejected by the web server config. All
cases are MSIE Browsers, but a lot of different versions and Windows
variants. It looks like browser upgrade to strong encryption helps, but
also "weak" browsers could use the site without problems because the
certificate has step-up ability coded in.

I describe one case as an example:

1) The first request of the client to the webserver gets the homepage. The
Request ist successful and uses 128Bit RC4-MD5. The answer is a frameset.
2) The Browser connects again to get the first of the two frames in the
frameset. It successfully resumes the SSL-Session.
3) The Browser connects again to get the second frame in the frameset. Now
the request is rejected and the logfile says the Client tried to use
EXP-RC4-MD5 40 Bit.

Using tcpdump/ssldump we can see the good requests 1) and 2) but for 3)
ssldump only outputs:
New TCP connection #3: (63867) <-> (443)
Version 2 Client.
3 1038388800.4248 (0.1196) S>C TCP FIN
3 1038388800.4273 (0.0024) C>S TCP FIN

although there are a lot of packets in the tcpdump capture file, and
verbose tcpdump with hexdump shows, that for instance in the packets are
strings from the certificate.

4) The Client goes on successfully using the ssl connection from 1) and 2).

Now the question is: Do you have any idea, why one request in the middle of
the sessions uses SSL Version 2?

Yours sincerely,

Rainer Jung


kippdata informationstechnologie GmbH
Bornheimer Straße 33a
D-53111 Bonn
Germany

Tel.: +49/228/98549-0
Fax: +49/228/98549-50
email: rainer.jung@kippdata.de

____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org