SSL Handshake under the hood …

Happy Friday!

We always hear about SSL handshake and routinely use it, but never really want/need to drill down to see what really is going on there. This is a nice handshake sequence description. During my development recently, I used CXF to call SOAP webservices via HTTPS over TLS. I ran into a few “handshake walls” which I eventually resolved. In the process, I found enabling tracer for SSL handshake is very useful. For Java, adding this to the VM params will enable it

-Djavax.net.debug=SSL,handshake

I captured the SSL communication as below. I won’t go through them in details because they are very self descriptive.

Be good and do excellent coding!

===========================================================

adding as trusted cert:
Subject: CN=…….
Issuer: CN=…….
Algorithm: RSA; Serial number: ……
Valid from Tue Nov 07 19:00:00 EST 2006 until Wed Jul 16 19:59:59 EDT 2036
…….
…….

Starting to Invoke Webservice –> https://xxx.xxx/mywebservice Fri Jun 26 09:54:27 EDT 2015
keyStore is :
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
trustStore is: C:\Program Files\Java\jdk1.8.0_45\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is :
init truststore
adding as trusted cert:
Subject: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
Issuer: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
Algorithm: RSA; Serial number: 0xc3517
Valid from Mon Jun 21 00:00:00 EDT 1999 until Mon Jun 22 00:00:00 EDT 2020

…….
…….
trigger seeding of SecureRandom
done seeding SecureRandom
trigger seeding of SecureRandom
done seeding SecureRandom
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
…….
…….

Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
main, setSoTimeout(0) called
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
…….
…….

%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1418549396 bytes = { 224, 43, 120, 102, 139, 75, 239, 187, 229, 175, 114, 139, 145, 9, 221, 183, 138, 2, 112, 134, 123, 94, 7, 68, 36, 208, 182, 123 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, ……., TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, ……, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, ……, SHA1withDSA, MD5withRSA
***
main, WRITE: TLSv1.2 Handshake, length = 207
main, READ: TLSv1.2 Handshake, length = 81
*** ServerHello, TLSv1.2
RandomCookie: GMT: 1418549396 bytes = { 142, 100, 141, 6, 255, 138, 243, 120, 33, 45, 208, 118, 224, 24, 6, 151, 36, 161, 154, 87, 240, 174, 80, 69, 194, 85, 209, 122 }
Session ID: {46, 112, 146, 68, 191, 63, 204, 28, 124, 103, 103, 9, 165, 180, 85, 127, 114, 199, 154, 56, 103, 219, 197, 48, 77, 75, 154, 11, 54, 168, 7, 157}
Cipher Suite: SSL_RSA_WITH_RC4_128_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Initialized: [Session-1, SSL_RSA_WITH_RC4_128_SHA]
** SSL_RSA_WITH_RC4_128_SHA
main, READ: TLSv1.2 Handshake, length = 2990
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN= …….
…….
…….
]
main, READ: TLSv1.2 Handshake, length = 4
*** ServerHelloDone
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1.2
main, WRITE: TLSv1.2 Handshake, length = 262
SESSION KEYGEN:
PreMaster Secret:
…….
…….
CONNECTION KEYGEN:
Client Nonce:
…….
…….
Server Nonce:
…….
…….
Master Secret:
…….
…….
Client MAC write Secret:
…….
…….
Server MAC write Secret:
…….
…….
Client write key:
…….
…….
Server write key:
…….
…….
main, WRITE: TLSv1.2 Change Cipher Spec, length = 1
*** Finished
verify_data: { 5, 13, 28, 40, 35, 90, 186, 31, 217, 111, 119, 83 }
***
main, WRITE: TLSv1.2 Handshake, length = 36
main, READ: TLSv1.2 Change Cipher Spec, length = 1
main, READ: TLSv1.2 Handshake, length = 36
*** Finished
verify_data: { 48, 164, 101, 77, 74, 77, 125, 12, 151, 111, 77, 111 }
***
%% Cached client session: [Session-1, SSL_RSA_WITH_RC4_128_SHA]
main, WRITE: TLSv1.2 Application Data, length = 450
main, WRITE: TLSv1.2 Application Data, length = 4116
…….
…….
main, READ: TLSv1.2 Application Data, length = 25

Finished Invoking Webservice.1435326869036

===========================================================

Advertisements

CXF Conduit setting for SSL and non-SSL client

Hi, there: Long time no see again. Spent a few days on some thing strange using CXF. I finally found out that there is some buggy issue with CXF Client. When hitting at WS on HTTPS/SSL, only cxf.xml will be effective. In details, the conduit client and authorization has to be configured in cxf.xml to make them work.

<http:conduit name=”https://.*”&gt;
<http:authorization>
<sec:UserName>userid1</sec:UserName>
<sec:Password>userpass1</sec:Password>
<sec:AuthorizationType>Basic</sec:AuthorizationType>
</http:authorization>
<http:client AutoRedirect=”false” Connection=”Keep-Alive”
AllowChunking=”true” ReceiveTimeout=”3600000″ ConnectionTimeout=”3600000″ />
</http:conduit>

But for NON-SSL request,  you need to configure them in code:

HTTPConduit http = (HTTPConduit) cl.getConduit();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setAllowChunking(true);
httpClientPolicy.setConnectionTimeout(TIMEOUT);
httpClientPolicy.setReceiveTimeout(TIMEOUT);
httpClientPolicy.setAsyncExecuteTimeout(TIMEOUT);
http.setClient(httpClientPolicy);

AuthorizationPolicy authorizationPolicy = new AuthorizationPolicy();
authorizationPolicy.setUserName(testUserID);
authorizationPolicy.setPassword(testUserPass);
authorizationPolicy.setAuthorizationType(“Basic”);
http.setAuthorization(authorizationPolicy);

I suspect this is a bug in CXF (at least version 2.74).   I haven’t fully tested it to make cxf.xml to work with NON-SSL. But I am sure there is this bug that for HTTPS, only cxf.xml file can work.

Cheers!

-TY

SSL issues by Soap Client from within Weblogic Server

Hi,

Happy Chinese New Year!

Every problem that took me more than 2 days to find the solution deserves a writeup! This time it was a known issue when starts a SOAP request from a Webservice client from within Weblogic server, over HTTPS.  The problem I had was that we use a wildcard certificate for the receiving host, something like *.tonyyan.com, but the hostname is something like server1.tonyyan.com. WLS by default will fail the hostname verification process, hence fails the SSL handshake. There is a very nice link  http://jandrewthompson.blogspot.com/2010/04/weblogic-and-wildcard-ssl-certificates.html where it is described how to impl. and use a custom hostname verifier. However, I liked to use it just for my own client instead of changing verifier at the WLS server level. Thus, I used this code to by pass hostname verification all together (warning, this should not be used in PROD env, where some better and strict logic should be used to control wild card certificate against its hostname. Or, you could be vulnerable to man-in-middle attack).

//BindingProvider
BindingProvider bp = (BindingProvider)port;

// hostname issue – allow any hostname vs. its certificate
Map<String, Object> ctxt = bp.getRequestContext();

HostnameVerifier hv = new HostnameVerifier() {
public boolean verify(String urlHostName,SSLSession session) {
logger.info(“HostnameVerifier without validation.  urlHostName is ” + urlHostName);
return true;
}
};
ctxt.put(“com.sun.xml.ws.transport.http.client.hostname.verifier”, hv);
ctxt.put(“com.sun.xml.ws.transport.https.client.hostname.verifier”, hv);
ctxt.put(“com.sun.xml.internal.ws.client.hostname.verifier”, hv);

With this code, it still didn’t work for me. It turns out that I forgot to put the server certificate in WLS’ truststore, based on this order of usage of certificates.

http://docs.oracle.com/cd/E11035_01/wls100/secmanage/identity_trust.html#wp1183754

After I put in the server certificate in DemoTrust.jks, things start to work great.

-TY