CS 5430 Spring 2016 A5 Problem 2

Step 1. Build a simple socket application

Compile and execute EchoServer.java and EchoClient.java with the following commands:

In one terminal:

javac EchoServer.java

javaEchoServer

In another terminal:

javac EchoClient.java

javaEchoClient

Now type some text into the client. It will be echoed by the server.

Answer the following questions:

  1. In EchoClient.java, what line(s) of code causes the text to be sent over the network?
  2. In EchoServer.java what line(s) of code receive the text that is sent over the network?

Step 2. Change the Echo server and client to use SSL

Change SocketFactory.getDefault()in EchoClient.java to SSLSocketFactory.getDefault(). Also change ServerSocketFactory.getDefault()in EchoServer.java to SSLServerSocketFactory.getDefault().

Now recompile and run the EchoServerand EchoClientas in step 1. Something will go wrong.

Answer the following questions:

  1. What exception is raised? What line of code in EchoServer.java raises it?

Although it’s probably not very clear from the error message and documentation, the underlying problem is that your server a certificate that your client is willing to trust.

Step 3. Equip the server with an RSA key pair

  1. Generate an RSA key pair and store it as a certificate in a Java keystore:

$ keytool -genkeypair -alias mykey -keyalg RSA \

-keystorekeystorefilename.jks

You may replace mykey and keystorefilename with strings of your choice. keystorefilename.jks is the name of the keystore file that the command will create (or modify, if the file already exists). A keystore may contain many certificates, each of which is named by an “alias.” So mykey is the name that will be given to the particular certificate you are creating in keystorefilename.jks.

You will be prompted to create a password for the keystore, to enter your distinguished name, and to create a password for the key pair itself.

Check your work by running the following command to examine the keystore:

$ keytool -list -v -keystorekeystorefilename.jks

Then:

Answer the following questions:

  1. What is the serial number of the certificate?
  1. What is the entry type of the certificate?
  1. What is the common name (CN) of the certificate owner?
  1. What is the common name (CN) of the certificate issuer?
  1. When does the certificate’s validity expire?
  1. Try entering an incorrect password. What happens? What can you infer about whether the password is being used for purposes of confidentiality or integrity?
  1. Tell the server how to access the keystore by adding the following code to EchoServer.java immediately before the construction of the SSLServerSocketFactory:

System.setProperty("javax.net.ssl.keyStore", "keystorefilename.jks");

System.setProperty("javax.net.ssl.keyStorePassword", "password");

Answer the following questions:

  1. Do you think it is generally a good practice to hardcode passwords in source code?
  1. Suggest an alternative implementation that doesn’t involve hardcoding the keystore password.
  1. Recompile and run the EchoServer as in step 1. It should now successfully start and wait for the client to connect.

Run the EchoClient as in step 1. Something will go wrong.

Answer the following questions:

  1. The exception raised is SSLHandshakeException. What line of code in EchoClient.java raises it?
  1. Consult the documentation of that exception. (The API documentation is at this URL: What does the exception signal?

Step 4. Equip the client with the server’s public key

  1. Export the server’s certificate (including the server’s public key, but excluding the server’s private key):

$ keytool -export -alias mykey\

-keystorekeystorefilename.jks\

-rfc -file certfilename.cer

You may replace certfilename with a string of your choice.

  1. Import the certificate into a Java truststore. A truststore is like a keystore except that it doesn’t contain any private keys. (But note that keytool will refer to the truststore as a “keystore”, which is a little confusing.)

$ keytool -import -alias mykey\

-filecertfilename.cer \

-keystoretruststorefilename.jks

You may replace truststorefilenamewith a string of your choice. You will be prompted to create a password for the new truststore. It may differ from the password you chose for the original keystore. The certificate will be displayed, then you will be asked whether to “trust” the certificate. Answer yes, and the certificate will be added to the truststore.

  1. Check your work by running the following command to examine the truststore:

$ keytool -list -v -keystoretruststorefilename.jks

Then:

Answer the following questions:

  1. What is the entry type of the certificate?
  1. Comparing the truststore to the keystore, did the serial number of the certificate change? Did its fingerprint change?
  1. Tell the client how to access the truststore by adding the following code to EchoClient.java immediately before the construction of the SSLSocketFactory:

System.setProperty("javax.net.ssl.trustStore", "truststorefilename.jks");

System.setProperty("javax.net.ssl.trustStorePassword", "password");

  1. Recompile and run the EchoClient as in step 1. (Don’t forget to have the EchoServer running, too.)
  1. Congratulations! You have secured the connection between the client and server with SSL.

Step 5. Investigate the crypto

  1. There’s a debug flag for Java’s SSL implementation that you can set. Rerun the client and server, but run the client as follows:

$ java -Djavax.net.debug=sslEchoClient

Answer the following questions by examining the debug output:

  1. What is the SSL cipher suite that is used by the client and server? You will find it as part of the “ServerHello” message on a line that begins “Cipher Suite: ”.
  1. What is the serial number of the trusted certificate, according to the debug output? Is it the same or different than the certificate you put in the truststore?
  1. What kind of key is in the trusted certificate, and what is its size? Is that size reasonable according to the NIST recommendations on key size?
  1. Find the “Master Secret.” According to section 6.3 of the TLS 1.2 spec [RFC 5246], what is the purpose of the Master Secret?
  1. What are the first few bytes of the Master Secret used in your SSL session? If you run the applications again, does the Master Secret change? Suggest a reason why or why not.