It is quite common that organizations use some kind of TLS decryption to have a look at the client traffic in order to protect against malware or evasion. (Some synonyms are SSL/TLS interception, decryption, visibility, man-in-the-middle, …) Next-generation firewalls as well as proxies implement such techniques, e.g., Palo Alto Networks or Blue Coat. To omit the certificate warnings by the clients, all spoofed certificates are signed by an internal root CA that is known to all internal clients. For example, the root CA is published via group policies to all end nodes.
But what happens if the DNS-based Authentication of Named Entities (DANE) is widely used within browsers? From the CA perspective, the spoofed certificates are valid, but not from the DANE perspective. To my mind we need something like an on-the-fly TLSA record spoofing technique that works in conjunction with TLS decryption.
Continue reading Idea: On-the-Fly TLSA Record Spoofing
After the implementation of DNS and DNSSEC (see the last posts) it is good to do some reconnaissance attacks against the own DNS servers. Especially to see the NSEC or NSEC3 differences, i.e., whether zone walking (enumeration) is feasible or not.
For many different kinds of DNS reconnaissance the tool dnsrecon can be used. In this post I will focus on the
-z option which is used for DNSSEC zone walking, i.e., walk leaf by leaf of the whole DNS zone.
Continue reading How to walk DNSSEC Zones: dnsrecon
By default DNSSEC uses the next secure (NSEC) resource record “to provide authenticated denial of existence for DNS data”, RFC 4034. This feature creates a complete chain of all resource records of a complete zone. While it has its usage to prove that no entry exists between two other entries, it can be used to “walk” through a complete zone, known as zone enumeration. That is: an attacker can easily gather all information about a complete zone by just using the designed features of DNSSEC.
For this reason NSEC3 was introduced: It constructs a chain of hashed and not of plain text resource records (RFC 5155). With NSEC3 enabled it is not feasible anymore to enumerate the zone. The standard uses a hash function and adds the NSEC3PARAM resource record to the zone which provides some details such as the salt.
Continue reading DNSSEC with NSEC3
One important maintenance requirement for DNSSEC is the key rollover of the zone signing key (ZSK). With this procedure a new public/private key pair is used for signing the resource records, of course without any problems for the end user, i.e., no falsified signatures, etc.
In fact it is really simply to rollover the ZSK with BIND. It is almost one single CLI command to generate a new key with certain time ranges. BIND will use the correct keys at the appropriate time automatically. Here we go:
Continue reading DNSSEC ZSK Key Rollover
This is really cool. After DNSSEC is used to sign a complete zone, SSH connections can be authenticated via checking the SSH fingerprint against the SSHFP resource record on the DNS server. With this way, administrators will never get the well-known “The authenticity of host ‘xyz’ can’t be established.” message again. Here we go:
Continue reading SSHFP: Authenticate SSH Fingerprints via DNSSEC
DNS-based Authentication of Named Entities (DANE) is a great feature that uses the advantages of a DNSSEC signed zone in order to tell the client which TLS certificate he has to expect when connecting to a secure destination over HTTPS or SMTPS. Via a secure channel (DNSSEC) the client can request the public key of the server. This means, that a Man-in-the-Middle attack (MITM) with a spoofed certificate would be exposed directly, i.e., is not possible anymore. Furthermore, the trust to certificate authorities (CAs) is not needed anymore.
In this blog post I will show how to use DANE and its DNS records within an authoritative DNS server to provide enhanced security features for the public.
Continue reading How to use DANE/TLSA
To solve the chicken-or-egg problem for DNSSEC from the other side, let’s use an authoritative DNS server (BIND) for signing DNS zones. This tutorial describes how to generate the keys and configure the “Berkeley Internet Name Domain” (BIND) server in order to automatically sign zones. I am not explaining many details of DNSSEC at all, but only the configuration and verification steps for a concrete BIND server.
It is really easy to tell BIND to do the inline signing. With this option enabled, the admin can still configure the static database for his zone files without any relation to DNSSEC. Everything with signing and maintaining is fully done by BIND without any user interaction. Great.
Continue reading DNSSEC Signing w/ BIND
To overcome the chicken-or-egg problem for DNSSEC (“I don’t need a DNSSEC validating resolver if there are no signed zones”), let’s install the DNS server Unbound on a Raspberry Pi for home usage. Up then, domain names are DNSSEC validated. I am listing the commands to install Unbound on a Raspberry Pi as well as some further commands to test and troubleshoot it. Finally I am showing a few Wireshark screenshots from a sample iterative DNS capture. Here we go:
Continue reading DNSSEC Validation with Unbound on a Raspberry
If you are searching for a DNSSEC validating DNS server, you can use BIND to do that. In fact, with a current version of BIND, e.g. version 9.10, the dnssec-validation is enabled by default. If you are already using BIND as a recursive or forwarding/caching server, you’re almost done. If not, this is a very basic installation guide for BIND with DNSSEC validation enabled and some notes on how to test it.
Continue reading BIND DNSSEC Validation