Bind Certificates to Domain Names for Enhanced Security With DANE and DNSSEC – Security Intelligence

Phishing and malware delivered via email remain some of the greatest threats to organizations today. According to the “IBM X-Force Threat Intelligence Index 2019,” nearly one-third of all analyzed attacks involved compromises via phishing emails.
Although business operations are increasingly reliant on email, the core of the technology hasn’t changed much over the years, and many of the current server-based email security mechanisms are still vulnerable to attacks. What if we could protect our email communications in the same way we already protect our browsing activities via HTTPS?
From a simplified standpoint, we can state that HTTPS is HTTP with a TLS/SSL encryption layer on top. This encryption layer serves three main purposes: confidentiality, integrity and authentication. Simply put, it allows the user to have some confidence that the information being transmitted cannot be eavesdropped on and cannot be altered by malicious actors — and most importantly, that it is being sent to the intended entity. After all, you do not want to send personal or medical information to a website run by criminals.
With HTTPS, it is important to recognize that secure does not necessarily mean safe. A secure website can still cause harm to your computer. Ensuring that information is transmitted solely to the intended entity is typically done by the browser, which verifies the identity of the server to which it connects. This identity is provided as a property of the TLS certificate and describes which domain the certificate belongs to. The client verifies that it can trust the certificate or that it is verified and trusted by a certificate authority (CA) that is trusted by the client. CAs play a crucial role in the whole process and are the entities that issue digital certificates.
It goes without saying that a CA is not going to issue a TLS certificate randomly. The requester needs to prove ownership of their domain. This can be done via the Domain Name System (DNS), by receiving an email, or by putting a text file up on the website. Unfortunately, this validation process isn’t flawless.
Because verification relies on DNS, there’s much to gain for an attacker in modifying the DNS infrastructure, as Cisco Talos discovered amid the Sea Turtle and DNSpionage campaigns, and FireEye observed earlier this year. In response to these attacks, the U.S. Computer Emergency Readiness Team (CERT) issued an alert, AA19-024A, on a DNS infrastructure hijacking campaign.
A different way of tampering with the validation process is to conduct a local border gateway protocol (BGP) hijack close to the CA, which makes the CA believe the attackers are the owners of a targeted domain. These attacks can be prevented by a conscientious CA with different validation points scattered around the internet.
Once an attacker is able to obtain a certificate for a domain, they can start a man-in-the-middle (MitM) attack, allowing them to capture, for example, login credentials. For this type of attack to be successful, the attacker also needs to divert the victim’s traffic. In general, this can be done by poisoning the DNS cache, placing malware on the victim’s machine, setting up rogue access points or targeting the internet service provider (ISP) directly.
Another approach to obtaining certificates wrongfully is to target the CA directly. The most notorious case of this was the DigiNotar hack in 2011, when false certificates were created for hundreds of websites, including Google and Skype after a breach of the CA.
During incident response, it’s crucial to detect the intrusion as soon as possible. It’s reasonable to assume that most CAs enforce security best practices and have sufficient security controls in place.
However, given that there are flaws in the system, browsers have a fairly long CA certificate list included, and certificates are not linked to one CA, it’s not unlikely that your organization will have to face an incident that involves malicious TLS certificates in the future. Despite the fact that certificates can be easily revoked in case of an incident and you can monitor the certificate transparency feed, there still remains a window of opportunity for an attacker.
Similar to email, DNS has been around for a very long time. Unfortunately, when it was being designed security was not the top priority. When a computer makes a DNS request, it simply trusts that the information it receives is from a valid and legitimate source, and attackers can abuse this implicit trust to cause mayhem.
This problem can be solved by introducing an actual verified level of trust into DNS, which can be done through Domain Name System Security Extensions (DNSSEC). DNSSEC grants additional resource records, which exist next to the traditional DNS records. These extra records provide a digital signature of the DNS records, allowing a client to verify the source and legitimacy of an answer.
Despite its use of the word “security,” DNSSEC does not provide encryption of DNS; it merely signs responses so that forgeries are detectable.
DNS-based Authentication of Named Entities (DANE) goes one step further. DANE is a protocol that uses DNS for storing certificates and DNSSEC to verify the validity of the requests. In other words, instead of relying on an external party to issue certificates, you can now control this yourself by putting the certificates within DNS.
Should this then replace the CA system altogether to solve the problem of having too many CAs? There are arguments for and against DANE replacing the CA system. Transferring the control and responsibility to the DNS system’s owners — top-level domains (TLDs), etc. — might not always be desired, but it can empower organizations and DNS administrators. Nevertheless, DANE can co-exist next to the current CA system.
Because DANE relies on DNS, you definitely need DNSSEC for it to work. Without DNSSEC, it’s impossible to guarantee the required strong integrity protection of the resource record.
The core of DANE is within the resource record type called Transport Layer Security Authentication (TLSA). These records are used to specify the keys used by the servers within the same domain. An example of a TLSA record name is “_443._tcp.www.myorg.com.” This record name is composed of three values:
The record returned then consists of four elements:
Setting the certificate usage value to 3 enables you to provide your own certificates, including a self-signed certificate. This can allow you to greatly improve user experience by presenting a valid self-signed certificate. It is important to note that DANE works perfectly fine with existing certificates issued by CAs — as demonstrated, for example, via certificate usage 0 and 1. Because of the flexibility of the protocol, it is also possible to have different certificate usage modes within the same domain.
Encryption of email transport can already be done using STARTTLS. The sending server starts an unencrypted channel to the receiver requesting to switch to an encrypted channel. Unfortunately, with this opportunistic TLS the receiving server can still refuse encryption, and the servers then continue in plain text. This is great for MitM attacks but not so great for organizations.
End-to-end encryption to ensure message integrity and sender authentication can be achieved via Secure/Multipurpose Internet Mail Extensions (S/MIME) and Pretty Good Privacy (PGP). But neither of these are widespread, and both have drawbacks concerning scalability or lack of user-friendliness.
DANE can do little for end user authentication or digital signatures, but it does protect the email transport, from both an integrity and confidentiality point of view. Before transmitting emails, the sending server will look up the TLSA record for Simple Mail Transfer Protocol (SMTP) communication. If this exists, it will immediately start with an encrypted channel toward the receiving server. This limits the opportunities for an intermediate attacker to request a “downgrade” to an unencrypted communication channel.
However, DANE is merely one piece of the puzzle. If the last chain in the email routing is a mail transfer agent (MTA) or a client talking plain text, then you’re back to where you started.
By far the most important consideration with DANE is having a strong and well-protected DNS infrastructure. If you’re already at the point of supporting DNSSEC, you hopefully understand the need for strong security controls. Also critical to the success of DANE is a solid DNS provisioning system. Because certificates are now managed as DNS records, having some form of automation, monitoring and change management becomes much more important.
Setting up TLSA records is easy with the use of these toolkits:
Using the tlsa command to create a TLSA record is straightforward:
tlsa –usage 3 –selector 1 –mtype 1 –certificate /path/to/certificate.crt www.myorg.com.
Once the record is created, the next steps are adding this new DNS record to the zonefile, updating the revision number and publishing the zone. On the server side — for example for the mail server Postfix — enabling DANE is as simple as setting the TLS level to DANE and making sure there is support for DNSSEC:
smtp_dns_support_level=dnssec
smtp_host_lookup=dns
smtp_tls_security_level = dane
smtp_tls_loglevel=1
The biggest hurdle for implementing DANE lies with DNSSEC. Granted, setting up DNSSEC can be daunting, but the reward of a much higher level of DNS security can make it worth the effort.
After you implement DNSSEC and set up DANE, you can start monitoring your environment for malicious SSL certificates with Zeek. Zeek extracts certificate metadata from traffic flows and then matches these against an SSL blacklist, for example SSLBL. It can also verify the certificates against a list of fingerprints (JA3 and JA3S). This verification works by looking at the TLS Client Hello (or Server Hello) packet following the TCP 3-way handshake. This packet and the way it is generated is fairly unique for every client (or server), and it is sent before actual encryption takes place.
To detect connections with malicious servers, you need to track both the client and server messages. Why? Because servers respond to different clients differently, but they will always respond to the same client in the same way. This means that even if a bad certificate (or tooling) is moved to a different domain, you can still track it because the fingerprint remains the same.
7 min read – While the evolution of LLMs mark a new era of AI, we must be mindful that new technologies come with new risks. Explore one such risk called “audio-jacking.”
3 min read – As generative AI goes mainstream, it highlights the increasing demand for AI cybersecurity professionals like Maria Pospelova. Pospelova is currently a senior data scientist, and data science team lead at OpenText Cybersecurity. She also worked at Interest, an AI cybersecurity…
6 min read – As organizations begin planning their cybersecurity strategies for 2024, these expert insights provide guidance on facing the year to come.
4 min read – Cloud environments were frequent targets for cyber attackers in 2023. Eighty-two percent of breaches that involved data stored in the cloud were in public, private or multi-cloud environments. Attackers gained the most access to multi-cloud environments, with 39% of breaches spanning multi-cloud environments because of the more complicated security issues. The cost of these cloud breaches totaled $4.75 million, higher than the average cost of $4.45 million for all data breaches.The reason for this high cost is not only the…
3 min read – Data residency is a hot topic, especially for cloud data. The reason is multi-faceted, but the focus has been driven by the General Data Protection Regulation (GDPR), which governs information privacy in the European Union and the European Economic Area.The GDPR defines the requirement that users’ personal data and privacy be adequately protected by organizations that gather, process and store that data. After the GDPR rolled out, other countries such as Australia, Brazil, Canada, Japan, South Africa and the UAE…
3 min read – A new report from SecurityScorecard reveals a startling trend among the world’s top energy companies, with 90% suffering from data breaches through third parties over the last year. This statistic is particularly concerning given the crucial function these companies serve in everyday life.Their increased dependence on digital systems facilitates the increase in attacks on infrastructure networks. This sheds light on the need for these energy companies to adopt a proactive approach to securing their networks and customer information.2023 industry recap:…
Analysis and insights from hundreds of the brightest minds in the cybersecurity industry to help you prove compliance, grow business and stop threats.

source

About The Author

admin

See author's posts