WebLogic, dramatic reduction of TLS sessions creation by rejectClientInitiatedRenegotiation

why the TLS Sessions are constantly invalidated, removed from cache and recreated, discovering that it's WLS SSLConfigUtils.configureClientInitSecureRenegotiation() who initiates this:

at sun.security.ssl.SSLSessionContextImpl.remove(SSLSessionContextImpl.java:132)

at sun.security.ssl.SSLSessionImpl.invalidate(SSLSessionImpl.java:673)

at weblogic.socket.utils.SSLConfigUtils.configureClientInitSecureRenegotiation(SSLConfigUtils.java:27)

at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:135)

at weblogic.socket.JSSEFilterImpl.isMessageComplete(JSSEFilterImpl.java:354)

at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:976)

at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:917)

at weblogic.socket.NIOSocketMuxer.process(NIOSocketMuxer.java:599)

at weblogic.socket.NIOSocketMuxer.processSockets(NIOSocketMuxer.java:563)

at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30)

at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43)

at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147)

at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119)

the code responsible is:

public static void configureClientInitSecureRenegotiation(SSLEngine sslEngine, boolean clientInitSecureRenegotiation)

 {

   if (!IS_JDK_CLIENT_INIT_SECURE_RENEGOTIATION_PROPERTY_SET)

   {

     if ((sslEngine != null) && (!sslEngine.getUseClientMode()))

     {

       if (!clientInitSecureRenegotiation) {

         sslEngine.getSession().invalidate();

       }

       sslEngine.setEnableSessionCreation(clientInitSecureRenegotiation);

       if (isLoggable()) {

         SocketLogger.logDebug(clientInitSecureRenegotiation ? "Enabled" : "Disabled TLS client initiated secure renegotiation.");

       }

     }

   }

   else if (isLoggable()) {

     SocketLogger.logDebug("TLS client initiated secure renegotiation setting is configured with -Djdk.tls.rejectClientInitiatedRenegotiation");

   }

 }

so the invalidate() is called only if !clientInitSecureRenegotiation , but it appears that clientInitSecureRenegotiation=isClientInitSecureRenegotiationAccepted is always FALSE





in JSSESocketFactory:

  JSSEFilterImpl getJSSEFilterImpl(Socket connectedSocket, String host, int port)

    throws IOException

  {

    SSLEngine sslEngine = getSSLEngine(host, port);

    return new JSSEFilterImpl(connectedSocket, sslEngine, true);

  }

in JSSEFilterImpl:

public JSSEFilterImpl(Socket sock, SSLEngine engine, boolean clientMode)

    throws IOException

  {

    this(sock, engine, clientMode, false);  // parameter 4 is isClientInitSecureRenegotiationAccepted, THIS IS ALWAYS FALSE, and clientMode is always TRUE

  }

   

  public JSSEFilterImpl(Socket sock, SSLEngine engine, boolean clientMode, boolean isClientInitSecureRenegotiationAccepted)  // this constructor is ultimately invoked

    throws IOException

  {

so the only way to avoid session invalidation is by having IS_JDK_CLIENT_INIT_SECURE_RENEGOTIATION_PROPERTY_SET=false, that is by setting -Djdk.tls.rejectClientInitiatedRenegotiation=false (true or false doesn't seem to matter, as long as the variable is set)


Thanks to Carlo for the excellent analysis.

No suitable client certificate could be found - continuing without client authentication

"No suitable client certificate could be found - continuing without client authentication"

1) are you specifying the password for the keystore?

2) are you providing a full certificate chain ? ( chain [0] , chain [1], chain [2] until the Root CA)

3) server specified issuers different from the one of the client certificate?

4) server specified ciphers not matching the one of the certificate?

5) (this is same as 2) whole certificate chain not in keystore (see https://stackoverflow.com/questions/9299133/why-doesnt-java-send-the-client-certificate-during-ssl-handshake )



Here the code https://github.com/frohoff/jdk8u-jdk/blob/master/src/share/classes/sun/security/ssl/ClientHandshaker.java , as you see it's totally pathetic and at the same message correspond completely different scenarios.

Java SSL server and client

https://www.baeldung.com/java-ssl-handshake-failures

this article is inspiring but it contains several errors/omissions.

The actually working code with detailed keytool commands is here https://github.com/vernetto/ssltests



Ultimate resource to learn SSL handshake is https://tls.ulfheim.net/

SSL renegotiation and resumption

"Resumption and renegotiation are rather opposites. Resumption restarts a previous TLS session in a new TCP connection, using the same TLS parameters. Renegotiation continues an existing TLS session in the same TCP connection, but changes some of the parameters.
"


in Fiddler, check for the renegotiation_info field in the CONNECT requestsmethods


https://www.ssllabs.com/ssltest/


Secure Renegotiation Supported
Secure Client-Initiated Renegotiation Yes
Insecure Client-Initiated Renegotiation No

Session resumption (caching) Yes
Session resumption (tickets) No


check DisableRenegoOnClient link


https://www.salt.ky/disabling-tlsssl-renegotiation-in-configuration-manager-2012/ and https://support.microsoft.com/en-us/help/977377/microsoft-security-advisory-vulnerability-in-tls-ssl-could-allow-spoof

"Modify the key to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\DisableRenegoOnClient | DWORD=0"



https://backstage.forgerock.com/knowledge/kb/article/a28022128 -Djdk.tls.rejectClientInitiatedRenegotiation=true


-Dsun.security.ssl.allowUnsafeRenegotiation=true ( see https://www.oracle.com/technetwork/java/javase/tlsreadme2-176330.html on why this is a bad idea)

Doc on Session Resumption https://spacehost.de/tls-session-resumption-caching-tickets/

jdk.tls.useExtendedMasterSecret=false
jdk.tls.allowLegacyResumption=true
jdk.tls.allowLegacyMasterSecret=true


Here more explanation on Resumption and Renegotiation



To understand JSSE in general read this guide https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html

ClientHello and ServerHello

When you enable -Dssl.debug=true -Djavax.net.debug=ssl -Dweblogic.log.StdoutSeverity=Debug you get a lot of cryptic information in the logs
This document http://www.cisco.com/c/en/us/support/docs/security-vpn/secure-socket-layer-ssl/116181-technote-product-00.html explains quite well the SSL exchange protocol.


http://security.stackexchange.com/questions/19473/understanding-2048-bit-ssl-and-256-bit-encryption

this is a sample ClientHello:

*** ClientHello, TLSv1
RandomCookie:  GMT: 1454428615 bytes = { 69, 83, 231, 161, 89, 17, 57, 52, 161, 204, 30, 120, 164, 155, 109, 48, 216, 11, 123, 111, 55, 22, 86, 64, 123, 128, 64, 180 }
Session ID:  {}
Cipher Suites: [TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension server_name, server_name: [host_name: ldap.pippo.net]
***
[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)', WRITE: TLSv1 Handshake, length = 94
[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)', READ: TLSv1 Handshake, length = 3726

this is a sample ServerHello:

*** ServerHello, TLSv1
RandomCookie:  GMT: 1454428615 bytes = { 173, 6, 9, 133, 26, 24, 40, 154, 88, 2, 88, 175, 59, 169, 225, 31, 240, 132, 194, 100, 230, 48, 159, 177, 56, 91, 246, 67 }
Session ID:  {49, 77, 200, 173, 221, 205, 188, 24, 24, 109, 151, 39, 90, 35, 26, 224, 39, 31, 102, 10, 125, 130, 207, 170, 124, 33, 67, 152, 53, 80, 6, 204}
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: 
***
%% Initialized:  [Session-1, TLS_RSA_WITH_AES_256_CBC_SHA]
** TLS_RSA_WITH_AES_256_CBC_SHA
*** Certificate chain
chain [0] = [
[
  Version: V3

...... details about certificate chain


]
***
*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities:


*** ServerHelloDone

TLS v1.2 support in Java 6

According to Oracle Doc:
JDK 6 release supports TLS v1. See:
http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
JDK 6 supports TLS 1.1 as well since JDK 6u111.
http://www.oracle.com/technetwork/java/javase/overview-156328.html#R160_111
JDK 7 release supports TLS v1, TLS v1.1 and TLS v1.2. See:
https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider

In fact, TLS 1.2 is available in Java 6: "TLS v1.2 is now a TLS protocol option with the release of JDK 6u121" or maybe even in 6u115 b32 (copy and paste issue?)
http://www.oracle.com/technetwork/java/javase/overview-156328.html
enabled with -Djdk.tls.client.protocols="TLSv1.2"

To test if you have TLSv1.2 support:

public class TLSTest  {
        public static void main(String[] args) throws Exception {
                System.out.println("before TLSv1.1");
                SSLContext ctx = SSLContext.getInstance("TLSv1.1");
                System.out.println("before TLSv1.2");
                ctx = SSLContext.getInstance("TLSv1.2");
                System.out.println("after");
        }

}

and run with
java -Djdk.tls.client.protocols="TLSv1.1,TLSv1.2" TLSTest

if you get "Exception in thread "main" java.security.NoSuchAlgorithmException: TLSv1.2 SSLContext not available" then you are screwed.

which Cipher Suites your JVM supports

"SunJSSE supports a large number of ciphersuites" http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
1) WLS 11g (WLS 10.3.6) uses JSSE and runs on Java SE 6
2) JSSE java 6  http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
3) WLS 10.3.6 ciphers: http://docs.oracle.com/cd/E28280_01/web.1111/e13707/ssl.htm#BABBDACC

The classification of the different bits (TLS_DHE_RSA_WITH_AES_128_CBC_SHA) is as follows:
TLS vs SSL
RSA vs ECDH vs ECDHE vs DHE vs KRB5
ECDSA vs RSA
RC4 vs 3DES vs DES vs AES
EDE vs CBC
SHA vs MD5

Set "-Dssl.debug=true -Djavax.net.debug=ssl -Dweblogic.log.StdoutSeverity=Debug" then search for the statement
SSLEngine.setEnabledCipherSuites
to see which Ciphers are actually ENABLED (not only supported).
See also http://stackoverflow.com/questions/10487962/java-cipher-suites
There is a property https.cipherSuites , and a SSLSocket.setEnabledCipherSuites()/SSLEngine.setEnabledCipherSuites() method.
See also MOS document "How to Verify the Sun JSSE Cipher Suites Available to WebLogic Server (11g/12c) (Doc ID 2052237.1)"
suggesting to enable these flags

 -Dweblogic.debug.DebugSecuritySSL=true
 -Djavax.net.SSL=true
 -Djava.debug=SSL
 -Djavax.net.debug=all
 -Dssl.debug=true
 -Dweblogic.StdoutDebugEnabled=true
 -Dweblogic.log.LogSeverity=Debug
 -Dweblogic.log.LoggerSeverity=Debug

SSL TLS renegotiation, RFC 5746

Generalities:
https://devcentral.f5.com/articles/ssl-profiles-part-6-ssl-renegotiation

Oracle technical details on the famous RFC 5746, here the mythical JSEE Ref Guide (something every human should read) :
http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#tlsRenegotiation

More explanations
http://security.stackexchange.com/a/24569/118343



Other tags: no_renegotiation handshake_failure

javax.net.ssl.SSLHandshakeException: Server chose unsupported or disabled protocol: SSLv3

If you get this error message "javax.net.ssl.SSLHandshakeException: Server chose unsupported or disabled protocol: SSLv3",
chances are that your JVM, for vulnerability issues connected to SSLv3, is configured to disable this protocol.
If you REALLY need to support SSLv3, check which file you are using for -Djava.security.properties=/path/to/yourfile, then edit yourfile and make sure your property:
jdk.tls.disabledAlgorithms=SSLv3, DH keySize < 768
doesn't contain SSLv3 (make it jdk.tls.disabledAlgorithms=DH keySize < 768)

WebLogic supported Cyphers

The list of the possible strong cyphers not that long:

AES256-GCM-SHA384      TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD

AES256-SHA256                TLSv1.2 Kx=RSA     Au=RSA  Enc=AES(256)  Mac=SHA256

AES128-GCM-SHA256      TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD

AES128-SHA256                TLSv1.2 Kx=RSA     Au=RSA  Enc=AES(128)  Mac=SHA256

AES256-SHA                       SSLv3 Kx=RSA       Au=RSA  Enc=AES(256)  Mac=SHA1

DES-CBC3-SHA                  SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1

AES128-SHA                       SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1

and they are all supported by most popular Content Delivery appliances.

According to Oracle doc, WebLogic supports SSL3 and TLS1, you can restrict the protocols with the 2 properties weblogic.security.SSL.protocolVersion and weblogic.security.SSL.minimumProtocolVersion (funnily it seems that the property value is spelled slightly differently in the 2 properties)

Interestingly it seems that support for TLS version > 1.0 is available only with Java 7.

So if you run on Java 6 the only option available is using SSL3.

WebLogic these days supports only the "JSSE-based SSL implementation", and the Cypher Suites are listed here for Java 6 and Java 7