Unable to restrict InMemoryLDap server to restrict/respond to specific TLS versions
A Java-based LDAP API
Brought to you by:
dirmgr,
kennethleo
Hi,
I am trying to test different combinations of SSL/TLS clients against InmemoryLdap server with
We have tried somethig like this
With this piece of code if a client initiates a TLSv1.2 client LDAP session whereas it should get failed
Thanks,
Java implementations seem to do weird things with regard to the set of protocols that are enabled when you request an SSL context with support for a given protocol. In some VMs, like the Oracle and OpenJDK VMs, it doesn't seem to make much difference what protocol you specify because SSL sockets (and server sockets) that are created will support higher versions. On the other hand, the IBM VM seems to enable only the exact protocol version that you specify when creating the context, so if you specify a protocol version then you kind of have to know in advance what protocol your clients are going to use.
Java does provide the ability to explicitly specify which protocol version(s) you want to enable for a given SSLSocket or SSLServerSocket, but only after the socket is created but before negotiation is completed. The LDAP SDK already includes support to do this transparently for SSLSocket objects, so that if you specify a given protocol it will treat it as an upper bound, but may enable lower protocol versions if it makes sense to do so. However, the LDAP SDK didn't do this for SSLServerSockets. It was probably some combination of oversight and less need for this support for server sockets than for client sockets. But to address the problem, I went ahead and updated the SSLUtil class to do something similar for SSL server sockets. You should be able to use this now if you check out and build the code for yourself.
Note, however, that SSLv3 is insecure (you should generally use at least TLSv1, but TLSv1.1 and TLSv1.2 are better), and the SSLUtil class doesn't like using it by default. It is possible that the changes I just made won't have any noticeable effect if you specifically request SSLv3. If you want to explicitly configure the SSL protocols that you want to enable, you can use the SSLUtil.setEnabledSSLProtocols to explicitly set the SSL protocols that wil be enabled by default, and then use the SSLUtil.createSSLServerSocketFactory method that doesn't take any arguments, which should create server sockets with exactly that set of protocols.
Hi,
I have not yet pulled out the latest code changes
I tried with following piece of code
SSLUtil serverSSLUtil = createSSLUtil();
SSLUtil clientSSLUtil = createSSLUtil();
serverSSLUtil.setDefaultSSLProtocol("TLSv1.2");
serverSSLUtil.setEnabledSSLProtocols(Arrays.asList("TLSv1.2"));
SSLSocketFactory socketFactory = serverSSLUtil.createSSLSocketFactory();
SSLServerSocketFactory serverSocketFactory = serverSSLUtil.createSSLServerSocketFactory();
InMemoryListenerConfig lConfig = InMemoryListenerConfig.createLDAPSConfig(
"ssl listener",
InetAddress.getLocalHost(), PORT, serverSocketFactory, socketFactory);
The debug logs shows that a TLS Client Hello 1.1 is coming in, Server should have sent a reject since it expects minimum TLSv1.2
But it does not behave that way
Am i Missing something
LDAPListener client connection reader for connection from 10.78.228.74:53573 to 10.78.228.74:34343, READ: TLSv1.1 Handshake, length = 163
ClientHello, TLSv1.1
RandomCookie: GMT: 1465240722 bytes = { 148, 66, 7, 111, 238, 81, 207, 112, 96, 170, 81, 214, 33, 151, 109, 167, 176, 181, 181, 8, 136, 4, 182, 164, 89, 0, 67, 206 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
[read] MD5 and SHA1 hashes: len = 163
0000: 01 00 00 9F 03 02 57 56 CD 92 94 42 07 6F EE 51 ......WV...B.o.Q
0010: CF 70 60 AA 51 D6 21 97 6D A7 B0 B5 B5 08 88 04 .p`.Q.!.m.......
0020: B6 A4 59 00 43 CE 00 00 38 C0 0A C0 14 00 35 C0 ..Y.C...8.....5.
0030: 05 C0 0F 00 39 00 38 C0 09 C0 13 00 2F C0 04 C0 ....9.8...../...
0040: 0E 00 33 00 32 C0 08 C0 12 00 0A C0 03 C0 0D 00 ..3.2...........
0050: 16 00 13 C0 07 C0 11 00 05 C0 02 C0 0C 00 04 00 ................
0060: FF 01 00 00 3E 00 0A 00 34 00 32 00 17 00 01 00 ....>...4.2.....
0070: 03 00 13 00 15 00 06 00 07 00 09 00 0A 00 18 00 ................
0080: 0B 00 0C 00 19 00 0D 00 0E 00 0F 00 10 00 11 00 ................
0090: 02 00 12 00 04 00 05 00 14 00 08 00 16 00 0B 00 ................
00A0: 02 01 00 ...
%% Initialized: [Session-1, SSL_NULL_WITH_NULL_NULL]
%% Negotiating: [Session-1, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
ServerHello, TLSv1.1
RandomCookie: GMT: 1465240722 bytes = { 46, 82, 241, 160, 143, 185, 163, 0, 164, 12, 109, 212, 60, 248, 32, 168, 25, 177, 224, 179, 66, 181, 38, 147, 37, 224, 214, 166 }
Session ID: {87, 86, 205, 146, 61, 138, 92, 230, 34, 129, 20, 248, 44, 209, 142, 104, 93, 22, 239, 2, 57, 114, 226, 100, 10, 82, 47, 191, 219, 30, 107, 160}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
Cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=xxx
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 1024 bits
modulus: 125560734468034281413597454819001154923263208715562871420714927711117542622577424695371700467041261741852148338044588626061095229485772949881406493267257167272147516013304316018607559237128353189708683481585843514724776123346452913382609184820816635021490820257502177452139018220785665866589917853611516656361
public exponent: 65537
Validity: [From: Wed Mar 09 01:47:31 IST 2016,
To: Thu Mar 09 01:47:31 IST 2017]
Issuer: CN=xxxx
SerialNumber: [ 56df3356]
]
Algorithm: [SHA256withRSA]
Signature:
You'll need to get the latest set of changes for calls to SSLUtil.setEnabledSSLProtocols to have any effect on the creation of server sockets.
When we give TLS we can then have all TLS versions enabled?
As I mentioned before, you'll need to check out and build the LDAP SDK for yourself to get the ability to control the protocols for server socket factories.
By default, SSLUtil will only try to use TLSv1, TLSv1.1, and TLSv1.2. It will try to use the highest protocol that is available, but will also support the lower protocols for greater compatibility. If you explicitly request TLSv1.2, then it will also support TLSv1.1 and TLSv1. If you explicitly request TLSv1.1, then it will also support TLSv1 but not TLSv1.2, and if you explicitly request TLSv1 then that is the only version that it will support.
If you want to do something different than that, then you'll have to explictly configure it with the
SSLUtil.setEnabledSSLProtocols
method. Restricting it to only support TLSv1.2 but not TLSv1.1 or TLSv1 falls into this category. Here is a simple example that demonstrates how to do that: