On Sat, May 24, 2014 at 06:59:11PM +0200, Patrick Ben Koetter wrote:

> Works for me:
> 
> p@mail:~$ posttls-finger -t30 -T180 -c -L verbose,summary bund.de
> posttls-finger: Verified TLS connection established to 
> mx2.bund.de[77.87.228.110]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 
> bits)

And for me, even from my PBL-listed road-runner dynamic IP.  Sensibly short
TLSA TTLs, and separate certs on each MX host:

    $ dig +noall +ad +comment +ans -t mx bund.de
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 6

    ;; ANSWER SECTION:
    bund.de.                21600   IN      MX      10 mx2.bund.de.
    bund.de.                21600   IN      MX      10 mx1.bund.de.

    $ dig +noall +ad +comment +ans -t tlsa _25._tcp.mx1.bund.de
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4

    ;; ANSWER SECTION:
    _25._tcp.mx1.bund.de.   900     IN      TLSA    3 0 1 
CC7C93BF7367FD0E47F4399D9CDF2A53DA0DCC4C86DEA331EA894ACF D91351A7

    $ dig +noall +ad +comment +ans -t tlsa _25._tcp.mx2.bund.de
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4

    ;; ANSWER SECTION:
    _25._tcp.mx2.bund.de.   900     IN      TLSA    3 0 1 
59E3CF5FA151553F4576C94C2500D705EFDDD855B6A59D88D28D0328 876A04CB

    $ posttls-finger -c -Lsummary bund.de
    posttls-finger: Verified TLS connection established to 
mx1.bund.de[77.87.224.163]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 
bits)

The MX hosts in question can also probably pass PKIX for anyone
who wants to manually configure "secure" with "bund.de", the chain
for "mx2" is:

    subject=/C=DE/O=Service/OU=ivbb-betrieb/L=ivbb-betrieb/CN=mx2.bund.de
    issuer=/C=DE/O=PKI-1-Verwaltung/OU=Bund/CN=CA IVBB Deutsche Telekom AG 11

    subject=/C=DE/O=PKI-1-Verwaltung/OU=Bund/CN=CA IVBB Deutsche Telekom AG 11
    issuer=/C=DE/O=PKI-1-Verwaltung/CN=PCA-1-Verwaltung-10

    subject=/C=DE/O=PKI-1-Verwaltung/CN=PCA-1-Verwaltung-10
    issuer=/C=DE/O=PKI-1-Verwaltung/CN=PCA-1-Verwaltung-10

The subjectAltName is just the MX hostname just like the CN, so
when not using a DNSSEC-validating resolver, one would use the
default "nexthop, dot-nexthop" match patterns.  With a DNSSEC
validating resolver, the MX lookup is no longer insecure, so
you could use:

    bund.de secure match=nexthop,hostname

The advantage of DANE is that no per-destination manual configuration
is required.

-- 
        Viktor.

Reply via email to