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

[Chris Burdess]

-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFA/5lb6dl1DEqHgrgRAoeoAJ0fyxMekKxTld/2mxhy9deLqvkhcACff2X9
ZnjgIgeGJ3OirGeBlAr8jrg=
=xNZ2
-----END PGP SIGNATURE-----