Specifying an outbound SSL configuration programma

Question

I am trying to create an SSL connection programmatically using a CUSTOM outbound ssl configuration configured in WAS 8.0.0.13 (IBM Websphere application server that uses java 1.6.0): (Security->SSL certificate and key managemement->Related Items:SSL configurations). The secure connection has been created successfully:a servlet that resides on the WAS server has connected to a server-side Socket listening on 127.0.0.1:1234. The problem is that my preferred cipher suites defined in 'Quality of Protection (QoP) settings' within SSL configuration are ignored. All the other properties (such as protocol or JSSE provider) are nicely regarded.

I have implemented a Servlet which was in the role of an SSL-client. This Servlet used this custom SSL configuration which had the following cipher suites defined:

1. SSL_RSA_WITH_AES_128_CBC_SHA
2. SSL_DHE_RSA_WITH_AES_128_CBC_SHA
3. SSL_DHE_DSS_WITH_AES_128_CBC_
4. SHA SSL_RSA_WITH_AES_128_GCM_SHA256
5. SSL_RSA_WITH_AES_128_CBC_SHA256
6. SSL_DHE_RSA_WITH_AES_128_GCM_SHA256
7. SSL_DHE_RSA_WITH_AES_128_CBC_SHA256
8. SSL_DHE_DSS_WITH_AES_128_GCM_SHA256
9. SSL_DHE_DSS_WITH_AES_128_CBC_SHA256

Unfortunately, a different list of cipher suites has been provided in ClientHello request:

1. SSL_RSA_WITH_AES_128_CBC_SHA
2. SSL_DHE_RSA_WITH_AES_128_CBC_SHA
3. SSL_DHE_DSS_WITH_AES_128_CBC_SHA
4. SSL_RSA_WITH_3DES_EDE_CBC_SHA
5. SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
6. SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
7. SSL_RSA_WITH_DES_CBC_SHA
8. SSL_DHE_RSA_WITH_DES_CBC_SHA
9. SSL_DHE_DSS_WITH_DES_CBC_SHA
10. SSL_RENEGO_PROTECTION_REQUEST

(This custom SSL configuration contained TLSv1.1 protocol in its definition.)

I have also tried another protocol (TLSv1.2) with a smaller set of cipher suites:

1. SSL_RSA_WITH_AES_128_CBC_SHA
2. SSL_DHE_RSA_WITH_AES_128_CBC_SHA
3. SSL_DHE_DSS_WITH_AES_128_CBC_SHA
4. SSL_DHE_DSS_WITH_AES_128_CBC_SHA256

Once again, a different list of cipher suites was provided in ClientHello request:

1. SSL_RSA_WITH_AES_128_CBC_SHA
2. SSL_DHE_RSA_WITH_AES_128_CBC_SHA
3. SSL_DHE_DSS_WITH_AES_128_CBC_SHA
4. SSL_RSA_WITH_3DES_EDE_CBC_SHA
5. SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

Moreover, I have also checked cell-default cipher suites and node-default-cipher-suites and there is no match between them and those provided in the ClientHello: Default Node Configuration/Default Cell Configuration:

1. SSL_RSA_WITH_AES_128_CBC_SHA
2. SSL_DHE_RSA_WITH_AES_128_CBC_SHA
3. SSL_DHE_DSS_WITH_AES_128_CBC_SHA
4. SSL_RSA_WITH_AES_128_GCM_SHA256
5. SSL_RSA_WITH_AES_128_CBC_SHA256
6. SSL_DHE_RSA_WITH_AES_128_GCM_SHA256
7. SSL_DHE_RSA_WITH_AES_128_CBC_SHA256
8. SSL_DHE_DSS_WITH_AES_128_GCM_SHA256
9. SSL_DHE_DSS_WITH_AES_128_CBC_SHA256

I have followed these instructions: https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.0.0/com.ibm.websphere.nd.doc/info/ae/ae/tsec_ssloutconfiguseJSSE.html

and have created the following implementation. 'doGet' method is an entry point:

public class TLSv1_1 extends HttpServlet {
private static final long serialVersionUID = 1L;
com.ibm.websphere.ssl.JSSEHelper jsseHelper;

public TLSv1_1() {
    super();
    jsseHelper = com.ibm.websphere.ssl.JSSEHelper.getInstance();
}

protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {

    Properties existing_sslProps = null;
    try {
        String existingAlias = "TLSv1.1";
        existing_sslProps = jsseHelper.getProperties(existingAlias);

    } catch (com.ibm.websphere.ssl.SSLException e) {
        e.printStackTrace();
    }
    printSSLproperties(response, existing_sslProps);
    SSLSocket socket = getSslSocket(existing_sslProps);
    writeToSocket(socket, 1234);
}

public static void printSSLproperties(HttpServletResponse response, Properties sslProps) throws IOException {
    if (sslProps != null) {
        StringBuilder sb = new StringBuilder();
        Set set = sslProps.entrySet();
        Iterator it = set.iterator();
        while (it.hasNext()) {
            Map.Entry entry = (Map.Entry) it.next();
            Object value = entry.getValue();
            sb.append("key: " + entry.getKey() + ", value: " + value + "\n");
        }
        System.out.println("sslProps:    -----------\n" + sb.toString());           
    } else {
        System.out.println("sslProps == null");
        response.getWriter().append("sslProps == null");
    }
}

public SSLSocket getSslSocket(Properties sslProps) {
    Map<String, Object> sslMap = new HashMap<String, Object>();

    sslMap.put("com.ibm.ssl.direction", "outbound");
    sslMap.put("com.ibm.ssl.remoteHost", "127.0.0.1");
    sslMap.put("com.ibm.ssl.remotePort", "1234");
    sslMap.put("com.ibm.ssl.endPointName", "HTTP");
    SSLSocketFactory sslSocketFactory = null;
    try {
        sslSocketFactory = jsseHelper.getSSLSocketFactory(sslMap, sslProps);
    } catch (SSLException e) {
        e.printStackTrace();
    }

    SSLSocket socket = null;
    try {
        socket = (SSLSocket) sslSocketFactory.createSocket();
    } catch (IOException e) {
        e.printStackTrace();
    }
    return socket;
}

public static void writeToSocket(Socket socket, int port) throws IOException, UnknownHostException {

    InetAddress address = InetAddress.getByName("127.0.0.1");
    socket.connect(new InetSocketAddress(address, port));
    BufferedWriter stream = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));

    for (int i = 0; i < 3; i++) {
        String lineX = UUID.randomUUID().toString();
        stream.write(lineX);
        stream.newLine();
        stream.flush();
        System.out.println("NEW LINE SUCCESSFULLY WRITTEN INTO SOCKET:" + lineX);
        sleep();
    }
}

private static void sleep() {

    try {
        Thread.sleep(1000 * 30);
    } catch (InterruptedException e) {

    }
} 

}

The presence of the hash map sslMap seems to be of no importance. It does not matter whether is set to null or contains no values.

I have also tried to enforce ssl properties on thread (this one has the highest preference among all the others): This approach also dodn't worked:

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

String existingAlias = "TLSv1.1";
existing_sslProps = jsseHelper.getProperties(existingAlias);

jsseHelper.setSSLPropertiesOnThread(existing_sslProps);

CommonIO.printSSLproperties(response, existing_sslProps);       
SSLSocket socket = getSslSocket(existing_sslProps);
CommonIO.writeToSocket(socket, 1234);

jsseHelper.setSSLPropertiesOnThread(null);
}

Finally, I have tried not to bind to any SSL configuration present in WAS server SSL configs, but only wire up a custom configuration with my java code:

sslProps.setProperty("com.ibm.ssl.protocol", "TLSv1.1");
    sslProps.setProperty("com.ibm.ssl.enabledCipherSuites",
            "SSL_DHE_DSS_WITH_AES_128_CBC_SHA SSL_DHE_DSS_WITH_AES_128_GCM_SHA256 SSL_DHE_DSS_WITH_AES_128_CBC_SHA256");
    sslProps.setProperty("com.ibm.ssl.trustStore",
            "/opt/IBM/Websphere/profiles/AppSrv01/config/cells/localhostCell01/nodes/localhostNode01/trust.p12");
    sslProps.setProperty("com.ibm.ssl.trustStorePassword", "***");
    sslProps.setProperty("com.ibm.ssl.trustStoreType", "PKCS12");
    sslProps.setProperty("com.ibm.ssl.keyStore",
            "/opt/IBM/Websphere/profiles/AppSrv01/config/cells/localhostCell01/key.p12");
    sslProps.setProperty("com.ibm.ssl.keyStorePassword", "***");
    sslProps.setProperty("com.ibm.ssl.keyStoreType", "PKCS12");

    sslProps.setProperty("security.provider.1", "com.ibm.jsse2.IBMJSSEProvider2");
    sslProps.setProperty("ssl.SocketFactory.provider", "com.ibm.jsse2.SSLSocketFactoryImpl");

But this approach also did not work. Could you please help me? I suppose I missed something principal or custom SSL configuration does not exist in this product.

Answer 1

So due to my not looking at your code carefully initially. I see the problem. Because you get the Socket factory directly from the JSSEHelper, we are not getting the chance to put the ciphers on the socket.

In your case you should follow the WAS's programmatic SSL methods. Get the properties and put them on the thread. eg

 try {
        String existingAlias = "TLSv1.1";
        existing_sslProps = jsseHelper.getProperties(existingAlias);
    jsseHelper.setSSLPropertiesOnThread(existing_sslProps);

    } catch (com.ibm.websphere.ssl.SSLException e) {
        e.printStackTrace();
    } 

The later don't get the Socket factory from the JSSE, get the default. So in getSslSocket() do something like:

public SSLSocket getSslSocket(Properties sslProps) {

    SSLSocketFactory factory = SSLSocketFactory.getDefault();

    SSLSocket socket = null;
    try {
        socket = (SSLSocket) factory.createSocket();
    } catch (IOException e) {
        e.printStackTrace();
    }
    return socket;
}

This will get you a WAS socket factory. The create socket call should return you a socket with the ciphers set on the SSLSocket. When you are done you should clear the properties off the thread.

jsseHelper.setSSLPropertiesOnThread(null);

Answer 2

I'm looking at an error involving the use of a SSL configuration named "TLSv1.1". 2 of the 3 ciphers you have configured are not supported by TLSv1.1, you can find more info about cipher supported by IBM java 6 here https://www.ibm.com/support/knowledgecenter/es/SSYKE2_6.0.0/com.ibm.java.security.component.60.doc/security-component/jsse2Docs/ciphersuites.html?view=embed. This is leaving you with one cipher, SSL_DHE_DSS_WITH_AES_128_CBC_SHA.

[12/17/17 6:16:19:524 EST] 00000000 SystemOut     O   Ignoring unsupported cipher suite: SSL_DHE_DSS_WITH_AES_128_GCM_SHA256
[12/17/17 6:16:19:524 EST] 00000000 SystemOut     O   Ignoring unsupported cipher suite: SSL_DHE_DSS_WITH_AES_128_CBC_SHA256
[12/17/17 6:16:19:527 EST] 00000000 SystemOut     O   %% No cached client session
[12/17/17 6:16:19:528 EST] 00000000 SystemOut     O   *** ClientHello, TLSv1.1
[12/17/17 6:16:19:528 EST] 00000000 SystemOut     O   RandomCookie:  GMT: 1513509379 bytes = { 108, 16, 192, 144, 124, 116, 226, 48, 69, 61, 93, 187, 104, 67, 120, 166, 233, 194, 67, 244, 136, 159, 105, 130, 106, 175, 18, 251 }
[12/17/17 6:16:19:529 EST] 00000000 SystemOut     O   Session ID:  {}
[12/17/17 6:16:19:529 EST] 00000000 SystemOut     O   Cipher Suites: [SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RENEGO_PROTECTION_REQUEST] 

This connection is going to port 9202 on the same host, 127.0.0.1. And ultimately ends in a error, javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure. I think your server is trying to talk to your nodeagent with the wrong SSL configuration. It seems to pick that configuration up from the dynamic outbound selection filter.

[12/17/17 6:16:19:440 EST] 00000000 SSLConfigMana 3   SSLConfig dynamic selection info: *,127.0.0.1,*
[12/17/17 6:16:19:440 EST] 00000000 SSLConfigMana 3   Parsing entry 0 of 1: *,127.0.0.1,*
[12/17/17 6:16:19:440 EST] 00000000 SSLConfigMana 3   This entry has 3 attributes.
[12/17/17 6:16:19:440 EST] 00000000 SSLConfigMana 3   Protocol: *, Host: 127.0.0.1, Port: *
[12/17/17 6:16:19:440 EST] 00000000 SSLConfigMana 3   Found a dynamic selection match!
[12/17/17 6:16:19:440 EST] 00000000 SSLConfigMana <  getPropertiesFromDynamicSelectionInfo -> found. Exit

Your filter will match anything going to the 127.0.0.1, to use the SSL configuration called "TLSv1.1". What ever this connection is going to seems to be using TLSv1 protocol. So the connection fails because of protocol mismatch. It seems this SSL configuration is not intended to be used accessing 127.0.0.1 and port 9202. Could that be your local node agent or dmgr port? If so the connection needs to the the NodeDefaultSSLSettings.

It's not obvious to me in the trace what connection is talking to your server, localhost and port 1234. Perhaps if you fix your configuration so that the node will use the correct SSL configuration when going to port 9202 and 127.0.0.1 it may be easier to figure out.

Answer 3

thank you for your great support & swift reply! based on your inputs, I removed all the dynamic outbound rules present in SSL configuration settings.

I have also modified the list of supported cipher suites on WAS-side (client side) based on your great link you have provided!:-). More precisely, I opted for only these suites because they are supported by all TLS protocols (TLSv1.0,TLSv1.1, TLSv1.2):

1. SSL_RSA_WITH_AES_128_CBC_SHA
2. SSL_RSA_WITH_3DES_EDE_CBC_SHA
3. SSL_DHE_RSA_WITH_AES_128_CBC_SHA
4. SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
5. SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Once again, I cleared all log files and then started application server. After retesting my scenario, this delta in log-files has been generated: https://drive.google.com/open?id=19KaDlsx2UVS_YfByaORQOf89mLlJke4e

Server side application that listens on 1234 port supports the same cipher suites:

1. SSL_RSA_WITH_AES_128_CBC_SHA
2. SSL_RSA_WITH_3DES_EDE_CBC_SHA
3. SSL_DHE_RSA_WITH_AES_128_CBC_SHA
4. SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
5. SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Of course, I didn't expect the issue will be resolved after these changes but I expected that I find some errors in logs/traces to reduce the load imposed on you. Unfortunately, I wasn't successful. Could you please check these logs/traces? Thank you honestly very much!

(Please ignore this exception:

FFDC Exception:java.net.MalformedURLException SourceId:class com.ibm.wkplc.extensionregistry.PluginDescriptor.initFromDom ProbeId:1

present in server1_b7f67871_17.12.19_04.44.51.8551967663872103714940.txt file, since I retested it once again (for the 3rd time) and this exception haven't been present after the 3rd re-test.)

Answer 4

thank you for your tips! I followed these instructions:

https://www-01.ibm.com/support/docview.wss?uid=swg21162961

to increase log/trace level based on your tips. If I had to make some other configuration changes, please let me know.

I gathered log files only from these subdirectories:

1. ../logs/server1
2. ../logs/nodeagent
3. ../logs/ffdc and placed them into ALL_LOGS/logs directory within these files:

https://drive.google.com/open?id=18TMYyjKx8L_pd8TxFG1uq1rOmikVyWeg

, so if there are also other log/trace files in different locations, please let me know. (Only Delta is present in these files since I cleared all the log/trace files before starting the server and retesting my scenario.)

I found only this in ffdc logs:

The client and server could not negotiate the desired level of security.Reason: Received fatal alert: handshake_failure vmcid: 0x49421000 minor code: 70 completed: No

I am not sure whether is the root cause of my problem, but no google results seemed to be relevant to my problem. As far as google results are concerned, I meant these:

https://www.ibm.com/developerworks/community/forums/html/topic?id=a2910c33-8f55-4ef7-823d-7ae367682e35

http://www.dsxchange.com/viewtopic.php?t=134492&sid=f6e236a4f14a9d80fc51c0820e5f7ce7 None of them was helpful...

Along with logs-subdirectories, I am also attaching server-side socket stdout with stderr in TLSv1.1_enforce_OnThread.log. Additionally, I am also attaching client-side configuration CONFIG_TLSv1.1._ENFORSE_SSL_ON_THREAD.png

Could you please check these log files? Thank you honestly very much.

-- Michael