Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 3551 views
  • Users 0 members are here
Options
Suggested
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

POP3Proxy, Poodle-Bugfix, TLS1 and TLS1.1 and fetchmail

darkwind
Hi,

I'm a linux admin using fetchmail on a local server to get emails via the pop3proxy of my sophos UTM 9.

We all know there is the infamous poodle-bug and sslv3 should not be used anymore.

Sophos has released a "bugfix" for this to make pop3proxy not using sslv3 anymore. But here is the catch. pop3proxy most likely uses openssl for connecting and though we don't want to use sslv3 anymore, TLS 1 and TLS 1.1 are still welcome and save to use. These, TLS 1 and TLS 1.1, rely on the same cipher_suits as sslv3.

So we have a problem. If you disable sslv3 as a cipher_suit, you cannot use TLS 1 or TLS 1.1 anymore. You could say, well you can still use TLS 1.2, because it doesn't rely on the sslv3 cipher_suit. But I'd answer, I do use fetchmail and you cannot force fetchmail to use TLS 1.2. [:(]

So since the last update I cannot use fetchmail anymore, because the solution proposed for the poodle-bug by Sophos was to turn off the sslv3 cipher_suit. And I don't like that at all. [:@]

Take a look in /var/storage/chroot-pop3/etc/pop3proxy.conf-default

before the patch/update 
tls_ciphers_server=RC4:HIGH:!MD5:!aNULL:!EDH


after the patch/update 
tls_ciphers_server=RC4:HIGH:!MD5:!aNULL:!EDH:!SSLv3


So here is my question. How can you configure pop3proxy so that sslv3 cipher suit is still usable but sslv3 protocol is not?

I saw this way of configuration on a lot of mail-services like dovecot and so on. So how can this be done with pop3proxy?


This thread was automatically locked due to age.
  • 0
    Have a look here:  The SSL v3.0 CBC (Poodle) vulnerability: affected versions, recommended steps and workarounds

    Pertinent Excerpt:

    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-pop3/etc/
    Open the exim.conf with vi: vi pop3proxy.conf
    Remove :!SSLv3 from the end of tls_ciphers_server
    Save your changes and close the editor: :wq
    Repeat this action for pop3proxy.conf-default
    Now restart the smtpd service by executing /var/mdw/scripts/pop3 restart

    Performing these steps will get you working.  Of course, it does not fix the issue as you want it fixed, with older TLS versions working while SSLv3 negotiation is turned off.  If you have a commercial (paid) license, you can also optionally engage Sophos Support on this issue directly (while sometimes Sophos staff do peruse this forum, posting an issue here does not automatically start a support case with Sophos).

    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.

  • 0 in reply to BrucekConvergent
    Hi,

    thank you for the reply. The part you pasted of the so called solution is well known to me. (Even with the mistakes coming from simple copy and pasting the part from the fix for SMTP exim. POP3 isn't SMTP [;)] )

    This solution is no help at all. The only way to fix the problem is to prohibit SSLv3 protocol and NOT the cipher_suit. Openssl 1.0.1j used by the UTM allows this strategy.

    What needs to be done by Sophos is fixing this part in the code of pop3proxy. It seems to be the policy of Sophos to prevent using SSLv3, since the patches provided turn this functionality off by default. So it's only consequent to work properly and patch pop3proxy. It's really a pity that this part of software is not open source else I'd fix it myself.

    But I will follow your advice and will open a ticket at Sophos.

    Thanks again for your answer.
  • 0 in reply to darkwind
    You may want to check out 9.304 (now out)... there are multiple "bugfixes" listed for SSL and POP3.  It may well be that this has been fixed.

    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.

  • 0 in reply to BrucekConvergent
    Hi,

    for me all worked untill I installed V9.304. Then I got the following error:

    2014:12:11-18:50:02 fw pop3proxy[25340]: Accepted client connection from 192.168.250.202 for 212.227.17.185 (pop.gmx.net Servers server_id 2)
    2014:12:11-18:50:02 fw pop3proxy[25340]: Fatal: Failed to accept SSL client
    2014:12:11-18:50:02 fw pop3proxy[25340]: SSL Error: 0x1408a10bd (error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number)

    My /etc/fetchmailrc in Ubuntu 14.4.1 was:
    ...
    ssl
    sslcertcheck
    sslproto "SSL3"
    sslcommonname "*********"
    ....

    I changed it quick and dirty to:

    sslproto "TLS1"

    and it is working again.

    So no tweaking the UTM. 

    Can anyone here tell me, whether that's right in fetchmail, or are there better parameters to set in fetchmail? That was the only quick thing I found in the man-pages.
Unfiltered HTML