Bringing this back to Java:
There are two server-side issues here, and probably more client-side
ones. Server side:
1) Which computer is this program running on?
Operating systems, and OS X is no exception, generally don't have a
good answer to this question. To answer this, I favor using uuid to
generate a unique ID for the machine, and storing that ID in some
well-known place. In the UpLib system, for Darwin and Linux, I store
this in /etc/uplib-machine-id, creating it if it doesn't already
exist. On Windows, I use the FQDN. Is there a better pure-Java
solution to this issue?
Note that this is different from "which names could the IP addresses
for this computer have?", which is either fairly easy to answer, in
the case of static IP addresses, or fairly unanswerable, in the case
of dynamically assigned IP addresses.
2) What hostname does the client think it's connecting to?
This generates most of the problems, due to the simplistic
last-century idea baked into HTTPS, that the server should know the
name the client will talk to it as, and present a certificate for that
name in the SSL handshake. It breaks because, for example, the client
can say "foo", and it gets expanded to "foo.parc.com" implicitly, or
the server can have multiple names for the same IP address. Marko
Hantula suggested, "If you had control over the clients you could also
force them to send the server name in the TLS extensions, that way
you'd immediately know which cert to present to the client." Which is
a great idea, but please tell me how to do that from the server side
with a Java framework?
Client side (Java clients):
1) What name will the server be using in its cert?
The hostname in the server's certificate may be a well-known variant
of the name you connected to. This can be addressed for
HttpsURLConnection by a custom hostname verifier. We include a class
called com.parc.uplib.util.PARCAwareCertHostnameVerifier in UpLib,
which understands the variants used at PARC, and OKs a cert hostname
if it's an approved variant of the hostname you connected to (because
the server shifted networks without restarting the service). It would
be nice to see standard Java have some version of this, possibly
accepting a RE to match against.
2) How can I stop thinking of certs?
Lots of times, client-side, you want to ignore the details of the
server's certificate, and just use the SSL for session encryption.
Not really safe to do that, but that's what most client-side programs
in other languages do. How to make that happen in Java? Took me a
while to find out, but the results (a custom X509TrustManager) are now
encapsulated in com.parc.uplib.util.CertificateHandler. This gives
you an API that allows you to ignore hostname mismatches, or ask the
user about certificates that can't be verified automatically, or
ignore unverifiable certs, or a few other things.
(These Java classes are indirectly available from
http://uplib.parc.com/ via the beta-test program; building UpLib from
source is not for the squeamish, but feel free to register on the blog,
which automatically adds you to the beta-test group.)
Bill
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
