The same way bug 506924 called for updating apache2 default cipher list, using the suggested ciphers by Mozilla, should we do the same for postfix's config? Going through postfix's docs, it seems to me the most appropriate way to do this would be to override the default for tls_high_cipherlist from ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH with ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:HIGH:!RC4:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK From reading http://www.postfix.org/postconf.5.html , I don't see a better way to increase the cipher strength and whether this change is even desirable.
*** Bug 508552 has been marked as a duplicate of this bug. ***
No. At this stage, interoperability trumps alleged protection against passive eavesdropping. RC4-MD5 is there to accept/send email with some versions of Exchange for example. The cipherlist interface in OpenSSL is very subtle and is subject to change. This is not an area for experimentation.
Both bugs, this and bug 508552 should be re-opened. We should try to use proper defaults. The majority will use defaults, they will not change it, except if it fails because some weird Exchange stuff or if they want to be more secure, however... If *we* (Gentoo) use proper defaults we'll help to push forward. I wish more distribution would ship proper defaults.
I must agree with Jorge and Christian here. Now that we know there are organizations actively storing/decrypting weakly encrypted data we should provide our users with strong encryption defaults. Unfortunately this also means we cannot stay backwards compatible for every ancient client that is only capable of weak/broken encryption. Please reconsider your decision.
It might be a good idea to create a tracker bug. It's not only Postfix but also Dovecot, Apache, nginx, lighttpd, ...
(In reply to Eray Aslan from comment #2) > No. At this stage, interoperability trumps alleged protection against > passive eavesdropping. RC4-MD5 is there to accept/send email with some > versions of Exchange for example. > > The cipherlist interface in OpenSSL is very subtle and is subject to change. > This is not an area for experimentation. Eray, as I mentioned in the initial comment, I have some doubts about whether we should do this for postfix, but I did thought it had merit discussing it. I disagree with you closing the dovecot bug as a duplicate, as there's nothing preventing us from doing that change in dovecot. If you want, I can provide a diff that keeps the weaker list commented or a list with RC4-MD5 support with a note that anyone wanting to support older Microsoft products might need to use it. Last, it's your prerogative to disagree with the proposal, but please close it as WONTFIX, CANTFIX or even UPSTREAM as this is not an invalid bug report.
Guys, smtp is not http. There is no user to press OK. Excluding Exchange 2003 from the list of MTAs we are willing to communicate with securely is actually detrimental to security. Perhaps surprisingly, the defaults are really there for a reason. Attempts to raise the policy floor results in decreased security because failure to negotiate a working TLS session leads to plaintext transmission in oppotunistic TLS. Even RC4-MD5 is better than plaintext. What can probably be safely done is raising opportunitistic floor to medium. But that is not what this bug proposes. Specifically (re: what this bug proposes in comment 1), postfix security grades are: null encryption-less grades for authenticated loopback traffic export 90's style export weak keys or stronger low legacy single-DES or stronger medium 128 bit RC4 or stronger high 128 bit AES or stronger One can see the specific cipher list with # openssl ciphers -v $(postconf -xh tls_high_cipherlist) Change high to medium, low etc to see the corresponding lists. Looking at the output from the above command, the proposed change just does not make sense. The Postfix default cipher-suites are chosen to avoid freezing-in any particular OpenSSL's version's cipher choices. Instead of explicit choices of discrete ciphers, cipher properties are used to sort the lists, and make appropriate exclusions. Changing the distro-wide defaults and listing specific ciphers to use would be a mistake.
(In reply to Jorge Manuel B. S. Vicetto from comment #6) > I disagree with you closing the dovecot bug as a duplicate Same points really. Interoperability (this time between MUA and server), any cipher being better than plaintext, specifying dicrete ciphers is bad ... But feel free to remove the duplicate if you like.
I believe the biggest jump in smtp security will not result from tinkering with cipher lists (they are good enough at least in postfix' case) but from wider adaptation of DNSSEC and DANE and corresponding TLSA records. Take debian.org (or a21an.org, heh) for example. debian.org's SMTP servers can be authenticated via their DNSSEC TLSA records. And so man in the middle attacks on email to debian.org from DANE TLSA enabled SMTP clients (e.g. Postfix 2.11 configured to use DNSSEC and DANE) require the attacker to brute-force crypt-analyze TLS cryptography, or have access to either the server's private keys, or the DNSSEC private keys of "debian.org", "org" or the root zone. gentoo.org supports DNSSEC but not DANE. The hard part is already done. Please consider publishing TLSA records for gentoo.org (just saying since I see infra folks in this bug). See bug #508756 Closing as WONTFIX.
The change to postfix which is useful, provided a preferable local verifying resolver (such as unbound or the like) is run, would be to enable postfix’s dane support by default: smtp_tls_note_starttls_offer = yes smtp_use_tls = yes smtp_dns_support_level = dnssec With those settings, whenever the MX lookup is dnssec secure and the resulting hostname has dnssec-secure tlsa record(s) for _25._tcp, postfix presumes that the intended destination supports STARTTLS and provides a cert which will associate with one or more of the tlsa records, and refuses to send the mail if those presumptions do not hold up. The idea is that if the secure tlsa does not match or if the destination does not support starttls even though a tlsa rr is published, then either there is a config error or an attack in progress. And that those who publish tlsa for their MXs prefer incoming mail be deferred if it looks like they are under attack. If the destination does not use dnssec or does not publish _25._tcp tlsa records for its MX postfix falls back to its pre-dane behaviour, so those settings will not cause harm.
