Mailing List CGatePro@mail.stalker.com Message #106950
From: Technical Support support@communigate.com <CGatePro@mail.stalker.com>
Subject: Re: Padding Oracle vulnerability
Date: Sat, 1 Sep 2018 00:52:43 +0300
To: CommuniGate Pro Discussions <CGatePro@mail.stalker.com>
Hello,

On 2018-08-28 10:59 , Fred.Zwarts F.Zwarts@KVI.nl wrote:
On Thu, 23 Aug 2018 15:35:24 +0300, Dmitry Akindinov (Technical Support support@stalker.com <CGatePro@mail.stalker.com>) wrote:
On 2018-08-23 12:06, Fred.Zwarts F.Zwarts@KVI.nl wrote:
In the release notes of version 6.2.6 I find the following bug fix:

•Bug Fix: TLS: 4.1: TLS connections might be vulnerable to Padding Oracle Attack.

We now run version 6.2.6.
If I run a test from https://www.ssllabs.com/ssltest/ it reports, among others:

This server is vulnerable to the OpenSSL Padding Oracle vulnerability (CVE-2016-2107) and insecure. Grade set to F.

What is the explanation? Are there more than one Padding Oracle bugs, of which one one was fixed?

It appears that some test scripts on the net expect specific behavior in response to attempts to break into a TLS session. The family of "padding oracle" attacks use the differences in TLS peer responses depending on the success/failure of particular TLS operation stages to guess the next portion of a session key. The protection is to hide those differences and the fixes in the recent versions of CGpro do that.

Thanks for the reply. I have been thinking about it but I do not really understand what you said. It is probably because English is not my native language.

Do you mean that the test of ssllabs produces a false positive, or do you mean that the bug fix does not remove the vulnerability, but it only hides the vulnerability?

The test produces a false positive, we believe. The idea behinf the "oracles" is that depending on the server response on incorrect TLS record (or even a delay with that response) the attacker may guess the success progress with his break-in attempt. So, the very first approach to fix is to report the same error regardless of the actual problem with decoding the faked TLS record. The current versions do that. But it looks like when ssllabs receives specific code it does not try more to see if the responses with different data in faked records are the same, but rather flags the implementation as vulnerable. We did tests by simply replacing that (already the same) response code with a diofferent and that was accepted by the test.

--
Best regards,
Dmitry Akindinov.
=======================================================================
When answering to letters sent to you by the tech.support staff, make
sure the original message you have received is included into your
reply.
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster