This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL TLS on SMTP

Our MAIL Relay worked fine until the NEW SSL Bug fix was applied, any suggestions ??

We have upgraded to 9.210-20, we now are getting serious EMAIL rejection problems EXIM Log:

SMTP command timeout on connection from (iPhone) [85.255.233.181]:23650
2014:12:04-18:54:38 fw1 exim-in[15966]: 2014-12-04 18:54:38 SMTP command timeout on connection from ([10.4.96.113]) [212.183.132.60]:53489
2014:12:04-18:55:00 fw1 exim-out[16233]: 2014-12-04 18:55:00 Start queue run: pid=16233
2014:12:04-18:55:00 fw1 exim-out[16233]: 2014-12-04 18:55:00 End queue run: pid=16233
2014:12:04-18:55:33 fw1 exim-in[16038]: 2014-12-04 18:55:33 SMTP command timeout on connection from (iPhone) [85.255.233.181]:19775
2014:12:04-18:55:40 fw1 exim-in[16043]: 2014-12-04 18:55:40 TLS error on connection from [85.255.233.181]:43614 (SSL_accept): timed out
2014:12:04-18:55:40 fw1 exim-in[16043]: 2014-12-04 18:55:40 TLS client disconnected cleanly (rejected our certificate?)


This thread was automatically locked due to age.
  • Cant see if this will FIX Problem ??

    Note: Once you have considered the workaround (or if you updated to 9.210) a connection with a Mailserver which uses SSLv3 is not possible anymore.In case you would like to reactive the support for SSLv3(vulnerable in this case) proceed as follows:

        Navigate to /var/chroot-smtp/etc/
        Open the exim.conf with vi: vi exim.conf
        Change the line openssl_options to: openssl_options = +no_tlsv1_2
        Save your changes and close the editor: :wq
        Now restart the smtpd service by executing /var/mdw/scripts/smtp restart
  • in my eyes only reverting the  fix will solve the problem.

    tested this with ha system: version 2.08 exim.conf works on node 1, while exim.conf on node 2 (version 2.10) ends in TLS / SSL problems even when you add openssl_options ...

    anyone any idea if this will be fixed in 9.3xx ?
  • If you have paid support, please ask Sophos Support to do the following:

    # edit /var/chroot-smtp/etc/exim.conf


    Press  to add line 297 (Ouch! I made a mistake when I posted this the first time.  It's correct now.)

    openssl_options = +no_sslv3


    although that change should be sufficient, change line 257 to

    tls_require_ciphers = RC4+RSA:HIGH:!MD5:!ADH:!SSLv2


    Press [escape]

    Type in

    :wq


    followed by [Enter], and that should have succeeded in adding the line they goofed on.  To check your work:

    # grep openssl /var/chroot-smtp/etc/exim.conf


    The output of that command should be

    openssl_options = +no_sslv3


    Cheers - Bob
    If your box already has the 9.300, 9.301 and 9.302 Up2Dates available on it, just change the version at the command line and Up2Date to 9.302 instead.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • okay ... 9.200 cuts away SSLv3 and other servers don't respond with TLS1.0:

    2-02.log.gz:2014:12:02-16:52:50 utm-2 exim-in[1184]: 2014-12-02 16:52:50 TLS error on connection from mail.trabert-fulda.de [212.218.98.2]:42904 (SSL_accept): error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

    with 9.208 an noSSLv3 the other server still uses TLS1

    /var/log/smtp/2014/12/smtp-2014-12-03.log.gz:2014:12:03-00:52:52 utm-2 exim-in[31012]: 2014-12-03 00:52:52 1XvxFT-00084C-2F ***(at)efm-fulda.de H=mail.trabert-fulda.de [212.218.98.2]:45274 P=esmtps X=TLSv1: DHE-RSA-AES256-SHA:256 S=32518 id=0df501d00d3a$e1aed4e0$a50c7ea0$@efm-fulda.de

    now using the "openssl_options = +no_tlsv1_2" means cutting off TLS1.2 and using SSLv3 ?!?
  • the "fix" does not work at all. 

    so the fact is, that from now on there is no working SMTP and POP3 proxy.

    well, i dont have to say that this is no go even for home user today !
    mail is essential and has to work !

    edit: try to send mail with auth user on 9.303-2
    result:
    2014:12:05-17:00:35 matrix exim-in[5007]: 2014-12-05 17:00:35 SMTP connection from [192.168.0.31]:44908 (TCP/IP connection count = 1)
    2014:12:05-17:00:35 matrix exim-in[6694]: 2014-12-05 17:00:35 TLS error on connection from [192.168.0.31]:44908 (SSL_accept): error:140A1175:SSL routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback
    2014:12:05-17:00:35 matrix exim-in[6694]: 2014-12-05 17:00:35 TLS client disconnected cleanly (rejected our certificate?) 

    sryl ?
  • fw115 - you implemented openssl_options = +no_tlsv1_2 and still problems with TLS ?
  • fw115 - you implemented openssl_options = +no_tlsv1_2 and still problems with TLS ?


    yep i did and got the same result !
  • If any of you guys are using a commercially license version of UTM, or the Appliance, do start a support case with Sophos Support (directly or via your reseller; posting here does not automatically mean a Sophos staff member will see it); they need to be made aware of this issue.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

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

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • If any of you guys are using a commercially license version of UTM, or the Appliance, do start a support case with Sophos Support (directly or via your reseller; posting here does not automatically mean a Sophos staff member will see it); they need to be made aware of this issue.


    well, then it will stay a sophos problem. in the good old astaro days, astaro staff checked the forum on daily basis. so if sophos don't or won't do it....

    i just have home version and can't open a ticket, but this problem is annoying!
  • This morning I received an email from support:

    The reason for this is that the UTM blocked insecure SSL connections from the providers to protect you from the Poodle Exploit.
    We can allow this but you will be vulnerable from the poodle exploit again.

    You may also check this KB for further details. 121509