JSSE Socket Factories An Overview of SSL and JSSE

dependent on the JSSE implementation and is not something we can change programatically. We will use the last three methods to modify our original client. We can use the relevant methods of the SSL session to retrieve information and complete the verification of the server. Changes to our original client are shown in bold: package javasec.samples.ch14; import java.io.; import java.net.; import javax.net.; import javax.net.ssl.; import javax.security.cert.; public class SSLClientVerifier { public static void mainString[] args throws Exception { SocketFactory sf = SSLSocketFactory.getDefault ; SSLSocket s = SSLSocket sf.createSocket args[0], Integer.parseIntargs[1]; SSLSession sess = s.getSession ; String host = sess.getPeerHost ; X509Certificate[] certs = sess.getPeerCertificateChain ; String dn = certs[0].getSubjectDN.getName ; X500Name name = new X500Namedn; if host.equalsname.getCN System.err.printlnWarning: Expected + host + and got + name.getCN ; BufferedReader br = new BufferedReader new InputStreamReader s.getInputStream ; PrintWriter pw = new PrintWriters.getOutputStream ; System.out.printlnWho is Sylvia?; pw.printlnWho is Sylvia?; pw.flush ; System.out.printlnbr.readLine ; s.close ; } } We use the session object to retrieve the servers certificate. If the common name in the servers certificate is not equal to its hostname, we print out a warning message. It is conceivable that the name we used to construct the socket may not exactly match the name embedded within the certificate, so we should obtain the IP addresses of both and ensure that they are the same. Thats the technique well use a little later when we perform HTTP client verification. Note that this is the same thing a browser does when the name within a site certificate does not match the name within the URL. If you run this with the test keystore created earlier youll see the warning message, but if you create another keystore with the common name equal to the hostname of your server, this code will execute without the warning.

14.4 SSL Contexts and Key Managers

The generic SSL sockets utilize several default options, including the protocol version used TLS 1.0, which also supports SSL 3.0 and the default key and trust managers. If you want to change any of these options, you must use an instance of the SSLContext class com.sun.net.ssl.SSLContext . This is often necessary, although it moves us away from a strictly protocol−independent socket factory paradigm. The SSLContext class is an engine class; it provides the following methods: public static SSLContext getInstanceString protocol public static SSLContext getInstanceString protocol, Provider provider public static SSLContext getInstanceString protocol, String provider Obtain an SSL context that implements the given protocol, optionally by consulting only the given provider. In Suns implementation of JSSE, the protocol must be TLS, TLSv1, SSL, or SSLv3. Since later versions of the protocol can support earlier versions, the string TLS provides the most generic instance of an SSL context. If the given algorithm cannot be found, a NoSuchAlgorithmException is thrown. If the given provider cannot be found, a NoSuchProviderException is thrown. public final String getProtocol Return the protocol supported by this context. public final Provider getProvider Return the provider that supplied the implementation of this context. public final void initKeyManager[] km, TrustManager[] tm, SecureRandom random Initialize this context with the given key managers, trust managers, and random number generator. Any or all of these parameters may be null , in which case default, internal implementations are used. If the context cannot be initialized, a KeyManagementException is thrown. public final SSLSocketFactory getSocketFactory Return a factory that produces SSL sockets based on the parameters of this context. public final SSLServerSocketFactory getServerSocketFactory Return a factory that produces SSL server sockets based on the parameters of this context. Typically, you use an SSL context so you can specify a new key manager or trust manager in the init method. Well see how to do that next.

14.4.1 Working with Key Managers

In our first server, we used the default key manager. The default key manager reads the keystore specified by the javax.net.ssl.keyStore property and finds the first alias in that keystore that has a key appropriate for use with the algorithm the server socket wants to use. Details on how the server socket selects an algorithm are given later in this chapter, but in essence the server will find the first RSA key or the first DSA key, and so on. The alias that is chosen is arbitrary, as it depends upon the order in which the aliases are returned via a hashtable enumeration.