DevHeads.net

Postings by Viktor Dukhovni

TLS X.509 certificate hygiene...

I've recently come across an interoperability problem between my
DANE survey scan engine and some STARTTLS implementations on remote
SMTP servers.

Reminder DNSSEC Root KSK roll today

In case you've not seen this many other places, just a friendly
reminder that ICANN is rolling the DNSSEC root KSK today. Make
sure your resolver (if it is validating) is ready. If you're
forwarding queries to an upstream resolver, you might also check
that the upstream is ready.

Exempting submission from RBL lookups.

[ You really must start a new thread when posting on a new topic.
DO NOT reply to a previous message, that breaks message threading.

DANE-TA(2) private CAs and SHA-1

By using DANE-TA(2) TLSA records you can associate your SMTP server
with a either a public or private (your own) issuer CA. This can
simplify the management of TLSA records of multiple MX hosts by
using a CNAME to a common location where you publish the shared CA
key hash.

Some care needs to be take to make sure that certificate chains
issued by a private CA can be successfully validated by correctly
configured DANE TLS clients.

1.

New EFF certbot plugin for Postfix

The EFF announced a certbot plugin for Postfix today, which
is still in beta. A couple of things to keep in mind:

* If you've already deployed DANE, this stands a good chance
of breaking your DANE TLSA records. For the moment do not
deploy this if have inbound DANE.

* Do consider sharing any substantive experience (issues you
had to resolve that may say others grief).

Recording of DANE talk at ICANN61

[ Also posted to <a href="mailto:dane- ... at sys4 dot de">dane- ... at sys4 dot de</a>, please pardon the duplication if
you're reading both lists. I'm planning to also post to exim-users
and <a href="mailto: ... at ietf dot org"> ... at ietf dot org</a> ]

I gave a talk about DANE for SMTP at the ICANN61 conference last week.
Audio and slides are available, but not a synchronized recording so if
you want to follow along you'll need to figure out the slide transitions
from the context of the audio. I was promised 45 minutes, had too much
material even for that, but only got 35 minutes, and yet managed to get
to most of the key points.

FWIW, port 465 gets standards-track blessing from RFC8314

<a href="https://tools.ietf.org/html/rfc8314#section-3.3" title="https://tools.ietf.org/html/rfc8314#section-3.3">https://tools.ietf.org/html/rfc8314#section-3.3</a>

The STARTTLS mechanism on port 587 is relatively widely deployed due
to the situation with port 465 (discussed in Section 7.3). This
differs from IMAP and POP services where Implicit TLS is more widely
deployed on servers than STARTTLS. It is desirable to migrate core
protocols used by MUA software to Implicit TLS over time, for
consistency as well as for the additional reasons discussed in
Appendix A.

Upgrade unbound resolver to 1.6.8 if used for DANE

If you're using unbound as your local DNSSEC-validating
resolver and have enabled DANE, an issue is resolved in
unbound 1.6.8 where NSEC records for wildcards could be
misused for invalid denial-of-existence proofs. See:

<a href="https://medium.com/nlnetlabs/the-peculiar-case-of-nsec-processing-using-expanded-wildcard-records-ae8285f236be" title="https://medium.com/nlnetlabs/the-peculiar-case-of-nsec-processing-using-expanded-wildcard-records-ae8285f236be">https://medium.com/nlnetlabs/the-peculiar-case-of-nsec-processing-using-...</a>
<a href="https://unbound.net/downloads/CVE-2017-15105.txt" title="https://unbound.net/downloads/CVE-2017-15105.txt">https://unbound.net/downloads/CVE-2017-15105.txt</a>

The first article mentions that the same issue affected
PowerDNS and Dnsmasq. So if you're using one of those,
you might also need to update.

New DANE SMTP monitoring and diagnostic utility

I am pleased to offer to the DANE user community a new monitoring
and diagnostic utility. This is a one-shot variant of my survey
code specialized for monitoring cron jobs and troubleshooting.

Code and instructions at <a href="https://github.com/vdukhovni/danecheck" title="https://github.com/vdukhovni/danecheck">https://github.com/vdukhovni/danecheck</a>

While Haskell may be an unfamiliar programming development toolchain
for many of you, I hope that it will not be difficult to install it
for the purpose of compiling an existing project.

Ironic interaction of greylistiing, backup MX hosts and DANE

[ To be sent separately also to the <a href="mailto:dane- ... at sys4 dot de">dane- ... at sys4 dot de</a> list. ]

I sent a "please fix your TLSA records" notice to "postmaster" and
"info" at a domain whose primary MX host certificate fails to match
its TLSA records:

postfix/pickup[62805]: 7672C1DD39: ...
postfix/cleanup[63835]: 7672C1DD39: message-id=<...>
postfix/qmgr[844]: 7672C1DD39: from=<...>, size=8815, nrcpt=2 (queue active)
postfix/smtp[63837]: 7672C1DD39: host mail.example.nl[192.0.2.1]
said: 450 4.2.0 ...

LibreSSL certificate verification issue

Please see:

<a href="http://seclists.org/oss-sec/2017/q2/145" title="http://seclists.org/oss-sec/2017/q2/145">http://seclists.org/oss-sec/2017/q2/145</a>

## Summary

LibreSSL 2.5.1 to 2.5.3 lacks TLS certificate verification if
SSL_get_verify_result is relied upon for a later check of a
verification result, in a use case where a user-provided verification
callback returns 1, as demonstrated by acceptance of invalid
certificates by nginx.

This also affects Postfix, and will make all connections appear to be
"Trusted" or "Verified" even when certificate verification actually
failed.

Postfix is only supported with OpenSSL and not LibreSSL.

When to use mandatory TLS ("encrypt", ...)

You use mandatory TLS when all your mail is sent to a small set of
relay hosts that are known to support TLS. If these have usable
certificates you can verify, you should consider using "secure" to
guard against active attacks, otherwise use "encrypt".

WoSign/StartCom CA in the news

WoSign (who seemingly purchased StartCom) seem to have run into
some compliance issues as reported by Firefox:

<a href="http://arstechnica.com/security/2016/09/firefox-ready-to-block-certificate-authority-that-threatened-web-security/" title="http://arstechnica.com/security/2016/09/firefox-ready-to-block-certificate-authority-that-threatened-web-security/">http://arstechnica.com/security/2016/09/firefox-ready-to-block-certifica...</a>

Many SMTP servers are using certs from StartCom. In my DANE
adoption survey, out of 2201 certificates used by DANE MX
hosts 411 are issued by StartCom and 47 by WoSign. So that's
just over 20% of observed certificates.

NEWSFLASH: DANE TLSA records published for web.de!

The web.de domain has just published DANE TLSA records for its MX
hosts. This follows earlier "pilot" deployments with the smaller
mail.com and mail.de domains.

web.de. IN MX 100 mx-ha02.web.de. ; AD=1
_25._tcp.mx-ha02.web.de. IN TLSA 3 1 1 409c9e91a2a9f4d7881dbf0094b3839d4343a4a57d9bf559fdeb0c1f4c5b8b3e ; passed

Subject = CN=mx-ha02.web.de,emailAddress=server- ... at 1und1 dot de,L=Montabaur,ST=Rhineland-Palatinate,O=1&1 Mail & Media GmbH,C=DE
Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr.

Mitigating DROWN

Some of the servers that expose TLS to cross-protocol DROWN attacks
via SSLv2 are MTAs running Postfix. If you're using an older
Postfix release (released prior to July 20 2015), or you've explicitly
configured TLS settings that may have enabled SSLv2, please update
your configuration as suggested below:

# Minimal recommended settings. Whenever the built-in defaults are
# sufficient, let the built-in defaults stand by deleting any explicit
# overrides.

Importance of keeping DANE TLSA records correct.

Until now, most DANE deployments have been on small hobbyist
machines, by people who mostly don't correspond with each other.
So if a particular domain's TLSA RRs were broken, nobody noticed.

This is about to change. The German email providers web.de and
gmx.de have announced upcoming DANE support (by the end of this
year). What this means for the hobbyist early adopters is that
forgetting/failing to do key/cert rollover correctly will soon
lead to lost mail.

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

RC4 in live email servers?

You've likely all been hearing that RC4 is on its way out, with
increasingly practical attacks to extract fixed plaintext that is
sent repeatedly in lots of messages (e.g. HTTP cookies).

While it is not clear how to extend these attacks to MTA-to-MTA
SMTP (except when SASL PLAIN auth is used), there is some merit in
trying to phase out support for RC4.

Before that's done however, I would like to have some evidence that
the need for RC4 is diminishing. Therefore, I'd like to ask the
list whether you're seeing declining use of RC4 in your TLS
connections (inbound or outbound).

FREAK cipher-suite hygiene for Postfix

Now that the FREAK attack is widely disclosed, those of you who
run SMTP servers that peer with clients that authenticate your
server (be it via the traditional PKI or via DANE), might want to
tighten-up your server cipher-suite settings just in-case:

smtpd_tls_exclude_ciphers = EXPORT, LOW

If nobody has yet elicited and factored any 512-bit RSA public keys
from your server then your unpatched clients will be safe from the
attack.

2.12-20141119 NetBSD6+ shared lib and dynamicmaps support. Also support for NetBSD7

The NetBSD7 sys_defs.h change and new case pattern in makedefs are
taken from NetBSD pkgsrc.

FYI: Null MX back from the dead

In the RFC editor queue as of 2014-08-29:

<a href="https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/" title="https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/">https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/</a>

Updating Access(5) checks and live smtpd(8) processes

One quick comment about check_sasl_access and established
sessions. This may not work reliably with Berkeley DB.

It is best to use a SQL, LDAP, ... database. I haven't checked
whether tinycdb (when not chrooted) automatically re-opens updated
".cdb" files. If so, CDB might work too.

Experimental TLS auth fallback code

My github Postfix repo:

<a href="https://github.com/vdukhovni/postfix" title="https://github.com/vdukhovni/postfix">https://github.com/vdukhovni/postfix</a>

has a "tlsfallback" branch, which extends Postfix with two new
pairs (smtp and lmtp flavours) of parameters (postconf(5) documentation
snippets below). I am soliciting feedback on the interface and
any operational experience if anyone is willing to test the code
on a live system.

OpenSSL 1.0.1g and Ironport SMTP appliances interop issue

[ Original openssl-users thread subject:
openssl update 1.0.1f to 1.0.1g broke sendmail ... ]

In a thread on the openssl-users list there is a report of an
upgrade to OpenSSL 1.0.1g (to deal with "Heartbleed") causing one
Sendmail system delivery problems to a few sites.

Postfix: OpenSSL 1.0.1[de] (upgrade to 1.0.1f recommended)

Though the problem is somewhat infrequent, OpenSSL 1.0.1d and 1.0.1e
will at times incorrectly compute the SSL message-authentication-code
(or MAC) on systems with Intel AES-NI hardware AES support.

From OpenSSL git history:

9ab3ce1 e_aes_cbc_hmac_sha1.c: fix rare bad record mac on AES-NI plaforms.

There are additional problems in 1.0.1d. If you build your own
OpenSSL version (1.0.1 branch) for linking with Postfix, use at
least 1.0.1f.

Note, some O/S distributions backport selected patches without
updating the package version number.

DANE and DNSSEC adoption

Sure, you can validate other people's domains even if your own
domain is not signed. These are independent.

Re: mynetworks hash issue

One more thing to keep in mind. When used with mynetworks, as
I already explained the RHS of the table entries is ignored.

Therefore, your attempt at a reject rule:

10.147.11.11 reject

is completely ineffective.

Domain RDN sequence substitution for LDAP search base.

If anyone is using LDAP for virtual hosting with a separate search
base for each hosted domain using domain component RDNs, please
reply on list whether the feature below is useful, and whether you
tested the code and found that it works for you (once a handful of
people respond that this is useful, that'll be enough, you can
test with a custom-built "postmap" binary if you like, without
upgrading Postfix).

Limitation: Because this expansion applies only to user@address
queries, it cannot be used to define the set of domains in
virtual_mailbox_domains or virtual_alias_domains.