X-Junk-Score: 0 [] X-KAS-Score: 0 [] From: "=?UTF-8?B?U8OpcmdpbyBBcmHDumpv?= sergio@3gnt.net" Received: from [193.227.239.7] (HELO 3gnt.net) by list.communigate.ru (CommuniGate Pro SMTP 6.3.11) with ESMTPS id 60512850 for CGatePro@list.communigate.ru; Wed, 27 Apr 2022 13:10:42 +0300 Received-SPF: pass receiver=mail.communigate.ru; client-ip=193.227.239.7; envelope-from=sergio@3gnt.net X-Virus-Scanned: by cgpav Received: from internal.domain; Wed, 27 Apr 2022 11:10:29 +0100 Message-ID: Date: Wed, 27 Apr 2022 11:10:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [CGP] Qualys "This server does not support Forward Secrecy with the reference browsers. Grade capped to B." problem - Case[AA7Q0427-953ID] Content-Language: pt_PT To: CommuniGate Pro Russian Discussions References:

Organization: =?UTF-8?Q?3GNTW_-_Tecnologias_de_Informa=c3=a7=c3=a3o=2c_Lda?= In-Reply-To: Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi,

On 27/04/2022 07:09, Dmitry Akindinov dimak@communigate.ru wrote:

Hello,

On 2022-04-27 06:18, Sérgio Araújo sergio@3gnt.net wrote:

Greetings,

Why does a freshly installed CentOS 7.9 / CommuniGate Pro 6.3.11 server only gets a B grade with the Qualys SSL checker <https://www.ssllabs.com/ssltest/index.html> (see attached screenshot) ?

The way they assign grades after their tests is questionable. For example to test for some vulnerabilities they would simply check the alert code recieved on connection termination witth a break-in attempt: if it's not the one they expect they would consider the implementation vulnerable, without more checks, regardless the fact that unsafe connection was terminated. If they see the older or weaker algorithms supported, they would cap your grade - even when those weaker algorithms are safer with oledr TLS versions and client would normally select the strongest suite presented by the server. As for this particular "forward secrecy" - this should be about ECDH(E) suits and the DH key size. CGPro supports ECDH (long-term DH pair) but not the Ephemeral ECDH (when DH pair is re-generated for every exchange in a TLS session), as that would require much more CPU for the multiple connections the server should be able to endure. The default DH key size is also considered too short by these tests: 6.3 uses 1536 by default, which is cobsidered effective against all but state-level attacks, but can be increased by a command-line parameter.

We plan to support TLS 1.3 and EC certificates in future versions. Not sure if ECDHE is that important for what most use as a mail server.

[]

The server uses a valid SSL certificate, and if use an Apache server as a reverse proxy, I get an A grade, which makes me think it's something with the CommuniGate Pro SSL implementation. However, I feel using Apache as a reverse proxy makes no sense, since CommuniGate Pro has an embedded Web server.

Well, when you need a web server, you use a web server. CGPro may be enough to serve its interfaces and home pages, but for a high load web site I would use apache or nginx anyway.

How do i fix/workaround the "/This server does not support Forward Secrecy with the reference browsers. Grade capped to B./" problem reported by the Qualys SSL checker <https://www.ssllabs.com/ssltest/index.html> ?

The short answer is "you can't do that now".

Well, generally hunting for a higher grade without understanding their meaning is not a good idea. The "forward secrecy" thing (ECDH) is the protection against decoding your traffic collected at full in the past with the certificate private key compromised in future. Every session is encrypted by a key unique for that session and it's _very_ hard to derive that key even if the certificate was compromised. But it's still possible for agencys with lots of CPU power to brute force for finding the actual session key and decode that session traffic. The "perfect forward secrecy" (ECDHE) reduces the prize for that brute force attack: not the entire session but only some shorter exchange can be decoded.
So, even with "imperfect forward secrecy" your traffic is well protected. Is protecting mail server traffic from an attack that is possible mostly in theory really worth of investing much more CPU power?

Thanks for the clarification.

Regards,