Open-Xchange broken after Update to 7.8.3 Rev5

Today I updated my Open-Xchange instance to the newest version 7.8.3-5. The upgrade worked as normal, except that I had some update-conflicts in the config files, as I adjusted some values in them – but hey, this is unfortunately normal for Open-Xchange. But after the update, I could not log into Open-Xchange because of a “temporary error on the server” (LGI-0003).

As this message didn’t tell me too much, I opened the Open-Xchange log file and found a stacktrace:

com.openexchange.exception.OXException: LGI-0003 Categories=ERROR Message='Unknown problem: "STARTTLS failure".' exceptionID=491740714-4
        [...]
Caused by: javax.mail.MessagingException: STARTTLS failure
        at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:922)
        at javax.mail.Service.connect(Service.java:366)
        at com.openexchange.authentication.imap.impl.IMAPAuthentication.handleLoginInfo(IMAPAuthentication.java:378)
        ... 48 common frames omitted
Caused by: com.sun.mail.iap.ProtocolException: STARTTLS failure
        at com.sun.mail.imap.protocol.IMAPProtocol.startTLS(IMAPProtocol.java:1433)
        at com.sun.mail.imap.IMAPStore.login(IMAPStore.java:959)
        at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:886)
        ... 50 common frames omitted
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
        at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1989)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1096)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1342)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1369)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1353)
        at com.openexchange.tools.ssl.DelegatingSSLSocket.startHandshake(DelegatingSSLSocket.java:390)
        at com.sun.mail.util.SocketFetcher.configureSSLSocket(SocketFetcher.java:598)
        at com.sun.mail.util.SocketFetcher.startTLS(SocketFetcher.java:525)
        at com.sun.mail.iap.Protocol.startTLS(Protocol.java:465)
        at com.sun.mail.imap.protocol.IMAPProtocol.startTLS(IMAPProtocol.java:1419)
        ... 52 common frames omitted

In my Open-Xchange setup, the Open-Xchange server authenticates against an IMAP server using the user’s standard mail address and the password entered on the UI. So this stacktrace told me, that the server tried to do this authentication when I tried to log in on the web-UI, but failed to establish a secure connection to the IMAP server.

Unfortunately this stacktrace did not tell too much about the real cause and therefore I tried to debug the error by raising the log level for SSL connections in my IMAP server. This also did not lead to more knowledgle on the problem except that I found out that ECDHE is used for the connection.

My next guess was some change in the JVM causing the server to miss some protocols or cipher suites. Unfortunately I could not find any problem here as even the Java Cryptography Extensions (JCE) were installed.

After some time I found some (new??) configuration options in Open-Xchange’s config file /opt/open-xchange/etc/imap.propertiesconcerning the SSL/TLS protocols and ciphers for IMAP connections:

  • com.openexchange.imap.ssl.protocols
  • com.openexchange.imap.ssl.ciphersuites

Apparently the default values (empty string) for those two config options prevented Open-Xchange to establish the secure connection. Next, I tried to find the correct values for the options. For the protocols option, the possible values were simple to find, as those are taken from the constants in the Java class sun.security.ssl.ProtocolVersion. In my case I chose TLSv1 TLSv1.1 TLSv1.2.

The value for the ciphersuites config option was harder to find. From the comment for the option, I found out, that an empty value for the option should make Open-Xchange use the default ciphers of the JVM but unfortunately this didn’t seem to work. Therefore I decided to find the default cipher suites and list them manually. For this, I coded a small Java class, that printed the default and additionally available cipher suites and executed it on my server (javac Ciphers.java ; java Ciphers):

import javax.net.ssl.SSLServerSocketFactory;
import java.util.Arrays;
import java.util.HashSet;
import java.util.Set;

public class Ciphers {
    public static void main(String[] args)
            throws Exception {
        SSLServerSocketFactory ssf = (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();

        System.out.println("Default Ciphers:");
        Set<String> defaultCiphers = new HashSet<>();
        defaultCiphers.addAll(Arrays.asList(ssf.getDefaultCipherSuites()));
        for (String c : defaultCiphers) {
            System.out.print(c);
            System.out.print(" ");
        }
        System.out.println();
        System.out.println();


        System.out.println("Additionally available Ciphers:");
        String[] availableCiphers = ssf.getSupportedCipherSuites();
        for (String c : availableCiphers) {
            if (defaultCiphers.contains(c)) {
                continue;
            }

            System.out.print(c);
            System.out.print(" ");
        }

    }
}

Setting both configuration options manually solved the problem for me. For my Debian system, the final configuration that fixed the error was:

com.openexchange.imap.ssl.protocols=TLSv1 TLSv1.1 TLSv1.2
com.openexchange.imap.ssl.ciphersuites= SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 TLS_EMPTY_RENEGOTIATION_INFO_SCSV TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.