[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Classpath-inetlib] imap and ssl, again

From: Chris Burdess
Subject: Re: [Classpath-inetlib] imap and ssl, again
Date: Thu, 22 Jul 2004 11:39:22 +0100

Hash: SHA1

Ruben Malchow wrote:
i've read the thread from the last days. and i really have to agree with daniel.

OK, it looks like my opinion is pretty unpopular, so I'm going to add non-negotiated IMAP over SSL via a constructor.

i cannot live with these lines from the inetlib 1.0 source, however:

// We don't require strong validation of the server certificate
TrustManager[] trust = new TrustManager[1];

if we didn't need it, we wouldnt use it. but apparently chris has fixed this in the cvs (didnt check out yet). the gnumail providers now honour the mail.trustmanager property. i would suggest the default trustmanager (if the property is not set) should be most resrictive.

The most restrictive would reject all certificates. The starttls method with no arguments would be redundant; you couldn't use it.

now, the next problem arises, and it might be one that might be a little off-topic here, because it actually is in parts a gnu mail thing:

i have different users on the same app, each with their own keystore .... it's supposed to become a webmail app when it's ready, and there are potentially multiple instances of this (web)app in the same vm (i've given up using singletons all over the place years ago), so knowing the username and the classname of the trustmanager doesn't get the job done. i need to know more: i need to give the trustmanager information not only on what trustmanager to use, but for what user on what instance of the webmail app. basically, the webmail session is the only place where i know the right parameters for the keystore.

of course, this is a very specific problem, but not an uncommon one from what i googled.

so. my last approach was to use the properties mail.keystore (a path to a keystore) and mail.keystorePassword (the corresponding, and optional password to use) to instatiate a keystore and a trustmanager using this keystore. chris convinced me it's much better to go for the trustmanager directly, because it can provide a lot of other things you might want to use in this context (such as collecting untrusted certificates you want to present to the user later to let him do the decision). but: it still needs to know what keys to use and where to get them from.

We could provide the ability to specify a KeyManager as well. This would only be useful, though, if the server used SSL authentication to authenticate the user. In my experience that hasn't been the case, although perhaps it's a feature server vendors are starting to implement? However, the IMAPConnection would need to intercept that exchange in order to determine whether authentication had taken place, so you couldn't simply provide a configured SSLContext.

the current property is mail.trustmanager which is set to a classname implementing a trustmanager. in this naming scheme, we might want to use mail.trustmanager.XXX properties, or does anyone else have an idea for a different approach to solving this problem?

The real problem is that Session only deals with string properties. Otherwise you could bind a fully-configured TrustManager into the session. Having mail.trustmanager.XXX properties sounds like a feasible workaround.

and (sorry to bring that up again): wouldnt it be nice to have a constructor for FOOConnection that takes an optional SSLContext parameter? yes, this would be a first step towards giving all connections the ability to tunnel themselves over ssl.

Are there use cases for this (tunnelling other inetlib protocols over SSL)? - -- Chris Burdess
Version: GnuPG v1.2.4 (Darwin)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]