From ietf-dane at dukhovni.org Fri Feb 10 21:25:41 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Fri, 10 Feb 2017 20:25:41 +0000
Subject: Don't forget to add TLSA records for black-hole MX hosts
Message-ID: <20170210202541.GZ28349@mournblade.imrryr.org>
Some domains with DANE-TLSA records for their primary MX hosts
neglect to publish DANE TLSA for secondary and/or "black-hole"
(spam magnet) MX hosts.
Consider nic.cz, until recently their "bh.nic.cz" host had no TLSA
records (and SMTP connections to that host would time out). This
gives an active on-path MiTM attacker opportunity to block connections
to the working MX hosts, and accept unauthenticated connections to
the black-hole MX host. After they were notified of the problem,
they made changes, and now we see TLSA records associated with
all the MX hosts, including "bh.nic.cz":
nic.cz. IN MX 10 mail.nic.cz. ; NOERROR AD=1
nic.cz. IN MX 20 mx.nic.cz. ; NOERROR AD=1
nic.cz. IN MX 30 bh.nic.cz. ; NOERROR AD=1
;
mail.nic.cz. IN A 217.31.204.67 ; NOERROR AD=1
mail.nic.cz. IN AAAA 2001:1488:800:400::400 ; NOERROR AD=1
_25._tcp.mail.nic.cz. IN TLSA 3 1 1 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; NOERROR AD=1
;
mx.nic.cz. IN A 217.31.58.56 ; NOERROR AD=1
mx.nic.cz. IN AAAA 2001:1ab0:7e1e:c574:7a2b:cbff:fe33:7019 ; NOERROR AD=1
_25._tcp.mx.nic.cz. IN TLSA 3 1 1 aa7b93daab084536530bd3256e9ceff4557cb43512640f7ab64487dc9ca14fab ; NOERROR AD=1
;
bh.nic.cz. IN A 217.31.204.252 ; NOERROR AD=1
bh.nic.cz. IN AAAA ? ; NODATA AD=1
_25._tcp.bh.nic.cz. IN TLSA 3 1 1 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; NOERROR AD=1
I've not yet nagged "iis.se" or "wia.cz", and there we see that
only one of the two MX hosts has a TLSA record:
iis.se. IN MX 5 mx1.iis.se. ; NOERROR AD=1
iis.se. IN MX 5 mx2.iis.se. ; NOERROR AD=1
;
mx1.iis.se. IN A 91.226.36.35 ; NOERROR AD=1
mx1.iis.se. IN AAAA 2a00:801:f0:106::35 ; NOERROR AD=1
_25._tcp.mx1.iis.se. IN TLSA 3 1 1 0894a6827f435ccb7435552290ff13e704776e4568235bbc899f515de3314ce3 ; NOERROR AD=1
;
mx2.iis.se. IN A 91.226.37.39 ; NOERROR AD=1
mx2.iis.se. IN AAAA 2001:67c:124c:2007::39 ; NOERROR AD=1
_25._tcp.mx2.iis.se. IN TLSA ? ; NXDOMAIN AD=1
wia.cz. IN MX 10 antispam.wia.cz. ; NOERROR AD=1
wia.cz. IN MX 20 bntispam.wia.cz. ; NOERROR AD=1
;
antispam.wia.cz. IN A 80.250.3.18 ; NOERROR AD=1
antispam.wia.cz. IN AAAA ? ; NODATA AD=1
_25._tcp.antispam.wia.cz. IN TLSA 3 1 1 3b67e777e8a11d373fae958c3ea5a200bd791813c0e6e9be34e2965bcfcc071e ; NOERROR AD=1
;
bntispam.wia.cz. IN A 31.7.247.78 ; NOERROR AD=1
bntispam.wia.cz. IN AAAA ? ; NODATA AD=1
_25._tcp.bntispam.wia.cz. IN TLSA ? ; NXDOMAIN AD=1
While during initial deployment it is natural to proceed incrementally
and add TLSA records to one MX host at a time, and test thoroughly
before moving on to the rest, the end-state should be to publish
TLSA records for all MX hosts, not a proper subset.
--
Viktor.
From alex.dupuy at mac.com Mon Feb 13 14:40:35 2017
From: alex.dupuy at mac.com (Alexander Dupuy)
Date: Mon, 13 Feb 2017 08:40:35 -0500
Subject: Don't forget to add TLSA records for black-hole MX hosts
In-Reply-To: <20170210202541.GZ28349@mournblade.imrryr.org>
References: <20170210202541.GZ28349@mournblade.imrryr.org>
Message-ID: <3107E22F-A11B-4E7D-9C3E-071636466017@mac.com>
The wonderful Internet.nl website and e-mail security and standards compliance checker, which was the first thing I thought of when I saw this message from Viktor, doesn?t currently check for TLSA records for MX hosts (although it does check for DNSSEC on the zones of MX hostnames, e.g. https://internet.nl/mail/dns-example.info/results# ). It would be wonderful if that functionality could be added in a future update to their site. Does NLnet Labs , which develops the software for this great checking tool, have a public repository for it? If so, I would be happy to submit a pull-request or patch to add that functionality.
@alex
p.s. could someone at Internet.nl please add Verisign Public DNS (https://www.verisign.com/en_US/security-services/public-dns/index.xhtml ) to the list of DNSSEC-validating public DNS services at https://internet.nl/faqs/dnssec/? They are the first major public DNS service after Google Public DNS to provide this feature, present from day one of their service (even though they don?t mention it), and they should be listed.
> On 2017-02-10, at 15:25, Viktor Dukhovni wrote:
>
>
> Some domains with DANE-TLSA records for their primary MX hosts
> neglect to publish DANE TLSA for secondary and/or "black-hole"
> (spam magnet) MX hosts.
>
> Consider nic.cz, until recently their "bh.nic.cz" host had no TLSA
> records (and SMTP connections to that host would time out). This
> gives an active on-path MiTM attacker opportunity to block connections
> to the working MX hosts, and accept unauthenticated connections to
> the black-hole MX host. After they were notified of the problem,
> they made changes, and now we see TLSA records associated with
> all the MX hosts, including "bh.nic.cz":
>
> nic.cz. IN MX 10 mail.nic.cz. ; NOERROR AD=1
> nic.cz. IN MX 20 mx.nic.cz. ; NOERROR AD=1
> nic.cz. IN MX 30 bh.nic.cz. ; NOERROR AD=1
> ;
> mail.nic.cz. IN A 217.31.204.67 ; NOERROR AD=1
> mail.nic.cz. IN AAAA 2001:1488:800:400::400 ; NOERROR AD=1
> _25._tcp.mail.nic.cz. IN TLSA 3 1 1 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; NOERROR AD=1
> ;
> mx.nic.cz. IN A 217.31.58.56 ; NOERROR AD=1
> mx.nic.cz. IN AAAA 2001:1ab0:7e1e:c574:7a2b:cbff:fe33:7019 ; NOERROR AD=1
> _25._tcp.mx.nic.cz. IN TLSA 3 1 1 aa7b93daab084536530bd3256e9ceff4557cb43512640f7ab64487dc9ca14fab ; NOERROR AD=1
> ;
> bh.nic.cz. IN A 217.31.204.252 ; NOERROR AD=1
> bh.nic.cz. IN AAAA ? ; NODATA AD=1
> _25._tcp.bh.nic.cz. IN TLSA 3 1 1 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; NOERROR AD=1
>
> I've not yet nagged "iis.se" or "wia.cz", and there we see that
> only one of the two MX hosts has a TLSA record:
>
> iis.se. IN MX 5 mx1.iis.se. ; NOERROR AD=1
> iis.se. IN MX 5 mx2.iis.se. ; NOERROR AD=1
> ;
> mx1.iis.se. IN A 91.226.36.35 ; NOERROR AD=1
> mx1.iis.se. IN AAAA 2a00:801:f0:106::35 ; NOERROR AD=1
> _25._tcp.mx1.iis.se. IN TLSA 3 1 1 0894a6827f435ccb7435552290ff13e704776e4568235bbc899f515de3314ce3 ; NOERROR AD=1
> ;
> mx2.iis.se. IN A 91.226.37.39 ; NOERROR AD=1
> mx2.iis.se. IN AAAA 2001:67c:124c:2007::39 ; NOERROR AD=1
> _25._tcp.mx2.iis.se. IN TLSA ? ; NXDOMAIN AD=1
>
> wia.cz. IN MX 10 antispam.wia.cz. ; NOERROR AD=1
> wia.cz. IN MX 20 bntispam.wia.cz. ; NOERROR AD=1
> ;
> antispam.wia.cz. IN A 80.250.3.18 ; NOERROR AD=1
> antispam.wia.cz. IN AAAA ? ; NODATA AD=1
> _25._tcp.antispam.wia.cz. IN TLSA 3 1 1 3b67e777e8a11d373fae958c3ea5a200bd791813c0e6e9be34e2965bcfcc071e ; NOERROR AD=1
> ;
> bntispam.wia.cz. IN A 31.7.247.78 ; NOERROR AD=1
> bntispam.wia.cz. IN AAAA ? ; NODATA AD=1
> _25._tcp.bntispam.wia.cz. IN TLSA ? ; NXDOMAIN AD=1
>
> While during initial deployment it is natural to proceed incrementally
> and add TLSA records to one MX host at a time, and test thoroughly
> before moving on to the rest, the end-state should be to publish
> TLSA records for all MX hosts, not a proper subset.
>
> --
> Viktor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL:
From john at klam.ca Sun Feb 19 19:20:52 2017
From: john at klam.ca (John Allen)
Date: Sun, 19 Feb 2017 13:20:52 -0500
Subject: Letsencrypt & TLSA - automation
Message-ID: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
Attached is a bash script that I am developing to automate the
generation of TLSA records from Letsencrypt certificates.
the script is called from the certbot renew hook, it can also be run
stand alone - Certbot_TLSAgen path-to-certificate "space separated list
of domains included in cert"
It seems to work, but would some kind sole take a look and where I have
or are about to screw up.
Any suggestions as to how to get the output into my DNS (Bind9)
preferably without using nsupdate. I am not keen on nsupdate as it makes
a mess of the zone files, which I use as documentation for my DNS.
Has anybody heard of a electronic "one time pad" system.
TIA
JohnA
-------------- next part --------------
#!/bin/bash
#=====================================================================================================================
#
# Copyright (c) 2017 John L. Allen
#
# This program is free software: you can redistribute it and/or modify it under the terms of the
# GNU General Public License as published by the Free Software Foundation, either version 3 of the License,
# or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
# without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see .
#
#=====================================================================================================================
declare -a TLSA_Services=( smtp imap submission sieve dav davical https ) # An arrrayof services for which TLSA might be needed
# these two variables are ????
Certbot_Lineage= # path to the certbot generated cert ...(RENEWED_LINEAGE or $1)
declare -a Certbot_Domains # An array into which RENEWED_DOMAINS or $2 Domains are split
# default values
#TLSA_File_Path="/etc/bind/tlsa/" # where do you want to put the TLSA records, default values
TLSA_File_Path="./tlsa_test/" # where do you want to put the TLSA records, default values - during testing
TLSA_Filename_Base="tlsa" # base filename for the TLSA records - generated as base_filename.sequence_number
TLSA_TTL=3600 # TLSA DNS record TTL
TLSA_Usage=3 # TLSA usage
TLSA_Selector=1 # TLSA selector
TLSA_Type=1 # TLSA type
#
#=====================================================================================================================
#===================Message output function - will need changing to output multi language message=====================
function error_message() {
echo $1 1>&2
exit 1
}
#=====================================================================================================================
#================ Check of either the Certbot set environment variables or the command line paramater=================
#================ depending upon how this script is invocked =================
#=====================================================================================================================
function Check_Env_Variables()
{
# Has command line parameter 1 or the environment variable RENEWED_LINEAGE been set.
# The Command line parameter overides the environment variable
[[ -z $RENEWED_LINEAGE ]] && Certbot_Lineage=$1 || Certbot_Lineage=$RENEWED_LINEAGE
if [[ -z $Certbot_Lineage ]]; then
error_code= $(error_message "Command line parameter 1 or the evironment variable \"RENEWED_LINEAGE\" was not set, exiting")
elif ! [[ -d $Certbot_Lineage ]]; then
error_code= $(error_message "Command line parameter 1 or the evironment variable \"RENEWED_LINEAGE\" is not a directory, exiting")
fi
# Has command line parameter 2 or the environment variable RENEWED_DOMAINS been set.
# The Command line parameter overides the environment variable
# If more than one domain is specified they are expected to be in the form of a space seperated list
[[ -z $RENEWED_DOMAINS ]] && Certbot_Domains=( $2 ) || Certbot_Domains=( ${RENEWED_DOMAINS} )
if [[ ${#Certbot_Domains[@]} -le 0 ]]; then
error_code=$(error_message "Command line parameter 2 or the evironment variable \"RENEWED_DOMAINS\" was not set, exiting")
fi
# Check that the TLSA_File_Path is the location (directory) where files containing the generated TLSA records will be put
#
if ! [ -d $TLSA_File_Path ]; then
error_code=$(error_message "the directory $TLSA_File_Path does not exist, please specify where the generated records are to be stored")
fi
# Check that the TLSA filename base has been set.
# The filename base is used to generate actual filenames in the form of base.sequence
#
if [ -z "$TLSA_Filename_Base" ]; then
error_code=$(error_message "Please specify a base filename into which the generated TLSA records can be placed")
fi
return $error_code
}
#=====================================================================================================================
#=======Set the output file name, including path.
#=======The filename is derived from TLSA_Filename_Base plus a generated serial number suffix
zzz=" "
function Set_Output_Destination()
{
count=$( ls -1 $1 | wc -l )
name=$(printf "%s%s.%04d" "$1" "$2" "$count")
while [ -a $name ]; do
count=$(( $count+1))
name=$(printf "%s%s.%04d" "$1" "$2" "$count")
done
echo $name
}
#=====================================================================================================================
#********************************************************************************************************************
#********************************************************************************************************************
# THe following functions were stolen from Viktor Dukhovni's tlsagen
#********************************************************************************************************************
#********************************************************************************************************************
#=====================================================================================================================
extract() {
case "$1" in
0) openssl x509 -in "$2" -outform DER;;
1) openssl x509 -in "$2" -noout -pubkey | openssl pkey -pubin -outform DER;;
esac
}
digest() {
case "$1" in
0) cat;;
1) openssl dgst -sha256 -binary;;
2) openssl dgst -sha512 -binary;;
esac
}
Set_TLSA_Usage() {
case "$(echo $1 | tr '[A-Z]' '[a-z]')" in
0|pkix-[ct]a) TLSA_usage=0;;
1|pkix-ee) TLSA_usage=1;;
2|dane-[ct]a) TLSA_usage=2;;
3|dane-ee) TLSA_usage=3;;
*) error "Invalid certificate usage: $1";;
esac
}
Set_TLSA_Selector() {
case "$(echo $1 | tr '[A-Z]' '[a-z]')" in
0|cert) TLSA_selector=0;;
1|spki|pkey) TLSA_selector=1;;
*) error "Invalid selector: $1";;
esac
}
Set_TLSA_Type() {
case "$(echo $1 | tr '[A-Z]' '[a-z]')" in
0|full) TLSA_Type=0;;
1|sha2-256|sha256|sha-256) TLSA_Type=1;;
2|sha2-512|sha512|sha-512) TLSA_Type=2;;
*) error "Invalid matching type: $1";;
esac
}
#=====================================================================================================================
#=====================================================================================================================
# as we cannot pass and parameters when this is called from the certbot renew hooks
# we will have to put them somewhere else,
# Defailt for general parameters
#
if [ -f /etc/default/Cerbot_TLSAgen.cf ]; then . /etc/default/Cerbot_TLSAgen.cf; fi
Check_Env_Variables "$1" "$2" # If we are running as a command then these two should be set, if not certbot environment variables should be
[[ $? != 0 ]] && exit # ooops! exit. this needs some improvement
#******needs testing
# Certbot_Lineage should now be set, so pick up any cert based paramamters from the ".../live/certname" directory
#
if [ -f ${Certbot_Lineage}Certbot_TLSAgen.cf ]; then . ${Certbot_Lineage}Certbot_TLSAgen.cf; fi
TLSA_Record_Store=$(Set_Output_Destination $TLSA_File_Path $TLSA_Filename_Base) # generate the output file location Path + generate filename
[[ $? != 0 ]] && exit # ooops! exit. this needs some improvement
TLSA_Digest=$( extract $TLSA_Selector ${Certbot_Lineage}cert.pem | digest $TLSA_Type | od -vAn -tx1 | tr -d ' \012' # Generate the TLSA key as a HEX string. As we are dealiing with a single cert do this once
exit $(( ${PIPESTATUS[0]} | ${PIPESTATUS[1]} | ${PIPESTATUS[2]} )) )
[[ $? != 0 ]] && exit # ooops! exit. this needs some improvement
# for each (sub)domain listed, check to see if it is a service doamin that we might like to have a TLSA record for
#
for domain in $( seq 0 $((${#Certbot_Domains[@]} -1 )) ); do
TLSA_target=${Certbot_Domains[domain]%.} # I am not sure whether the Cerbot list of (sub)domains has a trailing "."
TLSA_domain=${TLSA_target#*.} # Hopefully this will strip off the sub-domain part giving me a domain-name + TLD
if [[ -z "${TLSA_domain##*.*}" ]]; then # Primitive test - if there is a "." this is likely to be domin + TLD
for service in $( seq 0 $((${#TLSA_Services[@]} -1 )) ); do # Do this for each of the services that might us a TLSA record
while read srv_priority srv_weight srv_port srv_host; # read the out put of a DIG for a SRV record
do
if [ ${srv_host%.} == $TLSA_target ]; then # if the host returned by dig = the Cerbot target output a TLSA record
printf "_%d._tcp.%s %d IN TLSA %d %d %d %s\n"\
"$srv_port" "$srv_host" "$TLSA_TTL" "$TLSA_Usage" "$TLSA_Selector" "$TLSA_Type" "$TLSA_Digest" >> $TLSA_Record_Store
fi
done < <(dig SRV _${TLSA_Services[$service]}._tcp.${TLSA_domain} +short) #
done
# SOA_domain=$TLSA_domain
# read soa_ns soa_admin soa_seq soa_t1 soa_t2 soa_t3 soa_t4 < <(dig SOA $SOA_domain +short)
fi
done
From dgouttegattat at incenp.org Sun Feb 19 20:02:28 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sun, 19 Feb 2017 20:02:28 +0100
Subject: Letsencrypt & TLSA - automation
In-Reply-To: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
Message-ID:
On 02/19/2017 07:20 PM, John Allen wrote:
> Any suggestions as to how to get the output into my DNS (Bind9)
> preferably without using nsupdate.
For what it's worth, my method to insert TLSA records into my zone files
is to use some M4 macros.
The idea is to "fetch" the digests from the zone file when signing it,
instead of "pushing" the digests to the zone file when renewing the
certificates.
So, my zone file contains something like that:
---8<---
m4_define(SPKI_DGST,
`m4_esyscmd(openssl x509 -in $1 -pubkey -noout | \
openssl rsa -pubin -outform DER | \
openssl dgst -sha256 -binary | \
openssl enc -base64)')
_443._tcp.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/web/cert)
_25._tcp.mail.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/mail/cert)
--->8---
(Actually the macro definition is in a separate file which is included
in the zone file. But you get the idea.)
The file is then processed by `m4 -P` and the resulting zone file is
signed by dnssec-signzone.
(The manual for GNU M4 contains a warning that M4 can be "fairly
addictive" and that its users tend to use it everywhere; I'm afraid
that's true.)
Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
From ietf-dane at dukhovni.org Sun Feb 19 20:23:52 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 19 Feb 2017 14:23:52 -0500
Subject: Letsencrypt & TLSA - automation
In-Reply-To:
References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
Message-ID:
> On Feb 19, 2017, at 2:02 PM, Damien Goutte-Gattat wrote:
>
> ---8<---
> m4_define(SPKI_DGST,
> `m4_esyscmd(openssl x509 -in $1 -pubkey -noout | \
> openssl rsa -pubin -outform DER | \
> openssl dgst -sha256 -binary | \
> openssl enc -base64)')
>
> _443._tcp.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/web/cert)
> _25._tcp.mail.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/mail/cert)
> --->8---
Are you sure that base64 works in this context??? The presentation
format for TLSA records is hex encoded. I use:
hexdump -ve '/1 "%02X"'
where you're using "openssl enc -base64"
> (The manual for GNU M4 contains a warning that M4 can be "fairly addictive" and that its users tend to use it everywhere; I'm afraid that's true.)
Long ago I too was an m4 addict, but then I kicked the habit... :-)
That said, this implementation looks sensible.
--
Viktor.
From dgouttegattat at incenp.org Sun Feb 19 21:17:14 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sun, 19 Feb 2017 21:17:14 +0100
Subject: Letsencrypt & TLSA - automation
In-Reply-To:
References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
Message-ID: <26808e3e-9e2d-8518-6844-96d89bdcc728@incenp.org>
On 02/19/2017 08:23 PM, Viktor Dukhovni wrote:
> Are you sure that base64 works in this context??? The presentation
> format for TLSA records is hex encoded.
Oups. I re-wrote the macro in my message from memory instead of pasting
it from my actual script, and of course I messed up.
(Coincidentally, I spent the last few hours writing an introduction to
HTTP Public-Key Pinning, which does use base64 encoding.)
My real macro is:
m4_define(SPKI_DGST,
`m4_esyscmd(openssl x509 -in $1 -pubkey -noout | \
openssl rsa -pubin -outform DER | \
openssl dgst -sha256 | cut -d" " -f2)')
Sorry about that,
Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
From dane at lists.grepular.com Mon Feb 20 08:25:05 2017
From: dane at lists.grepular.com (Mike Cardwell)
Date: Mon, 20 Feb 2017 07:25:05 +0000
Subject: Letsencrypt & TLSA - automation
In-Reply-To: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
Message-ID: <20170220072505.GA31299@snake.grepular.com>
How do you intend to deal with the DNS caching issues? I.e, that you
need to renew the SSL cert and then publish it in the DNS for at least
one TTL before actually putting the cert in to production.
Mike
* on the Sun, Feb 19, 2017 at 01:20:52PM -0500, John Allen wrote:
> Attached is a bash script that I am developing to automate the generation of
> TLSA records from Letsencrypt certificates.
>
> the script is called from the certbot renew hook, it can also be run stand
> alone - Certbot_TLSAgen path-to-certificate "space separated list of domains
> included in cert"
>
> It seems to work, but would some kind sole take a look and where I have or
> are about to screw up.
>
>
> Any suggestions as to how to get the output into my DNS (Bind9) preferably
> without using nsupdate. I am not keen on nsupdate as it makes a mess of the
> zone files, which I use as documentation for my DNS.
>
>
> Has anybody heard of a electronic "one time pad" system.
--
Mike Cardwell https://www.grepular.com
OpenPGP Key DF70 D8E5 FBD6 8519 9257 C44C 0DA6 8B1E 1801 A332
XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 598 bytes
Desc: Digital signature
URL:
From john at klam.ca Mon Feb 20 11:49:11 2017
From: john at klam.ca (John Allen)
Date: Mon, 20 Feb 2017 05:49:11 -0500
Subject: Letsencrypt & TLSA - automation
In-Reply-To: <20170220072505.GA31299@snake.grepular.com>
References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
<20170220072505.GA31299@snake.grepular.com>
Message-ID: <41af87f9-88b6-df95-e267-e8d0bc22048d@klam.ca>
I am not sure, I have used INCLUDE statements in my zone files in the
past. But some people don't like them.
My thinking is that immediately after a cert update I would include two
files current and current -1 (probably using symlinks), after the TTL
period has past/expired I would remove current -1. Removing it might
mean that I update its symlink to point to an "empty" file. not literal
empty but only contains a comment(s)??
Another way, one that to me this feels extremely clumsy and as a result
I am not too keen on. Might be to have two copies of the zone file, a
working zone file and an operation zone file. The operational zone is
created by concatenation of the working file + the current TLSA file +
the expiring TLSA file during the TTL period.
Still have not worked out how to update the SOA sequence number, bearing
in mind that the the Bind zone file is somewhat free form.
JohnA
From john at klam.ca Mon Feb 20 11:55:58 2017
From: john at klam.ca (John Allen)
Date: Mon, 20 Feb 2017 05:55:58 -0500
Subject: Letsencrypt & TLSA - automation
In-Reply-To:
References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
Message-ID: <247933b9-8c6f-ef72-776a-dd8e877c87da@klam.ca>
Is the process to update the serial number automatic? If so care to share.
On 2017-02-20 4:04 AM, Casper Gielen wrote:
> Op 19-02-17 om 19:20 schreef John Allen:
>> Attached is a bash script that I am developing to automate the
>> generation of TLSA records from Letsencrypt certificates.
>>
>> the script is called from the certbot renew hook, it can also be run
>> stand alone - Certbot_TLSAgen path-to-certificate "space separated list
>> of domains included in cert"
>>
>> It seems to work, but would some kind sole take a look and where I have
>> or are about to screw up.
>>
>>
>> Any suggestions as to how to get the output into my DNS (Bind9)
>> preferably without using nsupdate. I am not keen on nsupdate as it makes
>> a mess of the zone files, which I use as documentation for my DNS.
> It may not be the cleanest method, but I use the INCLUDE statement in my
> zones to include snippets of externally maintained information.
>
> The script I use outputs the required records and I just put it in the
> right file and trigger a procedure to update the serial number and
> reload Bind.
>
From cgielen+dane-sys4 at uvt.nl Mon Feb 20 12:50:10 2017
From: cgielen+dane-sys4 at uvt.nl (Casper Gielen)
Date: Mon, 20 Feb 2017 12:50:10 +0100
Subject: Letsencrypt & TLSA - automation
In-Reply-To: <247933b9-8c6f-ef72-776a-dd8e877c87da@klam.ca>
References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
<247933b9-8c6f-ef72-776a-dd8e877c87da@klam.ca>
Message-ID: <20936d0d-0e13-4ff6-8fd5-4c58e891d599@uvt.nl>
Op 20-02-17 om 11:55 schreef John Allen:
> Is the process to update the serial number automatic? If so care to share.
Just a tiny and unreliable script that works in my controlled
environment where zonefiles use a serial based on the date. I wouldn't
recommend using it as is, but I've attached it for inspiration.
--
Casper Gielen | LIS UNIX
PGP fingerprint = 16BD 2C9F 8156 C242 F981 63B8 2214 083C F80E 4AF7
Universiteit van Tilburg | Postbus 90153, 5000 LE
Warandelaan 2 | Telefoon 013 466 4100 | G 236 | http://www.uvt.nl
-------------- next part --------------
#!/usr/bin/env bash
#
# Update serial in a zone file
# Casper Gielen, 2016
usage() {
echo "usage: update-serial "
echo "Updates the serial of a zonefile to the current date + a counter"
exit 1
}
zonefile="$1"
[ -z "$zonefile" ] && usage
# FIXME: improve the way we find the serial
old=$(awk '/;serial/{print $1}' $zonefile)
old_date=${old:0:8}
old_count=${old:(-2)}
new_date=$(date +%Y%m%d)
new_count="00"
if [ "$new_date" == "$old_date" ]; then
new_count=$(printf "%02d" "$[ 10#$old_count + 1 ]")
fi
new="${new_date}${new_count}"
# FIXME: make sure we change the right line
sed -i "s/$old/$new/" $zonefile
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL:
From ietf-dane at dukhovni.org Tue Feb 21 04:38:13 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 20 Feb 2017 22:38:13 -0500
Subject: Letsencrypt & TLSA - automation
In-Reply-To: <20170220072505.GA31299@snake.grepular.com>
References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
<20170220072505.GA31299@snake.grepular.com>
Message-ID:
> On Feb 20, 2017, at 2:25 AM, Mike Cardwell wrote:
>
> How do you intend to deal with the DNS caching issues? I.e, that you
> need to renew the SSL cert and then publish it in the DNS for at least
> one TTL before actually putting the cert in to production.
Indeed this is the key issue. The certificate provided by Let's Encrypt
should not be deployed as the live certificate used by the MTA until the
DNS TLSA records have been in place for at least a couple of TTLs.
Keep in that "TTL" here means not just the TTL for the RRset, but also
the refresh time of the zone by any slave servers, since until they obtain
fresh data they may be serving stale records with the full data TTL.
The simplest approach is to not point your MTA directly at the LE certs,
but instead to update the copy used by the MTA once the LE cert and its
TLSA digest have been in place sufficiently long...
This is complicated, which is why I recommend the "3 1 1" + "2 1 1"
approach with a stable public key described in:
http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444
and also in:
https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/
--
Viktor.
From dane-users-phil at spodhuis.org Tue Feb 21 05:38:09 2017
From: dane-users-phil at spodhuis.org (Phil Pennock)
Date: Tue, 21 Feb 2017 04:38:09 +0000
Subject: Letsencrypt & TLSA - automation
In-Reply-To:
References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
<20170220072505.GA31299@snake.grepular.com>
Message-ID: <20170221043808.GA48769@tower.spodhuis.org>
On 2017-02-20 at 22:38 -0500, Viktor Dukhovni wrote:
> Indeed this is the key issue. The certificate provided by Let's Encrypt
> should not be deployed as the live certificate used by the MTA until the
> DNS TLSA records have been in place for at least a couple of TTLs.
This is why I just use DANE on the CA certs, with a spare CA entry, so
that I don't need to coordinate grace periods around updating DNS on
each renewal.
For exim.org, it's just LE. I ended up dropping down to just X3 and X4.
For my own domains, it's LE and my private CAs.
For HPKP where there is a little more room inside the TCP stream and I
set longer TTLs, I include a commercial CA too; if everything goes to
hell and I end up paying for some certs for a year, I at least have an
exit plan. I can add to DNS as-and-when needed.
-Phil
From ietf-dane at dukhovni.org Tue Feb 21 05:47:28 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 20 Feb 2017 23:47:28 -0500
Subject: Letsencrypt & TLSA - automation
In-Reply-To: <20170221043808.GA48769@tower.spodhuis.org>
References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca>
<20170220072505.GA31299@snake.grepular.com>
<20170221043808.GA48769@tower.spodhuis.org>
Message-ID: <9ACA21DA-EA3F-4F5A-B92C-D27534654ED6@dukhovni.org>
> On Feb 20, 2017, at 11:38 PM, Phil Pennock wrote:
>
> This is why I just use DANE on the CA certs, with a spare CA entry, so
> that I don't need to coordinate grace periods around updating DNS on
> each renewal.
>
> For exim.org, it's just LE. I ended up dropping down to just X3 and X4.
>
> For my own domains, it's LE and my private CAs.
Thanks for that note.
If one is willing to issue leaf certs from a private CA, that's by far
the most robust option for port 25, where having a public trusted CA
in the chain is not particularly useful.
By all means, use LE on ports 587/465 for submission from mass-market
MUAs, but MTAs will either be opportunistic unauthenticated, or verify
private EE/private TA certs.
I'll probably add some code to Postfix 3.3 to make it easy to create
a TA key/cert + EE key/cert issued by said TA. And code to roll these
as described in the various messages I keep posting links to.
Updating the DNS will require a user-provided hook.
--
Viktor.
From john at klam.ca Wed Feb 22 23:17:46 2017
From: john at klam.ca (John Allen)
Date: Wed, 22 Feb 2017 17:17:46 -0500
Subject: TLSA record TTL values
Message-ID:
Is the any recommendation as to the TTL for TLSA records?
I would imagine fairly short as if the is a problem you want the old
ones gone ASAP!
John A
From ietf-dane at dukhovni.org Wed Feb 22 23:50:03 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Wed, 22 Feb 2017 17:50:03 -0500
Subject: TLSA record TTL values
In-Reply-To:
References:
Message-ID:
> On Feb 22, 2017, at 5:17 PM, John Allen wrote:
>
> Is the any recommendation as to the TTL for TLSA records?
An hour or less. Depending on how time-sensitive your email is.
Keep in mind the refresh time of secondary servers, setting the
TTL much below that does not help much.
> I would imagine fairly short as if the is a problem you want the old ones gone ASAP!
Yes, that's the basic motivation to keep it reasonably short.
--
Viktor.
From dane-users-phil at spodhuis.org Sat Feb 25 06:05:15 2017
From: dane-users-phil at spodhuis.org (Phil Pennock)
Date: Sat, 25 Feb 2017 05:05:15 +0000
Subject: smtpdane testing tool (early alpha)
Message-ID: <20170225050514.GA52256@tower.spodhuis.org>
Folks,
If you have Golang 1.8 (or newer) installed, my "smtpdane" tool might be
of interest.
mkdir ~/go
go get go.pennock.tech/smtpdane
There's a README.md with invoking hints, etc. Current git hosting has
this visible at:
https://github.com/PennockTech/smtpdane
I'll repeat the warning at the top of the README.md:
} EARLY ALPHA SOFTWARE
}
} THIS HAS NOT YET BEEN TESTED TO CONFIRM IT FAILS WHEN IT SHOULD,
} AGAINST BAD CERTIFICATES OR DNS
So yes, I need to create a test suite still, instead of relying upon
ad-hoc testing against various servers. That said, while I wouldn't yet
rely upon the tool for monitoring or assurance, it's useful for taking a
look.
Also: Go 1.8 is a very recent release; please do check version.
This is not a frivolous requirement on my part: Go 1.8 introduced the
hooks into the TLS certificate verification logic which I need to splice
DANE logic in there. The code should "cleanly" fail to build with an
obvious error message if an older toolchain is used.
At present, smtpdane still relies upon a validating DNS resolver,
instead of validating DNSSEC itself. For use as a monitoring component,
I'd like to remove that dependency.
smtpdane -help
smtpdane -mx spodhuis.org
Every MX host, every IP, connected to in parallel and success reported.
Feedback welcome. There's a TODO of things I know still need to be
done.
Thanks,
-Phil
From ietf-dane at dukhovni.org Mon Feb 27 03:06:15 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 26 Feb 2017 21:06:15 -0500
Subject: Update on stats
Message-ID: <20170227020615.GD92063@yyrkoon.imrryr.org>
As of today I count 110505 domains with correct DANE TLSA records
for SMTP. As expected the bulk of the DANE domains are hosted the
handful of DNS/hosting providers who've enabled DANE support in
bulk for the domains they host. The top 10 MX host providers by
domain count are:
43813 domeneshop.no
35704 transip.nl
15495 udmedia.de
2022 bhosted.nl
1332 nederhost.net
896 ec-elements.com
409 core-networks.de
307 uvt.nl
282 bit.nl
275 omc-mail.com
The real numbers are surely larger, because I don't have access to
the full zone data for most ccTLDs, and in particular .de and .nl.
There are 2401 unique zones in which the underlying MX hosts are
found, this counts each of the above providers as just one zone,
so is a measure of the breadth of adoption in terms of servers
deployed. Alternatively, a similar number is seen in the count
(2522) of distinct MX host server certificates that support the
same ~110000 domains.
Of the ~110000 domains, 565 have "partial" TLSA records, that cover
only a subset of the MX hosts. While this protects traffic to some
of the MX hosts, such domains are still vulnerable to the usual
active attacks via the remaining MX hosts.
The number of domains with incorrect TLSA records or failure to
advertise STARTTLS (even though TLSA records are published) stands
today at 64 (~4 are recent additions that will likely be resolved
soon, the remaining ~60 are the for now stable population of broken
domains). This month I'm posting the top 50 entries, these are
domains that have been on that list for the longest time.
Hall of Shame:
castleturing.net goldenhairdafo.net dexalo.de
nonoserver.info inu.nl dexalo.eu
wm.net.nz dnsmadefree.com digitalwebpros.com
apachedemo.de z0z0.me jeremyness.com
oostergo.net pksvice.cz maximilian-greger.com
thothnet.org ttygap.net copi.org
wipedivision.cz bels.cz delphij.net
rajmax.si baobrien.org poderdoalimento.com.br
acsemb.org baobrien.guru rnrfunco.net
dhautefeuille.eu pieterpottie.com sgt.com
dinepont.fr sylvieandpieter.com rnrfunco.com
hlfh.space sylviesfollies.com puz.de
12xu.info flatcap.org zencrypt.de
warunek.net russon.org freeservices.net
giesen.me amadigi.ovh kuzenkov.net
kamikazekippetjes.nl duffau.net obninsk.biz
myzt.nl daallexx.eu
The number of domains with bad DNSSEC support is 434. The top 10
DNS providers (by broken domain count) are:
62 axc.nl - Slated to be resolved
37 infracom.nl - Slated to be resolved
18 loopia.se
18 active24.cz
16 domaincontrol.com - notified
14 jsr-it.nl
12 rdw.nl
12 cas-com.net
11 dootall.com - notified
10 ignum.com
Around 100 of the broken domains have at least one working nameserver,
and so are email-reachable, given enough retries.
The number of domains that at some point were listed in Gmail's
transparency report is 99 (this is my ad-hoc criterion for a domain
being a large-enough actively used email domain). Of these 44 are
in recent reports (February 2017):
Hall of Fame:
gmx.at mail.de asp4all.nl
nic.br posteo.de ouderportaal.nl
registro.br ruhr-uni-bochum.de overheid.nl
gmx.ch tum.de xs4all.nl
open.ch uni-erlangen.de domeneshop.no
gmx.com unitymedia.de webcruitermail.no
mail.com web.de debian.org
trashmail.com enron.email freebsd.org
xfinity.com octopuce.fr gentoo.org
bayern.de comcast.net ietf.org
bund.de dd24.net isc.org
fau.de gmx.net netbsd.org
gmx.de hr-manager.net samba.org
jpberlin.de t-2.net torproject.org
lrz.de xs4all.net
A recent addition that is not listed above is "exim.org". It seems
that "exim.org" mailing lists don't process enough email to land
on Google transparency reports. Similarly, "openssl.org" used to
be on this list, and still has working TLSA records, but it seems
no longer generates enough email traffic to be on Google's reports.
I don't have any way to measure how many domains enable DANE outbound
but aren't using DNSSEC for their own domain or are not publishing
TLSA records. It is easy to do, just fire up a local validating
resolver, adjust /etc/resolv.conf to list only 127.0.0.1 and/or
::1, and add a couple of lines to main.cf. So the stats I am
reporting reflects only DANE adoption for inbound email.
--
Viktor.