Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Connect » SSL/TLS Protocol Initialization Vector blah blah (Help needed with SecurityMetrics vulnerability scan)
  •  
macjimbo

Messages: 103
Karma: 6
Send a private message to this user
We are struggling with the ever-moving goalposts presented by SecurityMetrics, who deal with PCI-DSS compliance. Because we take credit card payments online, our network has to be scanned for vulnerabilities. The latest vulnerability is described below. I don't even understand it to be honest. I was using a self-certified certificate until this week (because only our own staff log in to our server remotely) but Security Metrics don't like that any more so I had to install a proper certificate. Having done that and re-run the scan, I get a message that we have a 'SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability' (details below). This vulnerability is listed on multiple Kerio Connect ports. I hope someone can help. Thanks.


Description: SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability Synoposis: It may be possible to obtain sensitive information from the remote host with SSL/TLS-enabled services. Impact: A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow information disclosure if an attacker intercepts encrypted traffic served from an affected system. TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected. This script tries to establish an SSL/TLS remote connection using an affected SSL version and cipher suite, and then solicits return data. If returned application data is not fragmented with an empty or one-byte record, it is likely vulnerable. OpenSSL uses empty fragments as a countermeasure unless the 'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified when OpenSSL is initialized. Microsoft implemented one-byte fragments as a countermeasure, and the setting can be controlled via the registry key H KEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Secur ityProviders \\SCHANNEL\\SendExtraRecord. Therefore, if multiple applications use the same SSL/TLS implementation, some may be vulnerable while others may not, depending on whether or not a countermeasure has been enabled. Note that this script detects the vulnerability in the SSLv3/TLSv1 protocol implemented in the server. It does not detect the BEAST attack where it exploits the vulnerability at HTTPS client-side (i.e., Internet browser). The detection at server-side does not necessarily mean your server is vulnerable to the BEAST attack because the attack exploits the vulnerability at client-side, and both SSL/TLS clients and servers can independently employ the split record countermeasure. See also : http://www.openssl.org/~bodo/tls-cbc.txt http://vnhacker.blogspot.com/2011/09/beast.html http://technet.microsoft.com/en-us/security/bulletin/ms12-00 6 http://support.microsoft.com/kb/2643584 http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-th e-beast.aspx Data Received: Negotiated cipher suite: AES256-SHA|TLSv1|Kx=RSA|Au=RSA|Enc=AES(256)|Mac=SHA1 Resolution: Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure SSL/TLS servers to only support cipher suites that do not use block ciphers. Apply patches if available. Note that additional configuration may be required after the installation of the MS12-006 security update in order to enable the split-record countermeasure. See http://support.microsoft.com/kb/2643584 for details. Risk Factor: Medium/ CVSS2 Base Score: 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) CVE: CVE-2011-3389
  •  
Kedar

Messages: 1320
Karma: 48
Send a private message to this user
This vulnerability is fixed in Kerio Connect 8.0.0 (now in RC1 - http://www.kerio.com/betas/connect )
  •  
macjimbo

Messages: 103
Karma: 6
Send a private message to this user
OK thanks for this. Any idea when version 8 is likely to be released? I don't think anyone would recommend that I replace a stable version 7.4 in a live environment with an unreleased version 8? Or would you? Will this vulnerability also be addressed in 7.4.x ?
  •  
Kedar

Messages: 1320
Karma: 48
Send a private message to this user
macjimbo wrote on Thu, 27 September 2012 11:33
Will this vulnerability also be addressed in 7.4.x ?


We fixed receiving side for this vulnerability in the past but not sending side (data out from the server).
  •  
Pavel Dobry (Kerio)

Messages: 5245
Karma: 251
Send a private message to this user
Actually, this "vulnerability" is caused by necessary workaround for correct support of Microsoft Outlook on Windows XP with Kerio Outlook Connector.
In Kerio Connect 8 there is an option in the configuration file which allows to enable recommended workaround for this "vulnerability". But both things are exclusive, therefore Microsoft Outlook clients on Windows XP will not be able to connect to Kerio Connect server.
  •  
jolefebvre

Messages: 4
Karma: 0
Send a private message to this user
How do we activate the workaround exactly?
  •  
Pavel Dobry (Kerio)

Messages: 5245
Karma: 251
Send a private message to this user
Stop the server and change the configuration value SSLDontInsertEmptyFragments to 0.

Please note that some client (eg. browsers) may not support this and will not be able to use SSL connections to the server.
  •  
jolefebvre

Messages: 4
Karma: 0
Send a private message to this user
I made the change but our tool still detects the vulnerability. I know we "fixed" this vulnerability in other software by putting the RC4 cipher 1st in the priority order, before 3DES and AES.

Do you know if there's a way to do that in Kerio Connect?

Thanks
  •  
jolefebvre

Messages: 4
Karma: 0
Send a private message to this user
I'm not sure what changing SSLDontInsertEmptyFragments to 0 was supposed to do exactly, but since I've done that, absolutely nothing has changed.

When I connect with a browser to the Kerio Web interface with HTTPS I still receive AES128 as the preferred cipher.

We have fixed the Beast vulnerability in most of our systems by changing the preferred cipher order. The idea was to put RC4 ciphers first in the priority order.

Was this the objective behind changing the SSLDontInsertEmptyFragments value?

Is there any way to change the preferred cipher order to put RC4 on top?

We have a vulnerability scan for compliancy coming really soon and Kerio is ony of our last systems still vulnerable. Any help would be appreciated.

Thanks
  •  
Bill_E

Messages: 4
Karma: 1
Send a private message to this user
This is just to let Kerio know I am monitoring this thread. There are others out there with this problem.

We have the exact same situation with our firewall failing the PCI-DSS vulnerability scan on the HTTPS port used for external user's webmail access to our internal Kerio Connect mail server. It is our only remaining failure as well. I have tried the same SSLDontInsertEmptyFragments solution with no change in our PCI scan status.

I can't turn off external webmail. Prioritizing the RC4 cipher for https in the Kerio Connect web server would fix this. Is there a setting for that?
  •  
sthiessen

Messages: 4
Karma: 0
Send a private message to this user
We're also monitoring this thread, we have the same issue with our PCI-DSS scan and are out of compliance for over a month. Turning off webmail is not an option for our company either.
  •  
Bill_E

Messages: 4
Karma: 1
Send a private message to this user
Check these URLs for a solution.

forums.kerio.com/t/23749/mailserver-cfg
kb.kerio.com/article.php?id=1301
  •  
jolefebvre

Messages: 4
Karma: 0
Send a private message to this user
Looks promising. When is 8.0.1 will be available?
  •  
sthiessen

Messages: 4
Karma: 0
Send a private message to this user
According to Kerio 8.0.1 will be in Beta the end of January/beginning of February. See the article referenced by Bill_E above for more detail.
Previous Topic: Kerio Outlook Connector and Outlook Free/Busy
Next Topic: Directory used by spammers?
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Mon Oct 23 22:48:15 CEST 2017

Total time taken to generate the page: 0.00553 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.