[Top][All Lists]

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

[Classpath-inetlib] imap and ssl, again

From: Ruben Malchow
Subject: [Classpath-inetlib] imap and ssl, again
Date: Thu, 22 Jul 2004 00:00:26 +0200
User-agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)


i've read the thread from the last days. and i really have to agree with daniel. imap-over-ssl is basically nothing but a tunnel (i could run a ssh tunnel and would be effectively the same thing) and changes nothing whatsoever in the protocol - apart from maybe the fact that you might be less concerned about the security of the authentication mechanism, because of the transport layer being encrypted, and possibly trusted client- and server certificates might be required, this is a configuration- and not a basic design issue.

however, i could live with that, although it limits interoperability and would really appreciate the possibility to do everything from the first HELO to the last QUIT encrypted.

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.

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.

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?

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.

thanks for reading


reply via email to

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