TLS renegotiation issue (CVE-2011-1473) in Dovecot

Mon May 16 13:47:49 UTC 2022

ok need some more info but in general ssl setup should be as follows.

FQHN - do have have proper dns reverses setup? - this is an upstream thing

for example :

forwards :

## nslookup mail18.scom.ca
Server:         10.220.0.2
Address:        10.220.0.2#53

Name:   mail18.scom.ca
Address: 65.39.148.18

reverses :

## nslookup 65.39.148.18
18.148.39.65.in-addr.arpa       name = sogo.scom.ca.
18.148.39.65.in-addr.arpa       name = mail18.scom.ca.
18.148.39.65.in-addr.arpa       name = ns2.scom.ca.
18.148.39.65.in-addr.arpa       name = mail.scom.ca.

Authoritative answers can be found from:

it needs to be understood that the reverses are usually returned by your 
upstream isp and should be set accordingly, ie you will have to get them 
to program them.

if you note above you can have several mappings for reverses

next ssl rewriting (other then sni) does simply not work so well.

also you should have a static ip (assuming you do)

mail18 is in my reverse so this error wont be thrown.

also note the server name (mail18.scom.ca) for both dovecot and postfix 
MUST match the certificate and dns for all to work.

ssl when running a masil server should be setup with a proper 
ceretificate (i use a wildcard for mine), proper forwards and proper 
reverses. Lets Encrypt (free ssl) is not a stable way to go on a busy 
server. You can typically get an ssl cert (proper one) for 10~20 us? 
pending on the provider of the cert.

also note this has to be setup properly on postfix as well as that to 
could throw a FQHN error if they are connecting to port 25/465/587 as well.

My ssl config (example) - please note i run sni for multiple domains and 
certs

i typically run with the dovecot defaults under 2.3.18 and it seems to 
work ok.

----------------------------------------------------------------------------
# cat sni.conf
#sni.conf
ssl = yes
verbose_ssl = yes
ssl_dh =</usr/local/etc/dovecot/dh-4096.pem
ssl_prefer_server_ciphers = yes
#ssl_min_protocol = TLSv1.2

#Default *.scom.ca
ssl_key =</usr/local/etc/dovecot/scom.pem
ssl_cert =</usr/local/etc/dovecot/scom.pem
ssl_ca =</usr/local/etc/dovecot/scom.pem

local_name .scom.ca {
   ssl_key = /programs/common/getssl.cert -c *.scom.ca -q yes
   ssl_cert = /programs/common/getssl.cert -c *.scom.ca -q yes
   ssl_ca = /programs/common/getssl.cert -c *.scom.ca -q yes
}

local_name mail.clancyca.com {
   ssl_key = /programs/common/getssl.cert -c mail.clancyca.com -q yes
   ssl_cert = /programs/common/getssl.cert -c mail.clancyca.com -q yes
   ssl_ca = /programs/common/getssl.cert -c mail.clancyca.com -q yes
}

local_name secure.clancyca.com {
   ssl_key = /programs/common/getssl.cert -c secure.clancyca.com -q yes
   ssl_cert = /programs/common/getssl.cert -c secure.clancyca.com -q yes
   ssl_ca = /programs/common/getssl.cert -c secure.clancyca.com -q yes
}

local_name mail.paulkudla.net {
   ssl_key = /programs/common/getssl.cert -c mail.paulkudla.net -q yes
   ssl_cert = /programs/common/getssl.cert -c mail.paulkudla.net -q yes
   ssl_ca = /programs/common/getssl.cert -c mail.paulkudla.net -q yes
}

local_name mail.ekst.ca {
   ssl_key = /programs/common/getssl.cert -c mail.ekst.ca -q yes
   ssl_cert = /programs/common/getssl.cert -c mail.ekst.ca -q yes
   ssl_ca = /programs/common/getssl.cert -c mail.ekst.ca -q yes
}

local_name mail.hamletdevelopments.ca {
   ssl_key = /programs/common/getssl.cert -c mail.hamletdevelopments.ca 
-q yes
   ssl_cert = /programs/common/getssl.cert -c mail.hamletdevelopments.ca 
-q yes
   ssl_ca = /programs/common/getssl.cert -c mail.hamletdevelopments.ca 
-q yes
}
----------------------------------------------------------------------------

Happy Monday !!!
Thanks - paul

Paul Kudla

Scom.ca Internet Services <http://www.scom.ca>
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266

On 5/13/2022 10:38 PM, Elisamuel Resto wrote:
> 
> On 2022-05-13 5:02 pm, Greg Earle wrote:
>> Hello,
>>
>> At work I'm running a Dovecot 2.3.15 server on a RHEL 7.9 system with 
>> OpenSSL 1.0.2k.
>>
>> Our IT Security people are threatening to shut it down because of this:
>>
>>> We were notified of a possible TLS renegotiation vulnerability on 
>>> [FQHN].
>>>
>>> [Parent organization] ticket NNNNNNN is open to track efforts.
>>>
>>> We conducted a manual test on the site for TLS Renegotiation on IMAP 
>>> port 993.
>>>
>>> We found that this was set to enabled.
>>>
>>> In order to remediate we will need to either:
>>>
>>>  1. Disable Renegotiation (preferred)
>>>  2. Set a max aggregated renegotiation
>>>
>>> Please remediate as soon as possible.
>>>
>>> References:
>>>
>>> https://support.f5.com/csp/article/K15278
>>>
>>> https://nvd.nist.gov/vuln/detail/cve-2011-1473
>>>
>>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1473
>>
>> I did some Googling and among the results, I found a few old posts 
>> from this mailing list among them, which to summarize basically seemed 
>> to say "Yeah, we could write some code ... " but that was about it.
>>
>> The IT Security rep sent me a reference to an ancient Red Hat article
>>
>> https://access.redhat.com/articles/23543
>>
>> which is hysterical - ancient history, references NSS and Tomcat, 
>> suggests changes to an add-on product (Red Hat Certificate Server) 
>> that is EOL, etc.
>>
>> Is there any way to mitigate this issue?
>>
>> (The only thing I can think of is to upgrade the Dovecot server to 
>> RHEL 8 and restrict connections to only TLSv1.3, but that ain't gonna 
>> happen overnight.)
>>
>> Thanks,
>>
>>         - Greg
> 
> Greg,
> 
> I believe this to be a configuration error, not a dovecot problem. The 
> output of dovecot -n (as an attachment; look it over for any data you do 
> not want publicized) would help to suggest changes to bring you back 
> into compliance.
> 
> 
> Regards,
> Elisamuel Resto
> 