Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #22683 > unrolled thread

Adding hostname verification to SSLSocket

Back to article view | Back to comp.lang.java.programmer

Contents

  Adding hostname verification to SSLSocket Ian Pilcher <arequipeno@gmail.com> - 2013-03-02 13:02 -0600
    Re: Adding hostname verification to SSLSocket Roedy Green <see_website@mindprod.com.invalid> - 2013-03-04 12:38 -0800
    Re: Adding hostname verification to SSLSocket Arne Vajhøj <arne@vajhoej.dk> - 2013-03-06 21:46 -0500

#22683 — Adding hostname verification to SSLSocket

I am working with a library that can use an application-provided
SSLSocketFactory to create its SSL connections.  I would like to ensure
that all of its connections enforce hostname verification, which the
default SSLSocket implementation does not do.

It's tempting to simply write an SSLSocketFactory that does the hostname
verification in its various createSocket(...) methods, but this
obviously won't cover the case where a socket is created in an
unconnected state with createSocket() and connected later.  (It's also
not at all clear from the documentation that connect(...) can't be
called on a connected socket to connect it to a different server.)

So it seems that doing this the "right" way is going to require an
SSLSocket implementation -- something like this:

  public final class HostVerifyingSSLSocketextends SSLSocket
  {
      private final SSLSocket socket;
      private final HostnameVerifier verifier;

      public HostVerifyingSSLSocket(SSLSocket socket,
                                    HostnameVerifier verifier)
              throws SSLHandshakeException
      {
          this.socket = socket;
          this.verifier = verifier;
          if (socket.isConnected()) {
              verify();
          }
      }

      private void verify() throws SSLHandshakeException
      {
          SSLSession session = socket.getSession();
          if (!verifier.verify(session.getPeerHost(), session)) {
              IOException closeException = null;
              try {
                  socket.close();
              } catch (IOException ioe) {
                  closeException = ioe;
              }
              SSLHandshakeException she =
                      new SSLHandshakeException("Bummer");
              if (closeException != null) {
                  she.addSuppressed(closeException);
              }
              throw she;
          }
      }

      // Delegate all Socket and SSLSocket methods to socket ...


The question is which of the delegated methods need a call to verify().
I'm thinking that connect(), startHandshake(), and getSession() are the
only methods that need this.  (And getHandshakeSession() is right out.)

      public void connect(SocketAddress endpoint) throws IOException
      {
          socket.connect(endpoint);
          verify();
      }

      public void connect(SocketAddress endpoint, int timeout)
              throws IOException
      {
          socket.connect(endpoint, timeout);
          verify();
      }

      public void startHandshake() throws IOException
      {
          socket.startHandshake();
          verify();
      }

      public SSLSession getSession()
      {
          try {
              Session session = socket.getSession();
              validate();
              return session;
          } catch (SSLHandshakeException she) {
              return ERROR_SESSION;  // Need to create this. Uugh.
          }
      }

      public SSLSession getHandshakeSession()
      {
          throw new UnsupportedOperationException("Sorry");
      }

Any others?  Anyone see any fundamental problem with this approach
(other than the fact that it's a ton of mostly boilerplate code to work
around the fact that HandshakeCompletedListener.handShakeCompleted(...)
isn't allowed to throw a checked exception)?

Thanks!

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================

[toc] | [next] | [standalone]

#22715

On Sat, 02 Mar 2013 13:02:51 -0600, Ian Pilcher <arequipeno@gmail.com>
wrote, quoted or indirectly quoted someone who said :

> I would like to ensure
>that all of its connections enforce hostname verification, which the
>default SSLSocket implementation does not do.
 

Are you sure about that?  IIRC I had the opposite problem link
checking with links with a mismatch considered bad.  Mis-matches are
extremely common, particularly for large companies with many servers.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
One thing I love about having a website, is that when I complain about
something, I only have to do it once. It saves me endless hours of 
grumbling.

[toc] | [prev] | [next] | [standalone]

#22761

On 3/2/2013 2:02 PM, Ian Pilcher wrote:
> I am working with a library that can use an application-provided
> SSLSocketFactory to create its SSL connections.  I would like to ensure
> that all of its connections enforce hostname verification, which the
> default SSLSocket implementation does not do.
>
> It's tempting to simply write an SSLSocketFactory that does the hostname
> verification in its various createSocket(...) methods, but this
> obviously won't cover the case where a socket is created in an
> unconnected state with createSocket() and connected later.  (It's also
> not at all clear from the documentation that connect(...) can't be
> called on a connected socket to connect it to a different server.)
>
> So it seems that doing this the "right" way is going to require an
> SSLSocket implementation -- something like this:

> Any others?  Anyone see any fundamental problem with this approach
> (other than the fact that it's a ton of mostly boilerplate code to work
> around the fact that HandshakeCompletedListener.handShakeCompleted(...)
> isn't allowed to throw a checked exception)?

If you are using SSL for HTTPS, then I think that
HttpsURLConnection.setDefaultHostnameVerifier would be obvious. But
I assume that is not the case.

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web