Java Security

Hi,

we are running an application within a Tomcat 6.0.35 server on RHEL 5.7/i386 that queries our company's Active Directory using LDAP over SSL. One of the queries involves expanding a large distribution list. Since the upgrade from JDK 1.6.27 to 1.6.29 (or 1.6.30) the performance of this LDAP query has degraded dramatically, from about 8 seconds to more than 300 seconds. This only happens when encrypting the LDAP connection.

We are not sure how to debug this further. Which information would we need to provide to get to the root of this? I was thinking that perhaps the Tomcat output with the javax.net.debug=ssl,handshake property set for 1.6.27 and 1.6.29/30 would be sufficient?

With Java 1.6.29/30, the basic response/reply between the Tomcat and the AD server looks like:

TP-Processor11, WRITE: TLSv1 Application Data, length = 32
TP-Processor11, WRITE: TLSv1 Application Data, length = 160
Thread-270, READ: TLSv1 Application Data, length = 16368
Thread-270, READ: TLSv1 Application Data, length = 16368
Thread-270, READ: TLSv1 Application Data, length = 11920
TP-Processor11, WRITE: TLSv1 Application Data, length = 32
TP-Processor11, WRITE: TLSv1 Application Data, length = 160
Thread-270, READ: TLSv1 Application Data, length = 16368
Thread-270, READ: TLSv1 Application Data, length = 16368
Thread-270, READ: TLSv1 Application Data, length = 11920

When using Java 1.6.27, we see:

TP-Processor12, WRITE: TLSv1 Application Data, length = 208
Thread-42, READ: TLSv1 Application Data, length = 16368
Thread-42, READ: TLSv1 Application Data, length = 16368
Thread-42, READ: TLSv1 Application Data, length = 5696
TP-Processor12, WRITE: TLSv1 Application Data, length = 208
Thread-42, READ: TLSv1 Application Data, length = 16368
Thread-42, READ: TLSv1 Application Data, length = 16368
Thread-42, READ: TLSv1 Application Data, length = 5696

Looking at the 32 bytes long requests (with javax.net.debug=all set), we see:

Padded plaintext before ENCRYPTION: len = 32
0000: 30 0C C2 32 83 6E 9F D8 8F 5E E8 47 7A 0B 9A F1 0..2.n...^.Gz...
0010: 7D 44 78 0B 9E 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A .Dx.............
TP-Processor1, WRITE: TLSv1 Application Data, length = 32

Which doesn't make a whole lot of sense to us...

Any help debugging this further would be most welcome.

Cheers
Stefan