Service Packs and Hot Fixes
  1. Service Packs and Hot Fixes
  2. MNT-6968

Inbound email supports STARTTLS by default - however this requires Java + SSL configuration to be done to work

    Details

    • Type: Service Pack Request Service Pack Request
    • Status: Closed Closed (View Workflow)
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.2 R
    • Fix Version/s: 4.0
    • Component/s: Repository
    • Labels:
      None
    • ACT Numbers:

      17170

      Description

      Inbound email supports STARTTLS by default - however this requires Java + SSL configuration to be done to work.

      Basically when you connect to the inbound subethamail ESMTP service it reports it supports STARTTLS:

      [root@ts1 ~]# telnet 0 2525
      Trying 0.0.0.0...
      Connected to 0 (0.0.0.0).
      Escape character is '^]'.
      220 ts.alfresco.com ESMTP SubEthaSMTP
      EHLO foo
      250-ts.alfresco.com
      250-8BITMIME
      250-STARTTLS
      250 Ok

      However if the user has not configured Java + SSL in his JVM as described here: http://stilius.net/java/java_ssl.php

      STARTTLS negotiation will fail. The java logs show:

      12:23:09,349 DEBUG [org.subethamail.smtp.server.ConnectionHandler] SMTP connection count: 1
      12:23:09,351 DEBUG [org.subethamail.smtp.server.ConnectionHandler] Server: 220 ts.alfresco.com ESMTP SubEthaSMTP
      12:23:09,486 DEBUG [org.subethamail.smtp.server.ConnectionHandler] Client: EHLO mx-out-manc3.simplymailsolutions.com
      12:23:09,487 DEBUG [org.subethamail.smtp.server.ConnectionHandler] Server: 250-ts.alfresco.com
      250-8BITMIME
      250-STARTTLS
      250 Ok
      12:23:09,504 DEBUG [org.subethamail.smtp.server.ConnectionHandler] Client: STARTTLS
      12:23:09,504 DEBUG [org.subethamail.smtp.server.ConnectionHandler] Server: 220 Ready to start TLS
      12:23:10,075 WARN [org.subethamail.smtp.command.StartTLSCommand] startTLS() failed: no cipher suites in common
      javax.net.ssl.SSLHandshakeException: no cipher suites in common
      at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1611)
      at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187)
      at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:177)
      at com.sun.net.ssl.internal.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:638)
      at com.sun.net.ssl.internal.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:425)
      at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:139)
      at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
      at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1139)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123)
      at org.subethamail.smtp.command.StartTLSCommand.execute(StartTLSCommand.java:57)
      at org.subethamail.smtp.server.CommandHandler.handleCommand(CommandHandler.java:58)
      at org.subethamail.smtp.server.ConnectionHandler.run(ConnectionHandler.java:113)
      12:23:10,076 DEBUG [org.subethamail.smtp.server.ConnectionHandler] Server: 450 Problem attempting to execute commands. Please try again later.
      12:23:10,076 DEBUG [org.subethamail.smtp.server.ConnectionHandler] java.net.SocketException: Socket closed

      I have logged DOC-137 to include the SSL config as a doc note or whatever. I've also updated the wiki here: http://wiki.alfresco.com/wiki/Inbound_Email_Server_Configuration#StartTLS_Support

      I've raised this ticket as a behavioural change suggestion. I figure STARTTLS should be disabled by default, and users should have the option to turn it on in a properties file if they so require it. This would avoid the extra configuration. STARTTLS is not mandatory and most mail servers will happily send email with clear text.

      Also - if possible - regardless of what the user sets - the SMTP service should not report STARTTLS if it knows SSL has not been configured.

      Let me know if this doesn't make sense.

        Issue Links

          Activity

          Hide
          Scott Ashcraft added a comment -

          More information from the customer:
          subethasmtp now lives at http://code.google.com/p/subethasmtp/.
          At that location, there are the latest three versions available:

          Version 3.1.1 August 2009

          • implements a hideTLS property that, when set to true, suppresses the display of the STARTTLS.
            Version 3.1.2 Oct 24 2009
          • adds a requireTLS property that allows turning off TLS.
            Version 3.1.3 Feb 11 2010
          • unrelated fix

          I haven't seen yet where/how the properties are set. But it
          seems Alfresco could satisfy the JIRA issue ALF-1966 by upgrading
          to the latest subethasmtp jar subethasmtp-3.1.3.jar

          --------

          new properties:
          requireTLS
          hideTLS

          In invoking class:

          SMTPServer smtpServer = new org.subethasmtp.smtp.server.SMTPServer(...);
          smtpServer.setRequireTLS( getPropertyValue(requireTLS, true/false));
          smtpServer.setHideTLS( getPropertyValue(hideTLS, true/false));

          String getPropertyValue(String key, String default)

          { //try to get property, if not found use default String value = <PropertyLookup(key)>; if (value == null) value = default; return value; }
          Show
          Scott Ashcraft added a comment - More information from the customer: subethasmtp now lives at http://code.google.com/p/subethasmtp/ . At that location, there are the latest three versions available: Version 3.1.1 August 2009 implements a hideTLS property that, when set to true, suppresses the display of the STARTTLS. Version 3.1.2 Oct 24 2009 adds a requireTLS property that allows turning off TLS. Version 3.1.3 Feb 11 2010 unrelated fix I haven't seen yet where/how the properties are set. But it seems Alfresco could satisfy the JIRA issue ALF-1966 by upgrading to the latest subethasmtp jar subethasmtp-3.1.3.jar -------- new properties: requireTLS hideTLS In invoking class: SMTPServer smtpServer = new org.subethasmtp.smtp.server.SMTPServer(...); smtpServer.setRequireTLS( getPropertyValue(requireTLS, true/false)); smtpServer.setHideTLS( getPropertyValue(hideTLS, true/false)); String getPropertyValue(String key, String default) { //try to get property, if not found use default String value = <PropertyLookup(key)>; if (value == null) value = default; return value; }
          Hide
          Fabrizio Corsaro added a comment -

          Customer comment:

          Regarding JIRA issue#ALF-1966

          I was able to get the latest version of subethasmtp to work with Alfresco 3.2. By making changes to subethasmtp, I was able to turn TLS off. The only catch was, I had to remove an interface method org.subethamail.smtp.MessageHandler.done() that Alfresco doesn't yet implement. Other than that, it appears to work just fine.

          So, I think the following changes in Alfresco would allow optional use of TLS:

          Two relevant changes in newer subethasmtp versions:
          1. change: interface org.subethamail.smtp.MessageHandler has a new method void done().
          2. change: class org.subethamail.smtp.SMTPServer supports two new properties:
          boolean requireTLS;
          boolean hideTLS;
          (this would benefit from a third flag (allowTLS) which if set to false, would result
          in the STARTTLS command returning 454 instead of trying to change socket to use SSL).

          Alfresco fix:
          A. include new jar subethasmtp-3.1.1.jar, replacing existing jar subetha-smtp.jar.

          B. modify class org.alfresco.email.server.impl.subetha.SubethaEmailServer:
          1. add method done() to nested class Handler
          void done() { }

          2. add two new properties
          private boolean requireTLS = false; // the default in case no is property found
          private boolean hideTLS = true; // the default in case no is property found

          3. set the above properties from values found in an appropriate properties file

          // don't know the best property names or file, but something like:
          email.server.requireTLS=true
          email.server.hideTLS=true

          4. Use these properties to set corresponding values when instantiating SMTPServer:

          public void startup()

          { serverImpl = new SMTPServer(new HandlerFactory()); serverImpl.setPort(getPort()); serverImpl.setHostName(getDomain()); serverImpl.setRequireTLS(<email.server.requireTLS>); // <-- added serverImpl.setHideTLS(<email.server.hideTLS>); // <-- added serverImpl.start(); log.info("Email Server has started successfully"); }

          A customer who does not want to use TLS would set requireTLS to false and hideTLS to true. However, if the client still sends a STARTTLS, subethasmtp will attempt to use it. This means they must still configure for TLS. It would be preferable for the subethasmtp package to be enhanced to use an allowTLS/disableTLS flag so that if set it returns 454 when handling a STARTTLS command from the client.

          Show
          Fabrizio Corsaro added a comment - Customer comment: Regarding JIRA issue# ALF-1966 I was able to get the latest version of subethasmtp to work with Alfresco 3.2. By making changes to subethasmtp, I was able to turn TLS off. The only catch was, I had to remove an interface method org.subethamail.smtp.MessageHandler.done() that Alfresco doesn't yet implement. Other than that, it appears to work just fine. So, I think the following changes in Alfresco would allow optional use of TLS: Two relevant changes in newer subethasmtp versions: 1. change: interface org.subethamail.smtp.MessageHandler has a new method void done(). 2. change: class org.subethamail.smtp.SMTPServer supports two new properties: boolean requireTLS; boolean hideTLS; (this would benefit from a third flag (allowTLS) which if set to false, would result in the STARTTLS command returning 454 instead of trying to change socket to use SSL). Alfresco fix: A. include new jar subethasmtp-3.1.1.jar, replacing existing jar subetha-smtp.jar. B. modify class org.alfresco.email.server.impl.subetha.SubethaEmailServer: 1. add method done() to nested class Handler void done() { } 2. add two new properties private boolean requireTLS = false; // the default in case no is property found private boolean hideTLS = true; // the default in case no is property found 3. set the above properties from values found in an appropriate properties file // don't know the best property names or file, but something like: email.server.requireTLS=true email.server.hideTLS=true 4. Use these properties to set corresponding values when instantiating SMTPServer: public void startup() { serverImpl = new SMTPServer(new HandlerFactory()); serverImpl.setPort(getPort()); serverImpl.setHostName(getDomain()); serverImpl.setRequireTLS(<email.server.requireTLS>); // <-- added serverImpl.setHideTLS(<email.server.hideTLS>); // <-- added serverImpl.start(); log.info("Email Server has started successfully"); } A customer who does not want to use TLS would set requireTLS to false and hideTLS to true. However, if the client still sends a STARTTLS, subethasmtp will attempt to use it. This means they must still configure for TLS. It would be preferable for the subethasmtp package to be enhanced to use an allowTLS/disableTLS flag so that if set it returns 454 when handling a STARTTLS command from the client.
          Hide
          Frank Brown added a comment -

          I too encountered the problem mentioned above by Fabrizio: "However, if the client still sends a STARTTLS, subethasmtp will attempt to use it.".

          I supplied a patch for subethasmtp which has been incorporated into version 3.1.4.

          In subethasmtp version 3.1.4, there are now these options (all false by default):

          • default: TLS is supported and announced, but not required.
          • disableTLS=true: TLS is not supported; so obviously neither announced nor required.
          • hideTLS=true: TLS is not announced; it is supported but not required.
          • requireTLS=true: TLS is required so obviously allowed and pointless not to announce it.

          Here is an updated version of Fabrizio's
          Alfresco fix:
          ---------------------------------------
          A. include new jar subethasmtp-3.1.4.jar, replacing existing jar subetha-smtp.jar.

          B. modify class org.alfresco.email.server.impl.subetha.SubethaEmailServer:
          1. add method done() to nested class Handler
          void done() { }

          2. add three new properties
          // set TLS option defaults
          private boolean disableTLS = false;
          private boolean requireTLS = false;
          private boolean hideTLS = true/false;

          3. set the above properties from values found in an appropriate properties file

          // don't know the best property names or file, but something like:
          email.server.disableTLS=true/false
          email.server.requireTLS=true/false
          email.server.hideTLS=true/false

          (Note: as implemented in subethasmtp, only one of these properties need be set to true. It is easiest to view them collectively as a tri-valued switch, e.g. if disableTLS=true, hideTLS and requireTLS are ignored.
          set only one to true:
          disableTLS=true --> don't use TLS
          hideTLS=true --> allow but don't announce TLS
          requireTLS=true --> require TLS

          4. Use these properties to set corresponding values when instantiating SMTPServer:

          public void startup()

          { serverImpl = new SMTPServer(new HandlerFactory()); serverImpl.setPort(getPort()); serverImpl.setHostName(getDomain()); serverImpl.setDisableTLS(<email.server.disableTLS>); // <-- added serverImpl.setRequireTLS(<email.server.requireTLS>); // <-- added serverImpl.setHideTLS(<email.server.hideTLS>); // <-- added serverImpl.start(); log.info("Email Server has started successfully"); }

          ---------------------------------------

          Show
          Frank Brown added a comment - I too encountered the problem mentioned above by Fabrizio: "However, if the client still sends a STARTTLS, subethasmtp will attempt to use it.". I supplied a patch for subethasmtp which has been incorporated into version 3.1.4. In subethasmtp version 3.1.4, there are now these options (all false by default): default: TLS is supported and announced, but not required. disableTLS=true: TLS is not supported; so obviously neither announced nor required. hideTLS=true: TLS is not announced; it is supported but not required. requireTLS=true: TLS is required so obviously allowed and pointless not to announce it. Here is an updated version of Fabrizio's Alfresco fix: --------------------------------------- A. include new jar subethasmtp-3.1.4.jar, replacing existing jar subetha-smtp.jar. B. modify class org.alfresco.email.server.impl.subetha.SubethaEmailServer: 1. add method done() to nested class Handler void done() { } 2. add three new properties // set TLS option defaults private boolean disableTLS = false; private boolean requireTLS = false; private boolean hideTLS = true/false; 3. set the above properties from values found in an appropriate properties file // don't know the best property names or file, but something like: email.server.disableTLS=true/false email.server.requireTLS=true/false email.server.hideTLS=true/false (Note: as implemented in subethasmtp, only one of these properties need be set to true. It is easiest to view them collectively as a tri-valued switch, e.g. if disableTLS=true, hideTLS and requireTLS are ignored. set only one to true: disableTLS=true --> don't use TLS hideTLS=true --> allow but don't announce TLS requireTLS=true --> require TLS 4. Use these properties to set corresponding values when instantiating SMTPServer: public void startup() { serverImpl = new SMTPServer(new HandlerFactory()); serverImpl.setPort(getPort()); serverImpl.setHostName(getDomain()); serverImpl.setDisableTLS(<email.server.disableTLS>); // <-- added serverImpl.setRequireTLS(<email.server.requireTLS>); // <-- added serverImpl.setHideTLS(<email.server.hideTLS>); // <-- added serverImpl.start(); log.info("Email Server has started successfully"); } ---------------------------------------
          Hide
          Mark Rogers added a comment -

          Check in 30913 on HEAD - will be in Community 4.0.b

          3 new properties added
          email.server.hideTLS=false
          email.server.enableTLS=true
          email.server.requireTLS=false

          Show
          Mark Rogers added a comment - Check in 30913 on HEAD - will be in Community 4.0.b 3 new properties added email.server.hideTLS=false email.server.enableTLS=true email.server.requireTLS=false
          Hide
          Ravi Manthena added a comment -

          Assigned to Alfresco QA Team for retesting

          Please make sure you are using the following build 532 and also make sure the subversion revision number is 30975 or less.

          Show
          Ravi Manthena added a comment - Assigned to Alfresco QA Team for retesting Please make sure you are using the following build 532 and also make sure the subversion revision number is 30975 or less.
          Hide
          Alfresco QA Team added a comment -

          Successfully validated on Alfresco Enterprise v4.0.0b build 554(r31204), Tomcat, PostgreSQL, Java (all installer deployed), WinXP SP3, FF 7.0.1.
          Thanks, AlexPo.

          Show
          Alfresco QA Team added a comment - Successfully validated on Alfresco Enterprise v4.0.0b build 554(r31204), Tomcat, PostgreSQL, Java (all installer deployed), WinXP SP3, FF 7.0.1. Thanks, AlexPo.

            People

            • Assignee:
              Closed Bugs
              Reporter:
              Scott Ashcraft
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: