Difference in dealing with ssl certificate in respect of browser and jvm?

Question

This is how browser deals with ssl certificate when connecting to https site

1. When i type https://myDemoSite.com in browser , first of all my browser asks for the certificate from myDemoSite.com(due to https), then myDemoSite send that certificate to browser

2. Once browser receives that certificate, browser will check whether it is signed by verified authority or not like verisign

3. If yes from second step,then as third step it checks whether certificate issues has same url which user in browser typed

Now i am connecting the https site through java program say HttpsConnectProg1.My question is how the programmei.e HttpsConnectProg1 will deal with this certificate issued with https site connection(though certificate issued by this https site is cerified i.e signed by verified authority).

I just tried a small programme connecting to https site which issues the certified certificate. I was expected some error like sslhandshake error or some certificate error (as i did not add this this certified certificate in $JAVA_HOME\jre\lib\security folder)but to my surprise i did not get any error .

Now important question is does HttpsConnectProg1 checks step 3 done by browser as it is very important step? For your reference here it is

 import java.io.IOException;
 import java.net.MalformedURLException;
 import java.net.URL;
 import java.net.URLConnection;
 import java.util.Properties;
 import javax.net.ssl.HostnameVerifier;
 import javax.net.ssl.HttpsURLConnection;
 import javax.net.ssl.SSLSession;


 public class ConnectToDemoSite {

/**
 * @param args
 */
public static void main(String[] args) {
    // TODO Auto-generated method stub

    String urlStr = "https://www.myDemoSite.com/demo1/";
    URL url;
    Properties reply = new Properties();
    try {
        url = new URL(urlStr);
        URLConnection conn = url.openConnection();
        if(conn instanceof HttpsURLConnection)
        {
        HttpsURLConnection conn1 = (HttpsURLConnection)url.openConnection();
            conn1.setHostnameVerifier(new HostnameVerifier()  
            {        
                public boolean verify(String hostname, SSLSession session)  
                {  
                    return true;  
                }  
            });  

        reply.load(conn1.getInputStream());
        }
        else 
        {
             conn = url.openConnection();
             reply.load(conn.getInputStream());
        }
    } catch (MalformedURLException e) {
       e.printStackTrace();
        e.printStackTrace();
    } catch (IOException e) {
        e.printStackTrace();
    }
    catch (Exception e) {
        e.printStackTrace();
    }
    System.out.println("reply is"+reply);



 }

}

Answer 1

When you make a connection to an https:// URI with Java, it uses the Java Secure Socket Extension (JSSE) (unless you really want to use a custom implementation of SSL/TLS, but that's very rare).

There are multiple ways of tweaking the trust management (mainly be using custom TrustManagers), but it will use a certain number of sensible settings otherwise.

In your example, the certificate will be verified using the default SSLContext, itself configured with the default X509TrustManager, with trust anchors read from cacerts (see the table in the Customization section of the JSSE Ref. Guide).

By default, the JRE comes with a number of pre-trusted CA certificates (like most browsers or OSes) in cacerts, which is usually similar to what you would find in browsers. Here is what the JSSE Ref. Guide says about it:

IMPORTANT NOTE: The JDK ships with a limited number of trusted root certificates in the /lib/security/cacerts file. As documented in keytool, it is your responsibility to maintain (that is, add/remove) the certificates contained in this file if you use this file as a truststore.

Depending on the certificate configuration of the servers you contact, you may need to add additional root certificate(s). Obtain the needed specific root certificate(s) from the appropriate vendor.

If the certificate is trusted, it then checks whether the host name is valid for the intended URL. (Note that it's not the full URL that is checked, but the host name only.)

Those rules are defined in RFC 2818 (the HTTPS specification), Section 3.1. (Java 7 doesn't implement RFC 6125 yet, but the rules are very similar, especially for HTTPS.) EDIT: When the connection is established, the URLConnection (and the underlying SSLSession) is set with the host name of the server. In short, following the rules in RFC 2818, it looks into the server certificate for a DNS entry in the Subject Alternative Name (SAN) extension of the certificate to see if it matches the host name set for the connection, or look for that name in the certificate's Subject DN's Common Name (CN), when no SAN DNS entry is present.

The host name verification is normally done by the default host name verifier. In your example, you've replaced the default verifier by one that always returns true. Hence, this verification will not actually happen in your case, and everything will be accepted (you're introducing a security hole by doing this).

In addition, the default host name verification done in Java follows RFC 2818 more strictly than a number of browsers. In particular, it won't accept IP addresses in CNs.

(For the same reason as you should use a host name verifier that always returns true, you shouldn't use trust managers that don't do anything, as you'll see a number of examples around, offering a quick fix for some SSL error messages.)

Answer 2

Java includes root certificates from well-known certificate authorities, so if you have a real certificate, it operates much like a browser.

If you sign your own certificate, a browser will warn you and provide a UI to enable use of the certificate in the future. This is where things diverge for a Java program—the right way to handle this depends entirely on the program you are writing, and there can't be a one-size-fits-all approach.

If your application has a UI, you could do something similar to what a browser does.

On the other hand, a "headless" application is usually pre-configured with the necessary root certificates.

In the end, both browsers and the Java PKIX validation libraries are maintaining the security of TLS by requiring you to provide or approve the root certificates on which authentication ultimately depend. Without trusted root certificates, it is impossible to authenticate a server, and thus impossible to ensure privacy or integrity of communications.