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. (Not clear how you'd know this).
If your server might have already signed one or more export RSA
keys then its clients are potentially exposed to the attack for
the lifetime of the server's long-term RSA keys.
So, *after disabling* export grade algorithms, it may be prudent
as appropriate to deploy new certificates. If you've published
DANE TLSA records, follow the key rotation process described in:
https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1
Make sure to generate a new private/public key pair, rather than
just re-use the existing key for a new certificate. Make sure to
augment the TLSA record in DNS before deploying the new certificate,
wait 2 TTLs or so, then deploy the new certificate and drop the
obsolete instance of the TLSA record after.
Note that while Postfix clients that do mandatory TLS (authenticated
or not) do not enable EXPORT ciphers, the reason the FREAK bug is
important is that such clients accept ephemeral RSA key transport
with a 512-bit key anyway, while ostensibly negotiating a cipher-suite
that does regular RSA key transport. This is a failure to exclude
state transitions that should be disallowed in the SSL/TLS protocol
state-machine.
--
Viktor.
Hi All,
I'm trying to get to speed on the DANE implementation in Postfix, it appears to support only DANE certificate usage 2 (Trust anchor assertion) and 3 (Domain-issued certificate). Is there a particular reason why the public CA-signed certificate types wouldn't be supported as these are more likely (as of today, at least) to be installed on business and commercial platforms?
Extract from http://www.postfix.org/TLS_README.html#client_tls_dane:
"The Postfix SMTP client supports only certificate usages "2" and "3" (with "1" treated as though it were "3"). See tls_dane_trust_anchor_digest_enable for usage "2" usability considerations. Support for certificate usage "1" is an experiment, it may be withdrawn in the future. Server operators SHOULD NOT publish TLSA records with usage "1"."
Sincerely,
Kevin San Diego
Side question: why is there a reply to: ietf-dane(a)sys4.de <mailto:ietf-dane@sys4.de> in the post. Hitting simple reply makes it fail.
>
> On 20 Feb 2015, at 20:15, Viktor Dukhovni <ietf-dane(a)dukhovni.org <mailto:ietf-dane@dukhovni.org>> wrote:
>
> On Fri, Feb 20, 2015 at 08:01:09PM +0100, Andreas Fink wrote:
>
>
> Depends on what one one means by "fallback".
>>> How about support (as a fallback) for older clients? How "safe" (no pun
>>> intended) is it to disable as of today?
>>
>> Its simple: fallback = a MITM attacker can force fallback = youre pwned...
>>
Fall back in the sense of we tell the end user it was transported in a secure way but actually insecure encryption was used by the server and the MITM was able to decode it. If its acceptable to transfer in the clear in case TLS fails is something the mail operator might choose or not and it depends also on the specific link. For example I could say I know google mail supports TLS so only TLS would be permitted in my config but then if TLS steps down to RC4, i'm no longer protected from that assumption.
> When RC4 is enabled
> at a low preference MITM attackers cannot re-order the handshake
> without invalidating the TLS "finished" message.
Why this? a MITM attack implies the man in the middle terminates the TLS and thus he would in above example "mimic" the google mailserver's behaviour and simply would only offer RC4 inbound. Your sending mailserver would accept that as only option and use RC4 to deliver. So there's no "reordering" as its the only option provided. On the outbound connection, he simply would use a secure connection as usual to pass through the commands.
>
> I should be noted that, occasional bilateral security arrangements
> aside, MTA to MTA SMTP is generally vulnerable to MiTM attacks
> regardless of whether RC4 is enabled or not.
>
> With DANE, SMTP client MTAs can also authenticate servers for which
> no prior security settings exist, and in *that* case we have a
> fairly MiTM resistant protocol.
>
> In Postfix for peers that publish TLSA RRs, the "mandatory" TLS
> protocol, cipher and exclusion lists apply.
>
> By all means, try:
>
> smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
> smtp_tls_mandatory_exclude_ciphers = RC4
>
> If there are any domains that publish TLSA records for an SMTP
> server that is capable only of legacy crypto, both they and I will
> be surprised.
>
> --
> Viktor.
>
>
--
Andreas Fink
CEO DataCell ehf
CEO Backbone ehf
---------------------------------------------------------------
Tel: +41-61-6666330 Fax: +41-61-6666331 Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail: andreas(a)fink.org
www.datacell.com, www.backbone.is, www.finkconsulting.comwww.fink.org
---------------------------------------------------------------
Jabber/XMPP: andreas(a)fink.org
ICQ: 8239353 Skype: andreasfink
Support the reboot of the internet into secure mode: http://bootstrap.is <http://bootstrap.is/>
A little off topic for DANE users, but somehow in scope. You might consider
disabling RC4 in your servers cipher suite. IETF released an RFC requiring
(...) that Transport Layer Security (TLS) clients and servers never
negotiate the use of RC4 cipher suites when they establish connections.
This applies to all TLS versions. This document updates RFCs 5246, 4346,
and 2246.
-- Prohibiting RC4 Cipher Suites, https://tools.ietf.org/rfc/rfc7465.txt
p@rick
--
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Hi,
just from start i did the following steps:
1.) Our DNS provider has secured the domain veka.com with DNSSEC: http://dnssec-debugger.verisignlabs.com/veka.com
2.) I’ve computed "openssl x509 -in mail.veka.com.crt -outform DER | openssl sha256“ the 256bit hash from the complete certificate chain which is used by Postfix as well.
04459a87d803ee5d2450114c09e8370dc51b27716431378cfa5560e153aed957
3.) Our DNS provider has added this to the domain and has signed it again (no idea why there is a blank!).
_*._tcp.mail.veka.com. 3600 IN TLSA 3 0 1 04459A87D803EE5D2450114C09E8370DC51B27716431378CFA5560E1 53AED957
4.) I am still getting the error https://dane.sys4.de/smtp/veka.com
In TLSA 3 0 1 should be correct, right? I ma using the whole certificate chain for the hash, the same certificate file i’ve configured within Postfix.
_*._tcp.mail.veka.com. should be also working!
So what might be the problem now?
Kind regards!
Frank
--
Frank Fiene
IT-Security Manager VEKA Group
Fon: +49 2526 29-6200
Fax: +49 2526 29-16-6200
mailto: ffiene(a)veka.com
http://www.veka.com
PGP-ID: 62112A51
PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51
Threema: VZK5NDWW
VEKA AG
Dieselstr. 8
48324 Sendenhorst
Deutschland/Germany
Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler,
Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer
HRB 8282 AG Münster/District Court of Münster
Am 11.02.2015 um 13:55 schrieb Frank Fiene <ffiene(a)veka.com>:
Yeahhh.
I should have followed this from the beginning! ;-)
https://dane.sys4.de/smtp/fiene.iohttps://dane.sys4.de/smtp/veka.com
It is working for me now.
Many thanks to all!
>> Am 11.02.2015 um 13:31 schrieb Michael Schwartzkopff <ms(a)sys4.de>:
>>
>> Am Mittwoch, 11. Februar 2015, 07:16:54 schrieb John:
>>> On 2/11/2015 6:59 AM, Frank Fiene wrote:
>>>> Damned, don’t any short documentation. :-(
>>>>
>>>> I’ve seen this on a website with a howto.
>>>>
>>>>
>>>> I will test with all smtp Ports.
>>>> This should work for pop3s and imaps, too, shouldn’t it?
>>>> What is about pop3 and imap with TLS, the same?
>>>>
>>>>
>>>> Frank
>>>>
>>>>> Am 11.02.2015 um 12:44 schrieb John <john(a)klam.ca>:
>>>>>
>>>>> That should have read - I am not 100% certain, but I don't think you can
>>>>> use _*._tcp...... I think it has to be an actual port. In this case
>>>>> _25._tcp. ma....... --
>>>>> John Allen
>>>>> KLaM
>>>>> ------------------------------------------
>>>>> How many of you believe in telekinesis? Raise my hand...
>>>>
>>>> Viele Grüße!
>>>> i.A. Frank Fiene
>>>> --
>>>> Frank Fiene
>>>> IT-Security Manager VEKA Group
>>>>
>>>> Fon: +49 2526 29-6200
>>>> Fax: +49 2526 29-16-6200
>>>> mailto: ffiene(a)veka.com
>>>> http://www.veka.com
>>>>
>>>> PGP-ID: 62112A51
>>>> PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51
>>>> Threema: VZK5NDWW
>>>>
>>>> VEKA AG
>>>> Dieselstr. 8
>>>> 48324 Sendenhorst
>>>> Deutschland/Germany
>>>>
>>>> Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
>>>> Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner
>>>> Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board:
>>>> Ulrich Weimer HRB 8282 AG Münster/District Court of Münster
>>>
>>> This is my setup for smtp and submission -
>>>
>>> _25._tcp.smtp.klam.ca. IN CNAME tlsa301a._dane.klam.ca.
>>> _587._tcp.smtp.klam.ca. IN CNAME tlsa301a._dane.klam.ca.
>>> tlsa301a._dane.klam.ca. IN TLSA ( 3 0 1 5bf12300255d
>>>
>>> The credit for this goes to Viktor Dukhovni who advised me on how to set
>>> it up, without his input I would still be flailing around.
>>
>> Yes. Carsten wrote a nice article in German.
>> https://sys4.de/de/blog/2014/05/24/einen-tlsa-record-fuer-dane-mit-bind-9-p…
>>
>> It is really time to translate that doc.
>>
>> Mit freundlichen Grüßen,
>>
>> Michael Schwartzkopff
>>
>> --
>> [*] sys4 AG
>>
>> http://sys4.de, +49 (89) 30 90 46 64, +49 (162) 165 0044
>> Franziskanerstraße 15, 81669 München
>>
>> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
>> Vorstand: Patrick Ben Koetter, Marc Schiffbauer
>> Aufsichtsratsvorsitzender: Florian Kirstein
>
> Viele Grüße!
> i.A. Frank Fiene
> --
> Frank Fiene
> IT-Security Manager VEKA Group
>
> Fon: +49 2526 29-6200
> Fax: +49 2526 29-16-6200
> mailto: ffiene(a)veka.com
> http://www.veka.com
>
> PGP-ID: 62112A51
> PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51
> Threema: VZK5NDWW
>
> VEKA AG
> Dieselstr. 8
> 48324 Sendenhorst
> Deutschland/Germany
>
> Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
> Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler,
> Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer
> HRB 8282 AG Münster/District Court of Münster
>
Viele Grüße!
i.A. Frank Fiene
--
Frank Fiene
IT-Security Manager VEKA Group
Fon: +49 2526 29-6200
Fax: +49 2526 29-16-6200
mailto: ffiene(a)veka.com
http://www.veka.com
PGP-ID: 62112A51
PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51
Threema: VZK5NDWW
VEKA AG
Dieselstr. 8
48324 Sendenhorst
Deutschland/Germany
Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler,
Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer
HRB 8282 AG Münster/District Court of Münster
Hi --
Very recently I started to implement and investigate DNSSEC and DANE at a test server (separate FreeBSD jail with postfix). I am using OpenDNSSEC for key rollover management and KSKs and ZSKs with 2048-bits and algorithm 8. While learning (Open)DNSSEC I made a mistake (misuse of OpenDNSSEC functionality) and screwed my chain of trust, thus making my test server "unknown" to DNS. Well, I learned how to deal with that, but that experience made me think about a "fallback" setup for hosts that somehow managed to screw their chain of trust as well.
http://www.postfix.org/TLS_README.html#client_tls_dane shows me an opt-in approach for opportunistic DANE (if I am not completely misunderstanding).
What I want to implement is an opportunistic DANE approach with fallback to opportunistic TLS for "DANE broken" hosts, and implemented:
postconf -n | grep ^smtp_:
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_generic_maps = pcre:/usr/local/etc/postfix/smtp_generic_maps
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols = !SSLv2 !SSLv3
smtp_tls_note_starttls_offer = yes
smtp_tls_protocols = !SSLv2 !SSLv3
plus "broken" hosts:
transport_maps = pcre:/usr/local/etc/postfix/transport_maps
/usr/local/etc/postfix/transport_maps
/^example\.com/ opportunistic-tls
master.cf:
opportunistic-tls unix - - n - - smtp
-o syslog_name=postfix/otls
-o smtp_dns_support_level=enabled
-o smtp_tls_security_level=may
This is working on my test server, but before implementing that scheme on my productive server[1], I'd like to ask you experts out there:
Do I miss something that might break my approach? Or, is there a more elegant way to implement a fallback oTLS?
Thanks and regards,
Michael
[1] only a handful users, but outgoing mail should not fail, never :-)
Should I be signing my ip6.arpa. zones.
Is ip6.arpa signed, and is so how do add my zone to the root.
--
John Allen
KLaM
------------------------------------------
If you are out to describe the truth, leave elegance to the tailor.
