views:

254

answers:

1

I have created a standalone executable JAR program that needs to send private information over a SSL connection.
I was not able to establish the SSL connection using certificates. Was getting this:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path `building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target`

So I found some code somewhere that creates a trust manager that does not validate certificate chains:

// Create a trust manager that does not validate certificate chains
TrustManager[] trustAllCerts = new TrustManager[]{
            new X509TrustManager() {
                public java.security.cert.X509Certificate[] getAcceptedIssuers() {
                    return null;
                }
                public void checkClientTrusted(
                    java.security.cert.X509Certificate[] certs, String authType) {
                }
                public void checkServerTrusted(
                    java.security.cert.X509Certificate[] certs, String authType) {
                }
            }
        };

That did the trick and I was able to establish SSL connection without any certificates.

My concern is if the data will still be encrypted when exchanging private information. This is an execute JAR file that clients will be downloading to their computers.

So is a certificate really necessary for this case?

Thanks.

+1  A: 

Yes, it's still encrypted.

Essentially, SSL provides 2 types of security: trust and confidentiality.

You're bypassing the trust part, but the confidentiality is still valid.

Essentially, the TrustManager you've created stops Java from checking that the server is who it says it is. If the transmission was intercepted, and IF the intercepting party had the necessary private key to decrypt the message, then you'd have a problem.

It's a big IF. In most cases, this is fine, but really you should look at downloading the server certificate and putting it into a keystore.

See "keytool". The keytol executable comes with the JDK, and you can use this command-line tool to create a 'keystore' (in this case, aka 'truststore').

http://java.sun.com/javase/6/docs/technotes/tools/windows/keytool.html

There are many ways to tell Java to use a keystore, and your choice depends on what libraries etc you're using to make the SSL connection. One method is to use startup options, e.g.:

-Djavax.net.ssl.trustStore=mySrvKeystore -Djavax.net.ssl.trustStorePassword=123456

Best to google for "keystore java" plus your library name (if you're using one)

hth

amir75
Thanks for your response, very helpful. So since this JAR will downloaded/installed into client's computers, I guess there is a way to download the certificate and have it at the keystore.so the certificate needs to be downloaded and stored in clients computer? To do this do I have to use native code to execute that keytool command in the clients computer?
Marquinio
No, you just have to execute the keytool once on your own computer, then deliver the keystore (normally a ..jks file), along with your application. I'm pretty sure you can wrap the keystore into your jar file, and reference it via the classpath... Sorry to say that Java's ssl client implementation isn't easy to understand, and requires some reading and doing to get along with it ok...
amir75
Thank you so much. Now I have a clear view of what I have to do.
Marquinio
'IF the intercepting party had the necessary private key to decrypt the message'. That's not correct. There is no private key to decrypt the message - there is a session key negotiated dynamically between the peers. The problem with that so-called TrustManager is that it prevents you from knowing wo you're talking to. So you have fully secure communications with, err, anybody. SSL is not secure without authentication. See RFC 2246.
EJP
Hi EJP. Yes, SSL does not provide authentication, but to say that 'there is no private key' is just wrong. You are correct in that someone malicious could offer their own certificate (public key), BUT, honestly truly, the message will need to be decrypted using the associated private key. Take a look at this: http://www.verisign.co.uk/ssl/ssl-information-center/how-ssl-security-works/index.html .. if you store the certificate in a keystore, then no-one other than the certificate owner would be able to decrypt your message. Cheers
amir75
The problem is that the given `TrustManager` *doesn't* check against a particular certificate - it will blindly accept *any* certificate from the purported server, which could well be supplied by the man-in-the-middle.
caf
Thats' what I said at the beginning. "You're bypassing the trust part". Sheesh
amir75