Koozali.org: home of the SME Server
Obsolete Releases => SME Server 8.x => Topic started by: ghorst352 on December 03, 2014, 04:33:51 PM
-
I got a bit of confusion regarding SSL/TLS in combination with Thunderbird version 31.3.0 and SME Server 8.1. I am fully aware of the vulnerability in SSL 3 and Thunderbird effective yesterday or thereabouts completely disabled SSL in Thunderbird version 31.3.0. Great, that needed to be done so let's move on. Anyways, perhaps due to my lack of knowledge in this area I thought that TLS would be the fallback? I cannot receive emails using secure POP or IMAP due to Thunderbird killing off SSL so what in the heck am I suppose to do? I thought TLS 1.2 is what we are suppose to be using? My version is only TLS 1.0 on SME SERVER 8.1 w/ all updates? How am I suppose to erect a secure path for receiving email in combination w/ Thunderbird 31.3.0 and SME Server 8.1 + TLS?
Any help is greatly appreciated :D
-
Please open a bug with as much details (log files, Thunderbird error message etc...) as possible
-
Just to say that this isn't a one off experience, I've got the same problem with 8.1 and latest version of Thunderbird (31.3.0). Thunderbird's error log is:
Cannot communicate securely with peer: no common encryption algorithm(s).
(Error code: ssl_error_no_cypher_overlap)
Seems we need a higher version of TLS which isn't in the repositories. How do I check which version of TLS is currently installed? If all we have is 1.0 like bhay3s suggests, that is a vulnerable version and no longer supported.
-
And without a bug opened, this issue won't be worked on.....
-
http://bugs.contribs.org/show_bug.cgi?id=8707
-
Just as a side note I pushed out TB ver 24.4.0 to my stations until this issue is resolved. I do not get any helpful information like "particle" did in the error console the only thing I see is the status saying "connected to (my mail server)" and just sits there without ever successfully pulling email due to SSL being disabled in 31.3.0. I have combed my logs in SME but don't have anything else helpful to add at this time.
-
Well, I'm kind of pissed now. I did a vulnerability check over at ssllabs.com and the server failed miserably. The server is completely current with the repositories (all yum updates are done), and all the SSL things that were supposed to be patched and fixed aren't. There is no TLS 1.1 or 1.2 on the server:
Protocols
TLS 1.2 No
TLS 1.1 No
TLS 1.0 Yes
SSL 3 INSECURE Yes
SSL 2 Yes
This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate.
The server supports only older protocols, but not the current best TLS 1.2.
The server does not support Forward Secrecy with the reference browsers.
This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks.
I'll be updating the bug report later today when I have a better picture. In the meantime, it'd be nice to know why these security updates haven't been pushed out.
-
So, you're pissed because an opensource product you got for free is not as good as you'd like it to be am I correct ?
Anyway, please add your informations into the bug, not here
-
Actually, we paid Mitel a lot of money back in the day. After all the updates over the last year, I did not expect these vulnerabilities to still exist on this platform. Apologies for any bad feeling.
-
FWIW:
To me this issue seems to be a compatibility issue. Mozilla decided to disable SSLv3 in their products and made a new version available. If I was running a production environment, I would keep myself up to date with the announcements and change logs of the most used daily tools, such as an email/calendaring client, so I am fully aware of upcoming changes. Also I would test new updates thoroughly before approving it for daily usage in the production environment, for I would need to support all clients.
SME Server did not yet disable all the SSLv3 in the server components, and devs are working hard to do this for the same reasons as all other vendors are doing. SME Server is checked against SSLLABS.com and other tools regularly by many SME Server users. And also notice that any security check will change their methods based on market developments, such as POODLE.
So my best guest is that what used to work, e.g. SME Server and Thunderbird, became incompatible due to a significant change in one of the components. And I could have know that if I read announcements, did regular checks and especially did thorough testing before deploying a change in important production tools.
-
Its free, but the effort by Daniel is worth more than thank you, http://bugs.contribs.org/show_bug.cgi?id=8707 and http://bugs.contribs.org/show_bug.cgi?id=8716
-
FWIW:
To me this issue seems to be a compatibility issue. Mozilla decided to disable SSLv3 in their products and made a new version available. If I was running a production environment, I would keep myself up to date with the announcements and change logs of the most used daily tools, such as an email/calendaring client, so I am fully aware of upcoming changes. Also I would test new updates thoroughly before approving it for daily usage in the production environment, for I would need to support all clients.
You're right. It's a compatibility issue. SSLv3 is 18 years old. It's very old and not very good and got turned off. People have been turning it off since Firefox 22 a year and a half ago. There are THREE successive versions. Two of which aren't supported in 8.1 (TLS 1.1 & 1.2). That leaves us with TLS 1.0 only - which is vulnerable too. I can't find the end of life announcement so we could make plans...
Even SME 9.0 with yum updates (which supports TLS 1.1 & 1.2) still gives the error message server does not support RFC 5746, see CVE-2009-3555 and these errors come from 2009 and 2010.
I don't mind supporting people like Daniel who have provided a rock star response (see tip jar). But pointing fault with people who are responsibly updating clients by incremental minor versions (which is what caused this) is just preposterous. Otherwise you're basically saying that SME will only work with old vulnerable software.
-
There is a fix for this waiting to be verified in Bug 8707 it needs to be verified before it is released as an update. It needs a user who uses the mail features of SME and the latest thunderbird. The verification needs to confirm that the system still operates correctly with other mail clients and older versions of TB as well as the latest release. Update for SME9 has been verified (Thanks Jim :-))
See HERE (http://wiki.contribs.org/SME_Server:Documentation:QA:Verification) for the format that should be followed for a verification, hopefully this prevents other bugs being introduced via an update.
-
I can verify for my network after installing the upgraded POP3 package that TB ver 31.3.0 works successfully with SME Server 8.1. Thanks.
-
I can verify for my network after installing the upgraded POP3 package that TB ver 31.3.0 works successfully with SME Server 8.1. Thanks.
Edit: Tested on SME9 and works!
-
Has anyone tested the fix to see if it works on 7.x? Could one upgrade to e-smith-pop3-2.2.0-8.sme on 7.x and will this fix IMAP as well?
I mean, there must be *somebody* out there still running, say 7.6 for various reason I'm sure they wouldn't care to get into...
-
Has anyone tested the fix to see if it works on 7.x? Could one upgrade to e-smith-pop3-2.2.0-8.sme on 7.x and will this fix IMAP as well?
I mean, there must be *somebody* out there still running, say 7.6 for various reason I'm sure they wouldn't care to get into...
SME Server versions <=7.x (based on RHEL 4.x and Centos 4.x) are no longer supported. Patches and fixes are not back ported to these versions by any vendor. Fixes designed for SME Server 8.x and 9.x will not work for other versions.
You really should upgrade for you are missing out on all the security progress.
-
You're preaching to the choir ;)
We are being migrated to an Exchange server shortly so this box has been frozen while this transition is taking place. Administrators don't want to fiddle with things because it's working fine other than this specific issue and a couple of others that we've managed to patch. Since this issue is easily mitigated for the time being (it only affects a small number of users needing access outside the LAN and it's easy for them to revert to TB 31.2.0), this might not be sufficient enough for them to "risk" the upgrade.
So, we are caught in the middle between nervous management and security risks. Something I'm sure that the millions of XP users are familiar with...
-
Particle,
I do understand your frustrations as I am in the same boat. However.....
Actually, we paid Mitel a lot of money back in the day. After all the updates over the last year, I did not expect these vulnerabilities to still exist on this platform. Apologies for any bad feeling.
That was when Mitel 'owned' and ran it. That was a long time ago, and before v7, v8 and v9.
That vulnerabilities exist in these particular parts of the platform is not entirely our responsibility.
Unfortunately, we are bound mainly by what comes down from upstream. Remember that SME v8 is based on RHEL/CentOS 5 and SME v9 on RHEL/CentOS 6. It is a pile of code that sits on top of someone elses core distribution to make it easier to manage that core. We try to touch the actual core as little as possible.
I don't mind supporting people like Daniel who have provided a rock star response (see tip jar). But pointing fault with people who are responsibly updating clients by incremental minor versions (which is what caused this) is just preposterous. Otherwise you're basically saying that SME will only work with old vulnerable software.
Dan is one of the most important people around here. Without him and his work there would barely BE a SME server !!! Remember that he, like all of us, are unpaid volunteers. We do it because we want too, not because we get paid to.
No one was pointing fault at you for updating your software - they did point out that the SME server is open source, and essentially free to use, and with no guarantees.
If you want those then you need to look at a system with commercial support :-) And even then you may not get the answer you want - my guess is RHEL would advise you to upgrade to RHEL 7.
The point is that a vulnerability has been discovered in a protocol in software originally provided by RHEL. The client program then refuses to use that protocol. Upstream have no updates. SME is built on top of a platform that does not currently have a solution. The people to really complain to are RHEL.
Now, we could try and look at building our own packages etc (we have just started doing that for clamav to make sure it stays more up to date) BUT, that depends on manpower, and we just don't have anywhere near enough. It is a struggle to keep up things as they are, let alone running off and building our own stuff. We would then also leave ourselves exposed to the risks of running more up to date versions that have not gone through such rigorous checking as they would if they come from RHEL/CentOS.
Many people use SME because they want stability, not bleeding edge. Unfortunately this is one isolated area that we are really stuck on and there are no easy answers to it.
Caught between a rock and a hard place.....
Yes, we could go and try to update to RHEL/CentOS 7 but that is going to take a massive effort, and unless more people come forward to help, it won't happen for some while yet.
Note I am not trying to have a go, but trying to point out situation that we are in for you, and others ...... sometimes we just can't win !
B. Rgds
John
President, Koozali Foundation Inc.
-
To follow this up I asked about building a different version of OpenSSL etc and am advised as follows (I'm no dev so rely on the good advice of others !) :
We're already building our own OpenSSL, but it's just the upstream one with an updated trusted CA store.
Maintaining our own, newer openssl is just not possible (we'd have to re-build everything which is linked on it, which is nearly everything). And I don't think it'd be that useful.
We might not support TLSv1.1 and TLSv1.2 but we do support TLSv1.0 which is not vulnerable AFAIK
B. Rgds
John
President, Koozali Foundation Inc.
-
Brenno
..... this box has been frozen while this transition is taking place. Administrators don't want to fiddle with things....
So, we are caught in the middle between nervous management and security risks....
This is not a SME server problem.
There are technical solutions available, so this is really a management decision to do or not do certain things, & management accepts responsibility for the outcome of their decisions.