Re: Update to recommended TLS settings
On Fri, Aug 07, 2015 at 02:55:42AM +0200, DTNX Postmaster wrote: > For most systems, monitoring the status of their encryption just isn't > done at all; they use the defaults their device or server came with at > the time they purchased it, and rarely keep up with the times. They don't need to. There's nothing wrong with outdated crypto on systems that wouldn't even encrypt if encryption weren't on by default. We'll get more decent security through a natural process of deployment of more capable systems and retirement of less capable systems. Eventually, there'll be no demand for RC4 (for example), and we'll be able to turn it off with no noticeable degradation to cleartext. Later still (another ~5 years?) we'll be able to turn off TLS 1.0... > Also, unlike HTTPS, there is no way to surface the usage of bad > settings to the user and raise awareness that way, because the user > (employee or customer) has no real visibility into the state of > transport encryption between MTAs. There is generally very little they > can leverage to force change, even if they wanted to. Indeed "bad settings" are systems with broken DANE TLSA records that make it painful for others to enable decent security. Folks who just go with the flow and don't break anything are not a problem. I want to encourage capable administrators who can operate a signed DNSSEC zone without outages, and can document and perform key rotation correctly, to publish DANE TLSA RRs. I'd like to discourage others from doing so, if they don't have the determination, skill or discipline to do it well. > In other words, you gain NOTHING by dropping RC4 connections down to > plain text, at this point. It makes you, as a delivery destination, > less secure. You're punishing the end user out of some misplaced sense > of righteousness, doing disservice to both them and the recipients you > are responsible for. > > The only reason to disable old ciphers still in use for MTA-to-MTA > traffic is if leaving them enabled makes your systems vulnerable. In > all other cases, fallback to plain text is worse. Yes. This is why we've disabled EXPORT ciphers, and similarly weak, but no longer used legacy TLS features, but are aggressively hardening opportunistic TLS beyond that. And we'll continue to ship Postfix with reasonable default settings. -- Viktor.
Re: Update to recommended TLS settings
On 06 Aug 2015, at 21:44, Michael Ströder wrote: >>> simply look whether their system uses STARTTLS or not and won't check >>> which particular ciphers are used. IMO it might be a good learning effect >>> for >>> them if you disable STARTTLS for them. >> >> This is wrong. RC4 is not worse than cleartext. We'll disable >> RC4, once doing so almost never causes downgrades to cleartext. > > Yes, that's your opinion on that. > > But my opinion is that forcing clear-text might make admins wake up. > The point is that many people simply look at whether STARTTLS was used or not, > and not at the protocol and cipher details. > > Frankly I also consider your enquiry about statistics on RC4 usage to be > pretty much useless. > >> I posted best-practice settings, that protect as much traffic as >> possible, to the extent possible. > > ...at the risk that admins justify everything's ok forever because STARTTLS > was used. Except that those who deliberately keep using legacy software because they consider it 'safe enough', despite the general consensus on it, are a very small minority. For most systems, monitoring the status of their encryption just isn't done at all; they use the defaults their device or server came with at the time they purchased it, and rarely keep up with the times. Their transport encryption profile changes when they replace the legacy system, and the settings in the new server take over. Which are usually, again, the defaults the device ships with. Why does the Exchange 2003 problem disappear? Because the organisation has moved to a newer version of Exchange on a newer version of Windows Server. Also, unlike HTTPS, there is no way to surface the usage of bad settings to the user and raise awareness that way, because the user (employee or customer) has no real visibility into the state of transport encryption between MTAs. There is generally very little they can leverage to force change, even if they wanted to. Add to that the general level of misunderstanding when it comes to the workings of STARTTLS, and how it is NOT like HTTPS, misunderstandings about transport encryption in general, budget constraints, time constraints, and so on, and there's rarely enough leverage to actually force change. I say this as someone who takes a very proactive stance on this, for STARTTLS, HTTPS and other forms of transport encryption. Naming and shaming in public, if necessary. As a company, we have a great many conversations about this with a wide variety of organisations. We have special introductory fixed price audit rates for cases where just tuning the defaults will already improve their security profile by a lot. We have implemented fairly strict minimum requirements with a 'or else' deadline for clients we relay mail for. We blacklist without hesitation if a sender presents an actual security risk to our customers. And you know what? In the majority of cases, we LOSE. We've had customers go elsewhere when we enacted the 'or else' minimum requirements (with a reasonable grace period) because the responsible administrator does not want to be told that their stuff is broken, and out of date. Or a problem remains because they don't dare touch a legacy configuration, because they misunderstand how it actually works, despite our assurances that it will be OK. Or because they are not in direct control, and whoever is refuses to accept the evidence presented. Looking at you, MailGun dropping down to plain text because 'self-signed certificates are insecure'. In other words, you gain NOTHING by dropping RC4 connections down to plain text, at this point. It makes you, as a delivery destination, less secure. You're punishing the end user out of some misplaced sense of righteousness, doing disservice to both them and the recipients you are responsible for. The only reason to disable old ciphers still in use for MTA-to-MTA traffic is if leaving them enabled makes your systems vulnerable. In all other cases, fallback to plain text is worse. Mvg, Joni
Re: Update to recommended TLS settings
Michael Str?der: > Viktor Dukhovni wrote: > > On Thu, Aug 06, 2015 at 10:25:04AM +0200, Michael Str?der wrote: > > > >>> On Thu, Aug 06, 2015 at 09:13:53AM +0200, Sven Schwedas wrote: > Why medium and not high, while we're at it? What clients would have > problems with it? > >>> > >>> Because cleartext is not stronger than medium. If you make TLS > >>> impossible for peers that only support medium, they'll do cleartext. > >>> Raising the floor too high lowers security. Security is improved > >>> by raising the ceiling (stronger best supported ciphers), not > >>> raising the floor (removing weak ciphers that are still best > >>> available for a non-negligible set of peers). > >> > >> Viktor, I have some doubts regarding your point of view on this: > >> > >> I suspect that many admins maintaining systems only capable using medium > >> ciphers > > > > False premise. > > No, right premise. Please, the purpose of Postfix is to deliver mail, not to force other people into adopting your specific world view. If you must, go somewhere else. Wietse
Re: Update to recommended TLS settings
Viktor Dukhovni wrote: > On Thu, Aug 06, 2015 at 10:25:04AM +0200, Michael Str?der wrote: > >>> On Thu, Aug 06, 2015 at 09:13:53AM +0200, Sven Schwedas wrote: Why medium and not high, while we're at it? What clients would have problems with it? >>> >>> Because cleartext is not stronger than medium. If you make TLS >>> impossible for peers that only support medium, they'll do cleartext. >>> Raising the floor too high lowers security. Security is improved >>> by raising the ceiling (stronger best supported ciphers), not >>> raising the floor (removing weak ciphers that are still best >>> available for a non-negligible set of peers). >> >> Viktor, I have some doubts regarding your point of view on this: >> >> I suspect that many admins maintaining systems only capable using medium >> ciphers > > False premise. No, right premise. > "smtpd_tls_ciphers = medium" is a *floor* on the > available ciphers, not a ceiling. In practice HIGH ciphers are > used whenever available. The underlying cipherlist is essentially > > tls_medium_cipherlist = HIGH:MEDIUM I understand this all quite well since many years. >> simply look whether their system uses STARTTLS or not and won't check >> which particular ciphers are used. IMO it might be a good learning effect for >> them if you disable STARTTLS for them. > > This is wrong. RC4 is not worse than cleartext. We'll disable > RC4, once doing so almost never causes downgrades to cleartext. Yes, that's your opinion on that. But my opinion is that forcing clear-text might make admins wake up. The point is that many people simply look at whether STARTTLS was used or not, and not at the protocol and cipher details. Frankly I also consider your enquiry about statistics on RC4 usage to be pretty much useless. > I posted best-practice settings, that protect as much traffic as > possible, to the extent possible. ...at the risk that admins justify everything's ok forever because STARTTLS was used. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature
Re: Ownership/Permissions of /var/spool/postfix
Wietse Venema: > Rich Shepard: > >During the most recent upgrade I inadvertently altered owner, group, > > and/or permissions in /var/spool/postfix. I've looked for information in all > > the README files that seemed applicable but have not found a list of how > > /var/spool/postfix subdirectories should be set. Please point me to a doc > > that has this information. > > > >While 'postfix check' shows no errors, when I run mailx from the command > > line I get warnings about an inability to write to > > /var/spool/postfix/maildrop. That subdirectory is configured as: > > > > drwxr-sr-x 2 postfix postdrop 12288 Aug 6 09:55 maildrop/ > > DO NOT DO THAT. The directory MUST be writable only by root. Ignore my response. I thought this was the queue dir. Wietse
Re: Ownership/Permissions of /var/spool/postfix
Rich Shepard: >During the most recent upgrade I inadvertently altered owner, group, > and/or permissions in /var/spool/postfix. I've looked for information in all > the README files that seemed applicable but have not found a list of how > /var/spool/postfix subdirectories should be set. Please point me to a doc > that has this information. > >While 'postfix check' shows no errors, when I run mailx from the command > line I get warnings about an inability to write to > /var/spool/postfix/maildrop. That subdirectory is configured as: > > drwxr-sr-x 2 postfix postdrop 12288 Aug 6 09:55 maildrop/ DO NOT DO THAT. The directory MUST be writable only by root. Wietse
Re: Ownership/Permissions of /var/spool/postfix
On Thu, 6 Aug 2015, Viktor Dukhovni wrote: # postfix set-permissions Except on Debian systems where it might not work, because the Debian "postfix-files" file (in $daemon_directory for recent enough releases) often has more files list than are actually deployed by Postfix packages. Viktor, I run Slackware. In any case all the required permissions are listed in "postfix-files". Thanks for both pointers. That's what I wanted to learn. Regards, Rich
Re: Update to recommended TLS settings
On Thu, Aug 06, 2015 at 10:25:04AM +0200, Michael Str?der wrote: > > On Thu, Aug 06, 2015 at 09:13:53AM +0200, Sven Schwedas wrote: > >> Why medium and not high, while we're at it? What clients would have > >> problems with it? > > > > Because cleartext is not stronger than medium. If you make TLS > > impossible for peers that only support medium, they'll do cleartext. > > Raising the floor too high lowers security. Security is improved > > by raising the ceiling (stronger best supported ciphers), not > > raising the floor (removing weak ciphers that are still best > > available for a non-negligible set of peers). > > Viktor, I have some doubts regarding your point of view on this: > > I suspect that many admins maintaining systems only capable using medium > ciphers False premise. "smtpd_tls_ciphers = medium" is a *floor* on the available ciphers, not a ceiling. In practice HIGH ciphers are used whenever available. The underlying cipherlist is essentially tls_medium_cipherlist = HIGH:MEDIUM > simply look whether their system uses STARTTLS or not and won't check > which particular ciphers are used. IMO it might be a good learning effect for > them if you disable STARTTLS for them. This is wrong. RC4 is not worse than cleartext. We'll disable RC4, once doing so almost never causes downgrades to cleartext. I posted best-practice settings, that protect as much traffic as possible, to the extent possible. Asking for more than that just causes more mail to be sent in the clear. Don't do that. -- Viktor.
Re: Ownership/Permissions of /var/spool/postfix
On Thu, Aug 06, 2015 at 11:02:46AM -0700, Rich Shepard wrote: > I want a list of owners, groups, and permissions I can keep here so I can > repair inadvertent changes during future upgrades. # postfix set-permissions Except on Debian systems where it might not work, because the Debian "postfix-files" file (in $daemon_directory for recent enough releases) often has more files list than are actually deployed by Postfix packages. In any case all the required permissions are listed in "postfix-files". -- Viktor.
Re: Ownership/Permissions of /var/spool/postfix
On Thu, 6 Aug 2015, Michael J Wise wrote: This is from a MacOS 10.9 instance, so it's not quite current, and the user is ... a bit weird, but it should help as a data point. Good luck! Thanks, Michael. Rich
Re: Ownership/Permissions of /var/spool/postfix
> On Thu, 6 Aug 2015, Michael J Wise wrote: > >> Needs Group Write. > > Michael, > >Ah, I should have seen that. > >> See that little "s"? >> That's special. > >Yep. I learned that maildrop and public need to be set gid. > >It would still be useful to have a complete list of owners, groups, and > perms for the directory. This is from a MacOS 10.9 instance, so it's not quite current, and the user is ... a bit weird, but it should help as a data point. Good luck! $ ls -la total 0 drwxr-xr-x 16 root wheel 544 Aug 24 2013 . drwxr-xr-x 8 root wheel 272 Aug 30 2014 .. drwx-- 2 _postfix wheel 68 Aug 24 2013 active drwx-- 2 _postfix wheel 68 Aug 24 2013 bounce drwx-- 2 _postfix wheel 68 Aug 24 2013 corrupt drwx-- 2 _postfix wheel 68 Aug 24 2013 defer drwx-- 2 _postfix wheel 68 Aug 24 2013 deferred drwx-- 2 _postfix wheel 68 Aug 24 2013 flush drwx-- 2 _postfix wheel 68 Aug 24 2013 hold drwx-- 2 _postfix wheel 68 Aug 24 2013 incoming drwx-wx--- 2 _postfix _postdrop 68 Aug 24 2013 maildrop drwxr-xr-x 3 root wheel 102 Nov 6 2013 pid drwx-- 26 _postfix wheel 884 Nov 6 2013 private drwx--x--- 7 _postfix _postdrop 238 Nov 6 2013 public drwx-- 2 _postfix wheel 68 Aug 24 2013 saved drwx-- 2 _postfix wheel 68 Aug 24 2013 trace > Thanks, > > Rich > Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause.
Re: Ownership/Permissions of /var/spool/postfix
On Thu, 6 Aug 2015, Michael J Wise wrote: Needs Group Write. Michael, Ah, I should have seen that. See that little "s"? That's special. Yep. I learned that maildrop and public need to be set gid. It would still be useful to have a complete list of owners, groups, and perms for the directory. Thanks, Rich
Re: Ownership/Permissions of /var/spool/postfix
>During the most recent upgrade I inadvertently altered owner, group, > and/or permissions in /var/spool/postfix. I've looked for information in > all > the README files that seemed applicable but have not found a list of how > /var/spool/postfix subdirectories should be set. Please point me to a doc > that has this information. > >While 'postfix check' shows no errors, when I run mailx from the > command > line I get warnings about an inability to write to > /var/spool/postfix/maildrop. That subdirectory is configured as: > > drwxr-sr-x 2 postfix postdrop 12288 Aug 6 09:55 maildrop/ Needs Group Write. See that little "s"? That's special. Postfix uses a very interesting trick of having the executables set the GroupID when being run as the user, and this allows them to get into directories when the user they are running as normally cannot. sudo chmod +wg ./maildrop ... if memory serves. > > and so is public/ > > drwx--s--- 2 postfix postdrop 4096 Aug 6 10:22 public/ > >I want a list of owners, groups, and permissions I can keep here so I > can > repair inadvertent changes during future upgrades. > > Rich > Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause.
Ownership/Permissions of /var/spool/postfix
During the most recent upgrade I inadvertently altered owner, group, and/or permissions in /var/spool/postfix. I've looked for information in all the README files that seemed applicable but have not found a list of how /var/spool/postfix subdirectories should be set. Please point me to a doc that has this information. While 'postfix check' shows no errors, when I run mailx from the command line I get warnings about an inability to write to /var/spool/postfix/maildrop. That subdirectory is configured as: drwxr-sr-x 2 postfix postdrop 12288 Aug 6 09:55 maildrop/ and so is public/ drwx--s--- 2 postfix postdrop 4096 Aug 6 10:22 public/ I want a list of owners, groups, and permissions I can keep here so I can repair inadvertent changes during future upgrades. Rich
Re: postscreen dnsbl weighting with new(est) spamhaus return codes -- experiences/data?
Once upon a time, PGNd said: > On quick investigation, @ spamhaus now says > (http://www.spamhaus.org/news/article/713/) return codes have changed: Those are dbl response codes, not zen. You are mixing the two up, but they are very different. -- Chris Adams
postscreen dnsbl weighting with new(est) spamhaus return codes -- experiences/data?
Some time ago, I'd cribbed the following postscreen dnsbl weights from an experienced users' post ... iirc, it was on this list ... postscreen_dnsbl_threshold = 5 postscreen_dnsbl_sites = b.barracudacentral.org=127.0.0.2*7 zen.spamhaus.org=127.0.0.[10;11]*8 zen.spamhaus.org=127.0.0.[4..7]*6 zen.spamhaus.org=127.0.0.3*4 zen.spamhaus.org=127.0.0.2*3 ... They'd worked well for me. However, of late, I'd been seeing an increase in leaks through my filter. On quick investigation, @ spamhaus now says (http://www.spamhaus.org/news/article/713/) return codes have changed: http://www.spamhaus.org/faq/section/Spamhaus%20DBL#291 Return CodesData Source - 127.0.1.2 spam domain 127.0.1.4 phish domain 127.0.1.5 malware domain 127.0.1.6 botnet C&C domain 127.0.1.102 abused legit spam 127.0.1.103 abused spammed redirector domain 127.0.1.104 abused legit phish 127.0.1.105 abused legit malware 127.0.1.106 abused legit botnet C&C 127.0.1.255 IP queries prohibited! Once I find the docs @ spamhaus of what each of those data source defs & criteria are, I can cobble up a fresh/relative weighting, and see how it performs over time. Has anyone experience with a (re)weighting mix of these ^^ newer codes already to share?
Re: check_policy_service not working - need a 4eye method or..
Istvan Prosinger:
> On 2015-08-06 13:50, Istvan Prosinger wrote:
> > Got it.
> > I have made a small perl script as a service that would only return
> > reject as a policy (that sould have rendered most of the mailing
> > impossibble), and postfix was still mailing happily. Since I have
> > recompiled Postfix from the source, it was out of the question the the
> > process was faulty, so the only option is that Postfix couldn't
> > connect to a local service.
> >
> > It was the firewall. The FORWARD chain was set to drop all, and the
> > rest is history..
> >
> > Thanks everyone for the extraordinary efforts.
>
> @Wietse
> Regarding this one, is it possibble to implement an error message in the
> log if it cannot connect to a service, like a policy service in this
> case? I guess any clue in the maillog would do
The information is already in your logfiles, You just need to
develop a clue to find it.
Postfix logs a WARNING when the connect() call fails, and it
optionally logs an INFO message when the connect() call succeeds.
fd = auto_clnt->connect(auto_clnt->endpoint, BLOCKING, auto_clnt->timeout);
if (fd < 0) {
msg_warn("connect to %s: %m", auto_clnt->endpoint);
} else {
if (msg_verbose)
msg_info("%s: connected to %s", myname, auto_clnt->endpoint);
Wietse
Re: check_policy_service not working - need a 4eye method or..
On 2015-08-06 13:50, Istvan Prosinger wrote: Got it. I have made a small perl script as a service that would only return reject as a policy (that sould have rendered most of the mailing impossibble), and postfix was still mailing happily. Since I have recompiled Postfix from the source, it was out of the question the the process was faulty, so the only option is that Postfix couldn't connect to a local service. It was the firewall. The FORWARD chain was set to drop all, and the rest is history.. Thanks everyone for the extraordinary efforts. @Wietse Regarding this one, is it possibble to implement an error message in the log if it cannot connect to a service, like a policy service in this case? I guess any clue in the maillog would do
Re: check_policy_service not working - need a 4eye method or..
Got it. I have made a small perl script as a service that would only return reject as a policy (that sould have rendered most of the mailing impossibble), and postfix was still mailing happily. Since I have recompiled Postfix from the source, it was out of the question the the process was faulty, so the only option is that Postfix couldn't connect to a local service. It was the firewall. The FORWARD chain was set to drop all, and the rest is history.. Thanks everyone for the extraordinary efforts.
Re: Update to recommended TLS settings
Viktor Dukhovni wrote: > On Thu, Aug 06, 2015 at 09:13:53AM +0200, Sven Schwedas wrote: >> Why medium and not high, while we're at it? What clients would have >> problems with it? > > Because cleartext is not stronger than medium. If you make TLS > impossible for peers that only support medium, they'll do cleartext. > Raising the floor too high lowers security. Security is improved > by raising the ceiling (stronger best supported ciphers), not > raising the floor (removing weak ciphers that are still best > available for a non-negligible set of peers). Viktor, I have some doubts regarding your point of view on this: I suspect that many admins maintaining systems only capable using medium ciphers simply look whether their system uses STARTTLS or not and won't check which particular ciphers are used. IMO it might be a good learning effect for them if you disable STARTTLS for them. => drop RC4 Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature
Re: Update to recommended TLS settings
On Thu, Aug 06, 2015 at 09:13:53AM +0200, Sven Schwedas wrote: > > You should in most cases update main.cf by setting: > > > > # Exclude obsolete weak crypto. > > # > > smtpd_tls_protocols = !SSLv2, !SSLv3 > > smtpd_tls_ciphers = medium > > smtp_tls_protocols = !SSLv2, !SSLv3 > > smtp_tls_ciphers = medium > > Why medium and not high, while we're at it? What clients would have > problems with it? Because cleartext is not stronger than medium. If you make TLS impossible for peers that only support medium, they'll do cleartext. Raising the floor too high lowers security. Security is improved by raising the ceiling (stronger best supported ciphers), not raising the floor (removing weak ciphers that are still best available for a non-negligible set of peers). https://tools.ietf.org/html/rfc7435 > Is usage of tls_preempt_cipherlist still recommended? This has not been recommended, because it can cause interoperability problems with Exchange 2003 systems. To avoid those, you'd need to rank 3DES below RC4: tls_medium_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH:+RC4:+3DES pnly then can you "safely" set: tls_preempt_cipherlist = yes Note also that I strongly discourage non-expert tweaks to the "tls__cipherlist" parameters. It is too easy to mess up, the underlying OpenSSL cipherlist syntax is rather subtle. Basically, do not change these to values that did not originate from me. -- Viktor.
Re: Update to recommended TLS settings
On 2015-08-06 09:08, Viktor Dukhovni wrote:
>
> Recent updates to the supported Postfix releases have updated the
> default settings of the OpenSSL ciphers used for opportunistic TLS
> from "export" to "medium.
>
> If you're not yet using one of the releases from mid July, or
> have set non-default values for either of:
>
> smtpd_tls_protocols
> smtpd_tls_ciphers
> smtp_tls_protocols
> smtp_tls_ciphers
>
> You should in most cases update main.cf by setting:
>
> # Exclude obsolete weak crypto.
> #
> smtpd_tls_protocols = !SSLv2, !SSLv3
> smtpd_tls_ciphers = medium
> smtp_tls_protocols = !SSLv2, !SSLv3
> smtp_tls_ciphers = medium
Why medium and not high, while we're at it? What clients would have
problems with it?
>
> this will disable obsolete SSL protocol versions and the weakest
> ciphersuites that are rarely if ever used, and should not be used
> going forward. The above settings are the defaults for the most
> recent Postfix versions.
>
> If you need to send email to Exchange 2003 servers (not necessarily
> your own), you might also want to set:
>
> # Drop "exotic" ciphers leaving room for RC4-SHA in the top 64
> #
> smtp_tls_exclude_ciphers = MD5, SRP, PSK, aDSS, kECDH, kDH, SEED, IDEA,
> RC2, RC5
>
> which disables very rarely used ciphersuites that are not expected
> to be required for interoperability, making it possible for Exchange
> 2003 SMTP servers to negotiate RC4-SHA, which is the best ciphersuite
> that software supports.
>
> With Postfix 2.11 or later, you don't need a file-based TLS session
> cache. Session tickets are better:
>
> # Empty is best with Postfix >= 2.11
> #
> smtpd_tls_session_cache_database =
>
> Finally, you should generally use 2048-bit rather than 1024-bit DH
> parameters:
>
> http://www.postfix.org/FORWARD_SECRECY_README.html#quick-start
>
> smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
> smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
>
> The 512-bit parameter file won't be used if you've disabled "EXPORT"
> ciphers by setting "smtpd_tls_ciphers = medium" as recommended
> above. You can even set:
>
> smtpd_tls_dh512_param_file = ${config_directory}/dh2048.pem
>
> which would likely result in handshake failure if a DHE EXPORT
> cipher were negotiated, which is arguably a safety feature. Worst
> case you'll be using an export ciphersuite with a key agreement
> protocol immune to LOGJAM.
>
Is usage of tls_preempt_cipherlist still recommended?
--
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas
Systemadministrator
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.schwe...@tao.at | +43 (0)680 301 7167
http://software.tao.at
signature.asc
Description: OpenPGP digital signature
Update to recommended TLS settings
Recent updates to the supported Postfix releases have updated the
default settings of the OpenSSL ciphers used for opportunistic TLS
from "export" to "medium.
If you're not yet using one of the releases from mid July, or
have set non-default values for either of:
smtpd_tls_protocols
smtpd_tls_ciphers
smtp_tls_protocols
smtp_tls_ciphers
You should in most cases update main.cf by setting:
# Exclude obsolete weak crypto.
#
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = medium
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_ciphers = medium
this will disable obsolete SSL protocol versions and the weakest
ciphersuites that are rarely if ever used, and should not be used
going forward. The above settings are the defaults for the most
recent Postfix versions.
If you need to send email to Exchange 2003 servers (not necessarily
your own), you might also want to set:
# Drop "exotic" ciphers leaving room for RC4-SHA in the top 64
#
smtp_tls_exclude_ciphers = MD5, SRP, PSK, aDSS, kECDH, kDH, SEED, IDEA,
RC2, RC5
which disables very rarely used ciphersuites that are not expected
to be required for interoperability, making it possible for Exchange
2003 SMTP servers to negotiate RC4-SHA, which is the best ciphersuite
that software supports.
With Postfix 2.11 or later, you don't need a file-based TLS session
cache. Session tickets are better:
# Empty is best with Postfix >= 2.11
#
smtpd_tls_session_cache_database =
Finally, you should generally use 2048-bit rather than 1024-bit DH
parameters:
http://www.postfix.org/FORWARD_SECRECY_README.html#quick-start
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
The 512-bit parameter file won't be used if you've disabled "EXPORT"
ciphers by setting "smtpd_tls_ciphers = medium" as recommended
above. You can even set:
smtpd_tls_dh512_param_file = ${config_directory}/dh2048.pem
which would likely result in handshake failure if a DHE EXPORT
cipher were negotiated, which is arguably a safety feature. Worst
case you'll be using an export ciphersuite with a key agreement
protocol immune to LOGJAM.
--
Viktor.
