Apache HttpClient able to communicate over HTTPS when DIRECT but not via PROXY error: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated - apache

I have read though many different examples but I am currently having difficulties trying to communicate via a proxy using HTTPS. I have a wrapper to create a Apache HttpClient as seen in the code below.
Currently if I make my call without setting up a proxy it will use my truststore from the SSLSocketFactory and correctly allow the communication via SSL. The only certificate required is a verisign server certificate which does not require authentication.
When I setup a proxy I get an error saying:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
I feel that I must be missing some type of proxy setup which makes the proxy connection use the same SSLSocketFactory?
I tested with -Djavax.net.debug=ssl and I can see a lot more SSL activity when going direct. When I use direct I can see all the keys loaded and sent with the request, when I use the proxy I only see:
httpConnector.receiver.3, setSoTimeout(30000) called
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1307565311 bytes = { 184, 216, 5, 151, 154, 212, 232, 96, 69, 73, 240, 54, 236, 26, 8, 45, 109, 9, 192,
227, 193, 58, 129, 212, 57, 249, 205, 56 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_C
BC_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, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH
_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
]
Compression Methods: { 0 }
***
httpConnector.receiver.3, WRITE: TLSv1 Handshake, length = 73
httpConnector.receiver.3, WRITE: SSLv2 client hello message, length = 98
httpConnector.receiver.3, handling exception: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
httpConnector.receiver.3, SEND TLSv1 ALERT: fatal, description = unexpected_message
httpConnector.receiver.3, WRITE: TLSv1 Alert, length = 2
httpConnector.receiver.3, called closeSocket()
httpConnector.receiver.3, IOException in getSession(): javax.net.ssl.SSLException: Unrecognized SSL message, plaintext conn
ection?
httpConnector.receiver.3, called close()
httpConnector.receiver.3, called closeInternal(true)
httpConnector.receiver.3, called close()
httpConnector.receiver.3, called closeInternal(true)
2011-12-20 11:11:59,401 [httpConnector.receiver.3] INFO - The JavaScript method AddEvent threw an exception of type class co
m.alarmpoint.integrationagent.soap.exception.SOAPRequestException with message "javax.net.ssl.SSLPeerUnverifiedException: pe
er not authenticated". The exception will be propogated up the call stack.
Can anyone help out please. Here is my code for setting up the proxy and SSLSocketFactory.
var client = httpClientWrapper.getHttpClient();
var proxy = new HttpHost(PROXY_HOST, PROXY_PORT, "https");
client.getParams().setParameter(ConnRoutePNames.DEFAULT_PROXY, proxy);
var authpref = new ArrayList();
authpref.add(AuthPolicy.BASIC);
client.getParams().setParameter(AuthPNames.PROXY_AUTH_PREF, authpref);
ServiceAPI.getLogger().debug("KeyStore.getDefaultType() " + KeyStore.getDefaultType());
var trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
var instream = new FileInputStream(new File("conf/my.truststore"));
try {
ServiceAPI.getLogger().debug("getting trustore");
trustStore.load(instream, "changeit".split(''));
} finally {
instream.close();
}
var socketFactory = new SSLSocketFactory(trustStore);
var sch = new Scheme("https", socketFactory, 443);
client.getConnectionManager().getSchemeRegistry().register(sch);
Stack trace:
Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(Unknown Source)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:390)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:488)
at org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:561)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:732)

Here's a variant on aaron's solution, in Java (vs Groovy). This solution also avoids the HttpClientWrapper class (where does that come from?), and loads the proxy's certificate directly. It is written against HttpClient 4.2 (but I think it should work with 4.0). As an added bonus it includes an example of proxy authentication for a Windows proxy such as Microsoft ForeFront TMG.
It took me long enough to piece this together that I figured I should share it:
HttpParams params = new BasicHttpParams();
DefaultHttpClient.setDefaultHttpParams( params ); // Add the default parameters to the parameter set we're building
DefaultHttpClient client = new DefaultHttpClient( params );
KeyStore trustStore = KeyStore.getInstance( KeyStore.getDefaultType() );
trustStore.load( null );
InputStream certStream = new FileInputStream( "cert-file" );
CertificateFactory cf = CertificateFactory.getInstance("X.509");
X509Certificate cert = (X509Certificate)cf.generateCertificate(certStream);
certStream.close();
trustStore.setCertificateEntry( "proxy-cert", cert );
SSLSocketFactory socketFactory = new SSLSocketFactory(trustStore);
client.getConnectionManager().getSchemeRegistry().register( new Scheme( "https", 443, socketFactory ));
client.getParams().setParameter( ConnRoutePNames.DEFAULT_PROXY,
new HttpHost( "my-proxy", 8080 ));
// These 3 lines are only needed if your proxy is Windows based & requires authentication
AuthScope scope = new AuthScope( "myproxy", 8080, null, AuthPolicy.NTLM );
Credentials credentials = new NTCredentials( "username", "changeit", "WORKSTATION", "MY-DOMAIN" );
client.getCredentialsProvider().setCredentials( scope, credentials );
HttpGet get = new HttpGet( "https://mysite.com/resource" );
String result = client.execute( get, new BasicResponseHandler() );
System.out.println( result );

I solved this. The problem which I found once debugging into HttpClients code was the way my proxy was configured and the scheme's available.
HttpRoute[{tls}->https://someproxy->https://some_endpoint:443]
The problem was that the proxy was setup for https scheme but it was actually running on http. This became a problem when the wrapper did not configure a http scheme. In the end I created the SSLSocketFactory for my truststore and a default http scheme and setup my proxy correctly.
// Setup the Keystore and Schemes for the HttpClient and Proxy
var trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
var instream = new FileInputStream(new File("conf/my.truststore"));
try {
trustStore.load(instream, "changeit".split(''));
} finally {
instream.close();
}
var socketFactory = new SSLSocketFactory(trustStore);
var schHttp = new Scheme("http", PROXY_PORT, PlainSocketFactory.getSocketFactory());
// Create the HttpClient wrapper which will have the truststore SSLSocketFactory and a default http scheme and proxy setup
httpClientWrapper = new HttpClientWrapper("some_endpoint", 443, "/", socketFactory);
var client = httpClientWrapper.getHttpClient();
var proxy = new HttpHost(PROXY_HOST, PROXY_PORT, "http");
client.getParams().setParameter(ConnRoutePNames.DEFAULT_PROXY, proxy);
client.getConnectionManager().getSchemeRegistry().register(schHttp);

Have you tried using the global -Dhttp.proxyHost=proxy.host.com -Dhttp.proxyPort=8080 when launching your java process to verify that the SSLSocketFactory isn't falling back to proxyless communications.

Related

SSL issue on Android 9 Google Pixel One

I am trying to perform HTTPS requests to a host 10.10.10.1 from Android host with 10.10.10.2 in network without Internet connection - only WiFi 2 peers AP and Android 9 Google Pixel One device.
I've created network_security_config.xml with my cert that is self-signed and has CN=10.10.10.1 and SAN= DNS: 10.10.10.1 PI: 10.10.10.1.
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<base-config cleartextTrafficPermitted="true">
<trust-anchors>
<certificates src="system" />
<certificates src="user" />
<certificates src="#raw/zone"/>
</trust-anchors>
</base-config>
</network-security-config>
I don't receive verification error and observe successful requests incoming to server - data are HTTP request, decrypted and shown on the server log. But the server can't send data back! It sends, but for some reason these data are not being accepted by the Android phone - just ignored.
I see packets are going from the server to the phone and the server repeatedly retries to shutdown SSL socket until error or success (I made such behavior intentionally during surveying) - here is Wireshark dump from WiFi air:
Here is my request from AsyncTask
protected String doInBackground(String... params) {
StringBuilder result = new StringBuilder();
try {
CertificateFactory cf = CertificateFactory.getInstance("X.509");
InputStream caInput = new BufferedInputStream(MainActivity.this.getResources().openRawResource(R.raw.zone));
Certificate ca = cf.generateCertificate(caInput);
String keyStoreType = KeyStore.getDefaultType();
KeyStore keyStore = KeyStore.getInstance(keyStoreType);
keyStore.load(null, null);
keyStore.setCertificateEntry("ca", ca);
String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
TrustManagerFactory tmf = TrustManagerFactory.getInstance(tmfAlgorithm);
tmf.init(keyStore);
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, tmf.getTrustManagers(), null);
URL url = new URL("https://10.10.10.1/connect");
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
conn.setSSLSocketFactory(ctx.getSocketFactory());
conn.setRequestProperty("param1", params[0]);
conn.setRequestProperty("param2", params[1]);
conn.setRequestMethod("POST");
conn.setDoOutput(true);
conn.setDoInput(true);
mInputStream = conn.getInputStream();
byte[] buffer = new byte[1024];
ByteArrayOutputStream _buf = new ByteArrayOutputStream();
int l;
BufferedInputStream bufin = new BufferedInputStream(mInputStream);
while ((l = bufin.read(buffer,0,1024)) != -1) {
_buf.write(buffer, 0, l);
String rec = _buf.toString("UTF-8");
Log.d("MAIN", "Read: " + rec);
result.append(rec);
}
Log.d("MAIN", "Read finished: " + result.toString());
} catch (Exception e) {
e.printStackTrace();
}
return result.toString();
}
I suspect that Android 9 Network Security does block traffic somehow. I tried to use SSLSockets, change port from 443 to e.g. 1234 - no luck.
In fact my app is being created with Qt and firstly I used Qt stuff, but having no luck - I made fallback to Android Java code within my MainActivity, that I call via JNI from Qt code. Result is the same and I have no ideas more...
Where to dig?
UPD1
When the self-signed certificate is generated with SAN containing DNS:10.10.10.1 only (without IP:10.10.10.1) SSL fails with warnings:
W System.err: javax.net.ssl.SSLPeerUnverifiedException: Hostname 10.10.10.1 not verified:
W System.err: certificate: sha1/gyr2GOhy5lA+ZAHEzh0E2SBEgx0=
W System.err: DN: CN=10.10.10.1,O=Some ltd.,L=Knoxville,ST=TN,C=US
W System.err: subjectAltNames: [10.10.10.1]
W System.err: at com.android.okhttp.internal.io.RealConnection.connectTls(RealConnection.java:201)
W System.err: at com.android.okhttp.internal.io.RealConnection.connectSocket(RealConnection.java:149)
W ...
And conversely, with SAN IP:10.10.10.1 (without DNS: 10.10.10.1) - works as before - session established, data transferred to server and decrypted, but responses from server to client just ignored by client.
UPD2
I've also tried to use domain name some.device for the 10.10.10.1 device and issued certificate with CN and SAN DNS = some.device. It's resolved by Android 9 client, data is being sent successfully but response is still not being accepting.
Looks like Android bug.
After making additional surveying:
1. Some set of Android devices (builds), including Pixel 1, does not accept TCP session that was not finalized by mutual [FIN,ACK] and received data is not delivered to upper level of stack. Also data may not be accepted if TCP stream was not solid, with many retransmissions and Seq changing.
2. In case of using Qt - Android Network Security Configuration does not affect on communications.
3. This is not TLS related issue.

Restsharp :The SSL connection could not be established

An app is run on netcore2.1.5,win7.
I use restsharp to request the API and need to take client certificates, always return the error:
The SSL connection could not be established, see inner exception.
Authentication failed, see inner exception
The inner exception content:
System.ComponentModel.Win32Exception (0x80090326): 接收到的消息异常,或格式不正确。
English version:
"The message received is abnormal or not formatted correctly"
I user postman to request the API and take the same crt file and response the
result result.
My code on below:
string clientCertfile = #"E:\https\client.crt";
var client = new RestClient("https://apiserver/iocm/app/sec/v1.1.0/login");
X509Certificate2 certificates = new X509Certificate2(clientCertfile);
//X509Certificate2 certificates = GetMyX509Certificate(clientCertfile);
client.ClientCertificates = new X509Certificate2Collection(){ certificates };
client.RemoteCertificateValidationCallback =
new RemoteCertificateValidationCallback(OnRemoteCertificateValidationCallback);
var request = new RestRequest(Method.POST);
request.AddHeader("Content-Type", "application/x-www-form-urlencoded");
request.AddParameter("appId", "rIsyJsnMtOrKfpSO90");
request.AddParameter("secret", "8v0fH0ztunjP1oXT");
IRestResponse response = client.Execute(request);
postman test image

Specifying an outbound SSL configuration programmatically using JSSEHelper on Websphere 8.0. does not work

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:
SSL_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_DSS_WITH_AES_128_CBC_
SHA SSL_RSA_WITH_AES_128_GCM_SHA256
SSL_RSA_WITH_AES_128_CBC_SHA256
SSL_DHE_RSA_WITH_AES_128_GCM_SHA256
SSL_DHE_RSA_WITH_AES_128_CBC_SHA256
SSL_DHE_DSS_WITH_AES_128_GCM_SHA256
SSL_DHE_DSS_WITH_AES_128_CBC_SHA256
Unfortunately, a different list of cipher suites has been provided in ClientHello request:
SSL_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_RSA_WITH_AES_128_CBC_SHA
SSL_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
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
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:
SSL_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_DSS_WITH_AES_128_CBC_SHA
SSL_DHE_DSS_WITH_AES_128_CBC_SHA256
Once again, a different list of cipher suites was provided in ClientHello request:
SSL_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_DSS_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
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:
SSL_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_DSS_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_AES_128_GCM_SHA256
SSL_RSA_WITH_AES_128_CBC_SHA256
SSL_DHE_RSA_WITH_AES_128_GCM_SHA256
SSL_DHE_RSA_WITH_AES_128_CBC_SHA256
SSL_DHE_DSS_WITH_AES_128_GCM_SHA256
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.
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);
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:
../logs/server1
../logs/nodeagent
../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
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.
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):
SSL_RSA_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
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:
SSL_RSA_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
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.)

How to connect http server websocket with ssl using vertx?

I have created two classes server and client. Server starting with ssl as below
HttpServer server =
vertx.createHttpServer(new HttpServerOptions().setSsl(true).setKeyStoreOptions(
new JksOptions().setPath("server-keystore.jks").setPassword("wibble")
));
Also one more i.e. client
vertx.createHttpClient(new HttpClientOptions().setSsl(true)).getNow(4443, "localhost", "/", resp -> {
System.out.println("Got response " + resp.statusCode());
resp.bodyHandler(body -> System.out.println("Got data " + body.toString("ISO-8859-1")));
});
While running both On client I am getting "Failed to create SSL connection". Is there any way to configure anything related to ssl?
To enable ssl in vertx you can use keystore.jks file
Then use following configuration :
HttpServerOptions secureOptions = new HttpServerOptions();
if (Configuration.SSL_enabled) {
LOG.debug("Secure Transport Protocol [ SSL/TLS ] has been enabled !!! ");
secureOptions.setSsl(true)
.setKeyStoreOptions(new JksOptions().setPath(Configuration.SSL_filename)
.setPassword(Configuration.SSL_password))
.setTrustStoreOptions(new JksOptions().setPath(Configuration.SSL_filename)
.setPassword(Configuration.SSL_password))
.addEnabledSecureTransportProtocol(Constants.TLS_VERSION_1)
.addEnabledSecureTransportProtocol(Constants.TLS_VERSION_2);
}
vertx.createHttpServer(secureOptions).requestHandler(router::accept).listen(Configuration.port);
I hope this will help you :)

How to ignore "localhost" in Apache HttpClient using TLSv1.2?

I've tested several syntax constructions for Apache HttpClinet (HTTPS & TLS) in order to ignore the certificate chain for self-signed certificates typically used in "localhost" configurations. There is a custom HttpClient that works well for TLSv1.1 but watching the server traces, it does not trigger use of TLSv1.2, which is the desired security algorithm.
Below you find an attempt to configure the HttpClient using TLSv1.2.
Suggestions for other constructions are welcome. The "localhost" scenario remains a usual mechanism for the development of peer-to-peer routines. Would be nice to have a configurable routine that accepts self-signed certificates for localhost access only.
TLSv1.1 example and using custom HttpClient (Works OK for TLSv1.1 but does not work for TLSv1.2):
HttpClient client = HttpClients.custom().setSSLHostnameVerifier(new NoopHostnameVerifier()).setSslcontext(new SSLContextBuilder().loadTrustMaterial(null, (x509Certificates, s) -> true).build()).build();
Server Log:
*** Finished
verify_data: { 251, 245, 220, 174, 235, 125, 248, 119, 220, 80, 38, 1 }
***
Thread-7, WRITE: TLSv1 Handshake, length = 48
%% Cached server session: [Session-23, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA]
Thread-7, WRITE: TLSv1 Application Data, length = 108
Thread-7, WRITE: TLSv1 Application Data, length = 1
Thread-7, WRITE: TLSv1 Application Data, length = 19
Client - OK
Debug HTTP response: HttpResponseProxy{HTTP/1.1 200 OK [Date: Tue, 21 Feb 2017 21:16:02 GMT, Access-control-allow-origin: *, Content-length: 20] ResponseEntityProxy{[Content-Length: 20,Chunked: false]}}
*** end of debug ***
Service HTTP Response Code : 200
contentLength is: 20
serviceResponse : This is the response
Testing with TLSv1.2 and code
SSLContext sslContext = SSLContexts.custom().build();
SSLConnectionSocketFactory sslConnectionSocketFactory = new SSLConnectionSocketFactory(sslContext,
new String[]{"TLSv1.2"}, null, SSLConnectionSocketFactory.getDefaultHostnameVerifier());
HttpClient client = HttpClients.custom().setSSLHostnameVerifier(NoopHostnameVerifier.INSTANCE).setConnectionManager(clientConnectionManager).build();
(*) SSLContext class is deprecated
server log:
-Djavax.net.debug=ssl
or
System.setProperty("javax.net.debug", "ssl");
JsseJCE: Using MAC HmacSHA256 from provider TBD via init
MAC: Using MessageDigest HmacSHA256 from provider IBMJCE version 1.8
*** Finished
verify_data: { 69, 241, 3, 42, 44, 222, 21, 174, 250, 83, 244, 25 }
***
Thread-7, WRITE: TLSv1.2 Handshake, length = 80
%% Cached server session: [Session-21, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
Thread-7, READ: TLSv1.2 Alert, length = 64
Thread-7, RECV TLSv1.2 ALERT: warning, close_notify
Error at the client:
sh ./runit.sh
javax.net.ssl.SSLPeerUnverifiedException: Host name 'localhost' does not match the certificate subject provided by the peer (CN=My Name, OU=RED, O=RED Brazil, L=MYCITY, ST=SP, C=BR)
The following construction managed to connect with TLSv1.2 using a localhost certificate:
// solution for localhost certificates and TLSv1.2
// copied from: http://stackoverflow.com/questions/34655031/javax-net-ssl-sslpeerunverifiedexception-host-name-does-not-match-the-certifica/34657512
// thanks
final SSLConnectionSocketFactory sslsf;
try {
sslsf = new SSLConnectionSocketFactory(SSLContext.getDefault(),
NoopHostnameVerifier.INSTANCE);
} catch (NoSuchAlgorithmException e) {
throw new RuntimeException(e);
}
final Registry<ConnectionSocketFactory> registry = RegistryBuilder.<ConnectionSocketFactory>create()
.register("http", new PlainConnectionSocketFactory())
.register("https", sslsf)
.build();
// HttpClient client;
final PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(registry);
cm.setMaxTotal(100);
HttpClient client = HttpClients.custom()
.setSSLSocketFactory(sslsf)
.setConnectionManager(cm)
.build();
// end of solution for localhost bypass