hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject random SSL related stuff
Date Wed, 27 Dec 2006 18:02:10 GMT
Hi folks,

while hacking up a patch for HTTPCLIENT-475, I stumbled about
a few details. These are not urgent, but I'd like to write them
down now before I forget something.

1) HostnameVerifier
We have an interface with that name, and standard Java has one
too in javax.net.ssl. Both define methods called verify() that
check whether a hostname is acceptable with respect to presented
certificates and such. Although they all share the same name,
the standard Java method returns a boolean, while ours throw an
exception if the verification fails.
This is BAD. As in REALLY bad. Somebody gets used to the exception
being thrown, then someday calls the standard Java method without
noticing the difference, and a verification failure will just go
unnoticed!
Now I don't mind throwing an exception instead of returning a
boolean. It allows for an error message that tells about the
exact reason for the verification failure. But giving these methods
the same name as the original method with a completely different
usage pattern is not good. We must find a different name to point
out the different usage pattern. Maybe check(...) or assert(...)
or whatever, but not verify(...).

2) SocketFactory
We have an interface with that name, and standard Java since 1.4
has one too in javax.net. The PlainSocketFactory implementation
I modified for HTTPCLIENT-475 uses java.net directly, without the
factory. The SSLSocketFactory uses the standard SSLSocketFactory.
We could/should provide a non-SSL socket factory that uses the
standard SocketFactory interface. I'm not sure whether this should
be done directly in PlainSocketFactory, or whether we should leave
the plain one as it is and have another one.

3) SecureSocketFactory
The interface SecureSocketFactory is meant to create SSL socket
connections. These are considered to be secure, while connections
created directly from SocketFactory are considered insecure. I see
two problems with this tie-in, where the second one is the bigger:
- A SocketFactory might create secure connections by using for
  example native code. Since native code would not be able to
  layer a connection on top of a Java socket, the factory could
  not (fully) implement the SecureSocketFactory interface.
- A SecureSocketFactory might create SSL connections that should
  not be considered secure, because security depends on the cipher
  suite that is chosen.
I would prefer to untie those two aspects and introduce a method
to check/indicate whether a specific connection is secure or not.
The special thing about SecureSocketFactory is that it can layer
a connection on top of an existing one. Renaming the interface to
LayeredSocketFactory would be an option.


cheers,
  Roland


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message