Skip to main content

Is connection encrypted?

  6 posts   Feedicon  
Replies: 5 - Last Post: August 27, 2012 04:33
by: Bill Shannon
showing 1 - 6 of 6
Posted: August 15, 2012 15:43 by thking
Hi all,

I am currently using Javamail to connect to an IMAP server. For this I have set some properties such as mail.imap.starttls.enable to true. So, if I connect to an IMAP server that is capable of STARTTLS the connection will be encrypted. Unfortunately, the API does not provide any easy to use call to detect if a connection is encrypted or not.

Based on this I have two questions:
1. Do I miss an API call that tells me if the underlying connection of a (IMAP)Store is encrypted?
2. Would it make sense to enhance the Javamail API so that developers can easily learn if a underlying connection of a (IMAP)Store is encrypted? For me it makes sense to show to users of my application whether or not the connection is encrypted.

I am looking forward to read your comments on this.

Best regards,
Posted: August 16, 2012 00:17 by Bill Shannon
It's more complicated than that...

I could certainly add a way to find out if an SSL connection was requested, or if STARTTLS succeeded,
but that doesn't tell the whole story. SSL supports negotiation of the crypto mechanism used, and it's
possible (although unlikely) that a mechanism could be chosen that does no encryption. Also, if the
user supplies their own socket factory, it may not be clear exactly what's happening on the connection.

As a workaround, you could set the mail.imap.starttls.required property to true. If the connection succeeds,
you'll know that STARTTLS was used. If it fails, you can set the property to false and try again, knowing
that STARTTLS won't be used.
Posted: August 16, 2012 09:06 by thking
Hi Shannon,

thank you very much for your reply. I see your point.

The current situation is quite uncomfortable from a security point of view. With the default mechanism provided by javamail I cannot be sure that a connection is secure even if I request SSL or STARTTLS. As long as we allow insecure SSL configurations this situation will prevail.

To resolve this situation I propose the following:
* Remove insecure SSL configurations from the SSLSockets (if this is possible in all cases?) or at least make the SSL / STARTTLS configurations configurable in the javamail default settings.
* Provide feedback about which encryption is used via an API to the developers

What do you think about this?

Posted: August 16, 2012 21:22 by harbulot
  • Remove insecure SSL configurations from the SSLSockets (if this is possible in all cases?)

The insecure cipher suites (including those will null encryption) are not enabled the default JSSE configuration:

If you need to can wrap/create your own SSLSocketFactory and make more restrictive settings via setEnabledCipherSuites in createSocket before returning it. This would also allow you to choose which encryption is used. There is a property to specify the SSLSocketFactory

I'm not really convinced about the need for feedback at this stage: either the connection succeeds with the parameters you've set and with the cipher suite requirements you've set, or it fails (especially with starttls.required=true). Simply don't proceed at all with the connection if it doesn't meet the requirements you've configured.

I've also just had a quick look in the code, and one of the features that seems to be missing is the host name verification, which is required to prevent active MITM attacks. This could be addressed without any modification to Javamail when using JRE 7: use an SSLSocketFactory that wraps the default one (or whatever you need), but before returning the socket, set the following:

SSLParameters sslParams = new SSLParameters();

This should make use of the X509ExtendedTrustManager introduced in Java 7, using the HTTPS way of verifying the host name. There doesn't seem to be an IMAPS host name verifier, but the HTTPS rules for verifying the host name should be sufficient. It's better than nothing anyway.

Posted: August 26, 2012 15:14 by harbulot

Sorry, about the host name verification, I hadn't noticed, but you you should be able to set ssl.checkserveridentity to true. It's unfortunate that it seems to be false by default.

Perhaps an area for improvement in JavaMail would be the default values and the way errors in configuration are handled.

For example, it's quite easy not to configure an SSLSocketFactory properly, either via a mistake in the parameter name, or by assuming that it will be called in a certain way when it's not. I had initially made the incorrect assumption that using ssl.socketFactory.class would try to instantiate the class from a no-argument constructor, whereas it needs a getDefault() static method (this makes sense for the abstract, but this isn't obvious when providing the a custom concrete class. The problem is that the SocketFetcher fails silently on this and comes back to the default value.

Posted: August 27, 2012 04:33 by Bill Shannon
Many of the defaults are to maintain compatibility with previous versions.
Probably some of the defaults should be reconsidered for JavaMail 1.5.
showing 1 - 6 of 6
Replies: 5 - Last Post: August 27, 2012 04:33
by: Bill Shannon
Please Confirm