Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4773451

Support IP address based virtual hosting in default KeyManager implementation

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Not an Issue
    • P4
    • None
    • 1.4.0
    • security-libs

    Description



      Name: nt126004 Date: 11/04/2002


      FULL PRODUCT VERSION :
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
      Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)


      FULL OPERATING SYSTEM VERSION : Linux version 2.2.20 (gcc
      version egcs-2.91.66 19990314/Linux (egcs-1.1.2
      release))

      patched redhat 6.1


      A DESCRIPTION OF THE PROBLEM :
      When using multiple SSLServerSockets with each listening on
      it's own IP address, the JVM is not correctly sending the
      correct certificate to the connecting client's web browser.
       Regardless of which domain/IP the browser attempts to
      connect to, the JVM always maps the domain/IP for the first
      listed certificate in the keystore.

      Example: domains abc.com, def.com, ghi.com each have their
      own self-signed certificate in keystore , each created using
      'keytool -genkey' and created in same order. Each also
      being domain mapped to their own IP address and served
      through their own SSLServerSocket.

      When a client attempts to connect to abc.com, all is well.
      The correct certificate is presented to the client and
      connection succeeds. However, when the client attempt to
      connect to either def.com or ghi.com, they are presented
      with the certificate for abc.com.

      If client connecting to def.com or ghi.com elects to accept
      that incorrect certificate, connection succeeds to proper
      site, despite use of incorrect certificate. So correct
      domain/IP mapping is not the issue.


      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      1. map 2 different domains to different IP's
      2. use keytool -genkey to create certificates for both
      3. write simple listeners using SSLServerSocket at each domain
      4. attempt to connect to each domain with a web browser
      (I've tried Mozilla, Netscape and IE) and pay attention to
      the certificate presented.

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      Expected: client should be presented with the proper
      certificate for the domain being connected to.

      Actual: client is presented with the first certificate in
      the keystore.

      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------

      import javax.net.*;
      import javax.net.ssl.*;
      import java.net.*;


      public class TestSSLServer extends Thread implements Runnable
      {

      private static String[] arg;



      public TestSSLServer()
      {
      }



      /**
      * Pass in the 2 domain names to listen at.
      */
      public static void main(String argv[])
      {
      arg = argv;
      // startup the one and only thread of this class
      new Thread(new TestSSLServer()).start();
      }



      public void run()
      {
      try
      {
      ServerSocketFactory factory = SSLServerSocketFactory.getDefault();

      // create socket 1
      ServerSocket s1 = factory.createServerSocket(443, 1, InetAddress.getByName(arg[0]));
      TcpServer ts1 = new TcpServer(s1);
      ts1.start();

      // create socket 2
      ServerSocket s2 = factory.createServerSocket(443, 1, InetAddress.getByName(arg[1]));
      TcpServer ts2 = new TcpServer(s2);
      ts2.start();

      sleep(60000);
      }
      catch(Throwable t)
      {
      t.printStackTrace();
      }

      }



      class TcpServer extends Thread
      {
      private ServerSocket ss;


      public TcpServer(ServerSocket p_ss)
      {
      ss = p_ss;
      }

      public void run()
      {
      try
      {
      while(true)
      {
      Socket newSocket = ss.accept();
      newSocket.getOutputStream().write("hello".getBytes());
      }
      }
      catch(Throwable t)
      {
      t.printStackTrace();
      }
      }
      }
      }


      ---------- END SOURCE ----------

      CUSTOMER WORKAROUND:
      We did find a work around with help from hot dispatch. We ended up creating
      a key store for each domain that we want to serve a https connection for. It
      would be easier if we could put all the keys in one key store per the bug
      report and have JVM manage the keys correctly. I guess this is longer
      critical for us since we were able to work around it.
      (Review ID: 163381)
      ======================================================================

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              nthompsosunw Nathanael Thompson (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: