I'm writing an Android client for a system that requires me open an SSLSocket to a proxy server, do a tunnel handshake and then create ANOTHER SSLSocket over the tunnel. Here is my code to create the tunnel:
SSLSocketFactory sslsocketfactory = securityService.getSslContextNoCerts().getSocketFactory();
SSLSocket sslSocket = (SSLSocket) sslsocketfactory.createSocket(proxyAddress.getAddress(),
proxyAddress.getPort());
sslSocket.setEnabledProtocols(new String[] { SecurityService.TLS10 });
sslSocket.setEnabledCipherSuites(SecurityService.CIPHERS);
sslSocket.startHandshake();
Then I do tunnel handshake and then:
SSLSocketFactory sslsocketfactory = securityService.getSslContext().getSocketFactory();
hostSocket = (SSLSocket) sslsocketfactory.createSocket(tunnel,
InetAddress.getByAddress(remoteAddress.getIpAddress()).getHostAddress(),
remoteAddress.getPort(), false);
hostSocket.setUseClientMode(false);
hostSocket.setNeedClientAuth(true);
securityService.setEnabledProtocols(hostSocket);
hostSocket.setEnabledCipherSuites(SecurityService.DATASESSION_CIPHERS);
hostSocket.startHandshake();
At this point I get an SSLProtocolException with this message:
error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol (external/openssl/ssl/s23_srvr.c:589 0xad12b3f0:0x00000000)
Anybody know how I can achieve this? I know your first question would be why layer SSL over SSL, but I'm writing a client for and EXISTING system that requires it.
Any help would be much appreciated.
Zhubin
Ok I finally fixed this problem. For some reason when I use org.apache.harmony.xnet.provider.jsse.OpenSSLProvider (Android default SSL provider), SSL over SSL does not work. So I switched to org.apache.harmony.xnet.provider.jsse.JSSEProvider and now everything works fine.
Your code looks correct. As it doesn't work, I suggest you have misunderstood the requirement, or it has been misrepresented to you. I suggest you only need to keep using the original SSLSocket. Try it. I find it vanishingly unlikely that any real system works in the way you have described. Not only would its performance be abysmal; the server would have to have the same kind of double-SSL coding that you have here: and how would it know when to do that and when not? Once the tunnel is created the proxy just copies bytes. I bet that just continuing to use the original SSL connection will work.
Related
Im coding a client-server chat application. I want to encrypt connection between those two. Im doing that for my first time and I find it difficult. In my understanding I need a truststore for client and a keystore for server. I have followed this guide to generate them:http://peoplesofttutorial.com/generating-key-store-and-trust-store-using-keytool/
Client:
System.setProperty("javax.net.ssl.trustStore" , "hrms.truststore");
System.setProperty("javax.net.ssl.trustStorePassword" , "123456");
SSLSocketFactory sslsf = (SSLSocketFactory) SSLSocketFactory.getDefault();
SSLsocket = (SSLSocket) sslsf.createSocket(server, port);
Server:
System.setProperty("javax.net.ssl.keyStore" , "pskey.keystore");
System.setProperty("javax.net.ssl.keyStorePassword","123456");
SSLServerSocketFactory sslsocketfactory = (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
sslserversocket = (SSLServerSocket) sslsocketfactory.createServerSocket(Port);
Server is starting correctly. When I connect a client which is run on the same computer as the server is then I can connect without any issues but when I connect from different computer which is on the same network I get this error: javax.net.ssl.SSLException: Received fatal alert: internal_error
Could anyone help me solve this error?
I have solved my issue. My trust store and keystone were in my project files, but when I compiled it to runnable jar I thought that trust store and keystore are included in that runnable jar, unfortunately they are not. I solved it by putting truststore and keystore in one folder with the runnable jar.
Solution was really simple and the whole problem occurred because of my inexperience.
Thank you for help.
I have an app which connects to a server via HTTPS.
The server in question has a weak certificate which utilises RC4 Cipher (default support for which was recently removed from the JDK https://www.java.com/en/download/faq/release_changes.xml)
So following upgrade of the JDK, I am seeing javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
The release notes specify that you should use SSLSocket/SSLEngine.setEnabledCipherSuites()
to specifically enable certain ciphers.
However, using HttpsUrlConnection, or Apache's CloseableHttpClient, I can only find how to specify the SslSocketFactory. Which doesn't seem to provide function .setEnabledCipherSuites.
Found this post: Why does SSLSocketFactory lack setEnabledCipherSuites?
My question is:
Is there a way to get hold of the SSLEngine/Socket on an outbound client HTTP request so I can set the cipher suites before the handshake?
Thanks in advance.
I was facing the same problem and I was able to figure this out.
SecureProtocolSocketFactoryImpl protFactory = new SecureProtocolSocketFactoryImpl();
httpsClient.getHostConfiguration().setHost(host, port, httpsProtocol);
In the "SecureProtocolSocketFactoryImpl" class you have to override the method public Socket createSocket() for SecureProtocolSocketFactory class.
In that method you will get a socket like this
SSLSocket soc = (SSLSocket) getSSLContext().getSocketFactory().createSocket(
socket,
host,
port,
autoClose
);
So there you will be able to do something like below.
ciphersToBeEnabled[0] = "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA";
soc.setEnabledCipherSuites(ciphersToBeEnabled);
hope you get the idea. If you have any problems please comment below. Note that doing this only will not enable RC4 related ciphers. You will need to modify java "java.security" file in jre/lib/security/ file and remove CR4 form the disabled algorithm list.
For HttpsURLConnection, set the system property https.cipherSuites.
As you mentioned SSLSocketFactory doesn't support setEnabledCipherSuites() so can do something like this
SSLSocketFactory socketFactory=(SSLSocketFactory)SSLSocketFactory.getDefault();
SSLSocket socket=(SSLSocket)socketFactory.createSocket(host,port);
socket.setEnabledCipherSuites(CIPHERS);
SSLSocket provides setEnablesCipherSuites();
I need to implement the Apache HttpClient SecureProtocolSocketFactory interface to create SSL sockets that do not use the SSLv2Hello protocol and make SSLv3 handshakes. From the documentation, the process to modify the protocol list is to call setEnabledProtocols on the SSLSocket. I believe I need to do this after creating it but before connecting it because connection initiates the SSL handshake and it's the SSL handshake protocol I'm trying to change.
This is mostly fine: rather than using the with-parameter context.getSocketFactory().createSocket(...) overloads which both create and connect the sockets then I can use the parameterless overload to create the socket, set it up and then connect it myself. The problem is there's another overload of createSocket() in SSLSocketFactory that wraps an existing socket with SSL, and that initiates the handshake immediately i.e. I do not have the opportunity to reconfigure it.
So to cover that case too I think I've got to throw away SSLSocket.setEnabledProtocols and instead do one of
modify my SSLContext's set of protocols which is what SSLSocketImpl uses to configure itself. However I can't see a public interface to do this so I'd need to change this by reflection, which means assuming private members of the class and also getting access to the internal class ProtocolList.
use my SSLContext only to get an SSLEngine which I can configure, and then implement my own SSL on the sockets using this.
I'm not very happy with either of these; I'd probably lean towards reflection since Java 7+ is dropping SSLv2Hello so if the classes change in the future and my reflection breaks then that's not actually a problem. I have a new instance of SSLContext already for a custom trust store.
Have I missed something - a public mechanism on SSLContext or SSLSocketFactory to set this up? Is there a better, cleaner way to do this? Thanks!
On further investigation, I don't think reflection is possible either. I was looking at the JDK8 source since that's what I had to hand, whereas in the JDK6 source SSLSocket initialises itself from a static list, not from an SSLContext or SSLContextSpi property:
enabledProtocols = ProtocolList.getDefault();
and the source field behind getDefault is static final so I can't modify that either :-(
So I'm running out of ideas. I'm still not keen on reimplementing SSLSocket (2000+ lines of it) so I think it's back to setEnabledProtocols and hope my HTTPS client never has to negotiate up a connection to SSL.
I ran into very similar problem.
I think you can break most of the issues down to the question, why can we override enabled ciphers in a custom socket factory but we cannot set the procol versions returned by getEnabledProtocols(): String[]?
Or even more simple:
If you could set enabled ciphers and protocol versions in SSLContext, you could use any HttpsConnection / SSLClient and SSLServerSocket and even libaries (Apache HttpClient, OKHttp, ...) and be sure that your security requirements in terms of SSL protocol versions and ciphers are both met.
Unfortunately most people stop at the point where a connection is established, security is just an announce to them.
I know this has been asked several times. I've tried them all but none of them work as I want.
I'm polling a webservice repeatedly in 30 second intervals. The webservice is based on HTTPS / SSL. I want to remove the overhead of SSL handshake on each webservice call ( SSL reuse). How can I achieve this?
I've looked at SSLCertificateSocketFactory and SSLSessionCache which seems to be the answer. I can get an SSLSocket instance by calling
SSLSocketFactory sockFactory = SSLCertificateSocketFactory.getHttpSocketFactory(TIMEOUT, sslSession);
However I cannot find a way to set my keystore and password to this socket factory. I guess you can set the keystore and password only via an SSLSocketFactory constructor.
So my 2 problems are
1) Need SSL reuse
2) Need to use my keystore for accepting the certificates from the server.
Thanks
I have this:
SSLSocketFactory factory = HttpsURLConnection.getDefaultSSLSocketFactory();
SSLSocket socket = (SSLSocket) factory.createSocket("www.verisign.com", 443);
This is failing on the 2nd line with a "Connection refused" error.
Now, would I have to install verisign's certificate in my trust store before I can even do the above? I was under the impression that I could connect to an SSL server and execute getPeerCertificates() to get the certificates. Is this not what our browsers do? Otherwise how would they know which signing authority to use?
(Obviously I'm using Verisign as an example. My real URL is far too fugly to use here...)
Connection refused means nothing was listening at the target host:port, or a firewall got in the way. This is logically and temporally prior to anything SSL does.
Have you checked that the remote service is actually up and running, and that you can connect to it? Perhaps the "Connection refused" error is actually a refused connection. :-)
Usually you don't need to install server's certificate on your computer explicitly. PKI works in the way that your system should be able to validate server's certificate without any prior knowledge about it. However this will work only when your server's certificate has it's roots in on of the "known CAs", i.e. certificate authorities, whose root or other certificates are already listed on the client system. If this is not the case (eg. you have a self-signed or some other custom certificate on the server), you really need to install the certificate on your client system before the mentioned classes can validate server certificate properly.
You can read about certificates and how they are used in SSL here.