Analyzing DANE's Response to Known DNSsec Vulnerabilities

Analyzing DANE's Response to Known DNSsec Vulnerabilities Matthew Henry Joseph Kirik Emily Scheerer UMBC UMBC UMBC henmatt1@umbc.edu joskir1@umbc.edu semily1@umbc.edu May 9, 2014 Abstract: SSL/TLS is currently the most popular solution for secure communication between clients and servers. Although there are weaknesses in the current system, Certificate Authorities remain a critical security service in a network, able to verify the identity of an entity, issue digital certificates, and maintain a certificate revocation list. In an ideal world, DANE (DNS-based Authentication of Named Entities) would support a certificate authority, preventing man in the middle attacks by giving the certificate record based on the previously made DNSsec (The Domain Name System Security Extension) request through a TLSA record. However, our research discovered that with a self-signed certificate, instead of supporting a certificate authority, DANE makes it easier for the attacker by only requiring them to forge the DNS server and claiming a selfsigned certificate, instead of needing to compromise both the certificate authority and the DNS server. Keywords: SSL, TLS, DANE, DNSsec, Certificate Authorities Section 1: Motivation 1.1 Introduction Our group analyzed the security concepts instituted as part of the DANE protocol to authenticate DNS and browser requests. Until now, authentication of domain names have been done by third party Certificate Authorities, in order to make sure the entity on the far end of a secure connection actually represents the users intended domain. 1 Currently SSL/TLS-based applications maintain a list of over 200 Certificate Authorities whose certificates they will accept, creating many points of vulnerability. A compromise at any point would allow the attacker to issue certificates for any domain. As a result, DNSsec was developed to distribute secure information about domain names through the DNS system itself. Each domain holder can act as an authority for subordinate domains. The DANE working group within the Internet Engineering Task Force (IETF) created a new type of DNS record format for certificate associations, known as TLSA, which allows a domain to sign statements about which entities are authorized to represent it. Initially we believed that DANE was a reasonably thought-out method to securely determine exactly which SSL/TLS certificate a browser should use to connect to the site. DANE as advertised was also being considered to be used in securing email and voice communications/multimedia sessions over IP protocol networks (VoIP). According to our analysis, DANE associations can be used either as a check on the current model (i.e. limit which Certification Authorities may vouch for a 1 Barnes, Richard L. Domain Name Authentication with DNSSEC and DANE-The Internet Protocol Journal, Volume 15, No. 1. Cisco, n.d. Web. 04 May 2014. http://www.cisco.com/web/about/ac123/ac147/archiv ed_issues/ipj_15-1/151_dane.html 1

domain) or as an alternative trust path (i.e. root trust in a DNSsec authority instead of a Certification Authority), but it still does not overcome the inherent vulnerabilities in DNSsec. In other words, the transition and security problems that face DANE arise because DANE is the first real application of DNSsec that is expected to be widely deployed. In order to comprehensively understand DANE, we must first address its foundation, namely SSL/TLS and DNSsec. The following sections attempt to give an adequate representation of both, ending with a detailed discussion of the new DANE protocol. 1.2 Secure Sockets Layer/Transport Layer Security (SSL/TLS) HTTPS is identical to HTTP syntactically but adds an additional layer of security known as SSL (Secure Sockets Layer) or a newer implementation known as TLS (Transport Layer Security). These security protocols rely on the notion of a certificate to verify the identity of both the server and to establish the encrypted communication channel between the web browser and the web server. Current TLS-based applications rely on PKIX for authentication of domain names. PKIX is based on a very general digital certificate system called X.509, and as a result, it has no inherent binding to the DNS. Unlike the DNS, which has a single global root, there is no single authority under which all PKIX certificates can be verified. Relying parties can either trust every authority that has a signed certificate for an entity it wants to authenticate or they will not be able to validate the identities of some entities. To establish an HTTPS session there is a series of communications that take place between the browser and the server. First, the browser requests an HTTPS session with the servers and provides a list of cryptographic hash functions and ciphers. Then the server selects strongest hash function and ciphers its supports, informs browser and send back its certificate. The certificate will contain the server s public encryption key. After this, the browser verifies the authenticity of the certificate and encrypts a random number using the server s public key. Finally, using the random number, the browser and server generate shared secret keys that are used to encrypt and authenticate all subsequent messages. In addition to providing a server s public key, certificates provide a means of verifying the identity of websites. Each of the web servers communicating with the browsers may be run by a different administrative authority. Therefore certificates are used to provide a means of verifying the identity of websites to the browsers. Certificates are digitally signed using the private key of a trusted third party, known as a Certificate Authority. In order to get a certificate, a web site owner submits a certificate signing request to the authority alongside a fee. If the identity of the requestor and ownership of the domain name for the website is verified, the authority signs and issues the certificate. Overall, the goal of the Certificate Authority verification is initially to verify the authenticity of the binding between a certificate and a domain name. Secondly, it allows a Certificate Authority organization to vouch for the trustworthiness of the entity that is managing the domain name in question. When a user navigates to a website that attempts to establish an HTTPS session but in return is provided a revoked or expired certificate, the web browser should display an error message. This certificate verification model has been in use by the HTTPS protocol for since the mid- 90 s but recently it has been compromised. In many situations, adversaries were able to defeat this model by attacking one of the Certificate Authorities that the victim web site was not actually using. Several recent attacks have taken advantage of this fact by targeting smaller Certification Authorities as a way to obtain 2

certificates for major domains (i.e. an attack through DigiNotar on Google). 2 It is possible for attackers to initiate a man-in-the-middle attack to intercept encrypted traffic by providing forged or expired certificates. 1.3Domain Name System Security Extension (DNSsec) In November 1993, the earliest organized work on DNSsec within the Internet Engineering Task Force began as an open design team meeting run by members of the DNS working group. 3 It was not until 2004 that the IETF began writing down the specific set of threats against which DNSsec is designed to protect. In response to increasingly complicated attacks on Certificate Authorities over the past two decades, DNSsec was developed as a way to alleviate the risk from compromising parties. Any HTTPS session that uses a domain name opposed to a hard coded IP address begins with a DNS lookup. DNSsec is a set of security extensions to the DNS protocol, which digitally signs all DNS replies using public-key cryptography, making it difficult to spoof a DNS reply. When a user issues a DNS request, the request packet indicates that DNSsec is supported and if the queried supporter also supports DNSsec, a resource-record signature (RRSIG) is returned alongside any resolved queries as well as DNSKEY record containing the authoritative name server s public key. The RRSIG contains a digital signature of the returned records (hash of the returned records encrypted with the authoritative name server s 2 Barnes, Richard L. Domain Name Authentication with DNSSEC and DANE-The Internet Protocol Journal, Volume 15, No. 1. Cisco, n.d. Web. 04 May 2014. http://www.cisco.com/web/about/ac123/ac147/archiv ed_issues/ipj_15-1/151_dane.html 3 "RFC 3833 - Threat Analysis of the Domain Name System (DNS)." Internet Engineering Task Force, n.d. Web. 04 May 2014. <http://tools.ietf.org/html/rfc3833>. private key). The user can verify the returned records by decrypting the digital signature using the name server s public key. In order to be useful as a given relying party to authenticate someone, a certification path has to end in a trust anchor, that is, an authority that the relying party trusts to make assertions. In the DNSsec context, relying parties can in principle have only one trust anchor, namely the DNS root. 4 In order to establish trust in the name server s public key, DNSsec employs a chain of trust to the root name server. 1.4 DNSsec-based Authentication of Named Entities (DANE) The goal of DANE is to address some of the vulnerabilities of the current PKIX system by allowing DNSsec to allow domains to publish information secured with DNSsec that can add additional security to PKIX certificates used for TLS. DANE explicitly staples a domain name to a certificate. Previously relaying parties could not determine which Certificate Authority a web site obtained their certificate from. DANE relies on DNSsec to cryptographically secure the transaction between the relaying party and the zone owner; therefore the zone owner can also use DNS to convey details about the web server s certificate. DNSsec uses a resource record, whereas DANE specific a new type called the TLSA (TLS associations) record containing a hashed fingerprint of the certificate that the relaying parties should see when they contact the server. More specifically the TLSA has three basic fields: usage (which type of statement the record is making), selector/matching (how a TLS certificate chain should be matched against the 4 Barnes, Richard L. Domain Name Authentication with DNSSEC and DANE-The Internet Protocol Journal, Volume 15, No. 1. Cisco, n.d. Web. 04 May 2014. http://www.cisco.com/web/about/ac123/ac147/archiv ed_issues/ipj_15-1/151_dane.htm 3

record), and certificate for association (the actual data against which the TLS certificate chain should be matched). These records are stored under the target domain with a prefix that indicates the transport and port number for the TLS server. The DANE protocol limits the scope of the existing trust anchors while simultaneously providing the client with a new trust anchor. In other words, the client only accepts a specific certificate issued under a specific Certificate Authority and the client should use a domain-provided trust anchor to validate certificates for that domain. Section 2: Previous Work In a SANS Institute report, Holly McKinley depicts how SSL/TLS works in its current implementation, provides a chronological history of development and also an analysis of the security the protocol supports. 5 Although it mentions several of the vulnerabilities in the SSL/TLS protocol, it did not propose or evaluate any potential solutions. Several similar articles discussing SSL/TLS were referenced as a template for evaluations in our analysis. Researchers have also analyzed DANE s implementation. One paper in particular referenced in our analysis was Eric Osterweil, Danny McPherson and Lixia Zhang s Verisign technical report 6. The group addresses the implementation that the operational community has long used as attack surfaces or 5 McKinley, Holly Lynne. SSL and TLS: a Beginner s Guide. SANS Institute, 2003. https://www.sans.org/reading- room/whitepapers/protocols/ssl-tls-beginners-guide- 1029 6 Osterweil, Eric, Danny McPherson, and Lixia Zhang. "A Quantitative Comparison Between X.509 CA Verification and DANE Via Attack Surface Analysis." Verisign Labs, 2012. http://techreports.verisignlabs.com/docs/tr- 1120004.pdf. general notions of system vulnerabilities. Their results show that if web sites implemented DNSsec excluding DANE, they would reduce their attack surface by as much as two orders of magnitude. By implementing DANE in full using DNSsec as a verification substrate, it would reduce their attack surface by three orders of magnitude. The report also provides an extensive detailed description of TLSA, a new type of DNS resource record specified by DANE, which contains a hashed fingerprint of the certificate that the relying party (RP) should expect to see when they contact the web server. This resource is useful for our overall analysis of the new security mechanisms offered in the DANE protocol. However, this report was not analyzing attack vectors, as ours has done. Instead, it assumed the ideal DANE setup. In an IETF Journal report, Richard Barnes explains the DANE protocol and how it attempts to solve some of the issues with TLS 7. He details the underpinnings of the DANE protocol and presents some of the new security challenges this protocol will create for users and client-side developers. This paper describes the current TLS client authentication, which uses asymmetric cryptology to protect communications. The current implementation is vulnerable to the BEAST attack, and the article discussed, DANE s vulnerability to it. This paper served as an example for our lab research, although we attempted a similar analysis with other known attacks, specifically spoofing and sniffing. Finally, in the process of conducting our group s analysis, we used several documents created by the actual DANE developers. Specifically, V. Dukhovni s memo in 2013 detailing how to implement DANE and the different aspects of publishing DANE TLSA 7 Barnes, Richard L. DANE: Taking TLS Authentication to the Next Level Using DNSSec. IETF Journal, October 2011. 4

records. 8 This document reports what server operators need to consider, how the clients authenticate the server s certificate chain, how DANE leverages the DNSsec infrastructure, and finally how TLSA records are validated. This document helped us to implement DANE, but was not instructive in detailing its vulnerabilities. Section 3: Methods 3.1 Lab Setup To test DANE s response to known vulnerabilities, we created a lab environment to run attacks. Our lab consisted of two apache webservers with self-signed certificates, one Nginx server with a self-signed certificate, a raspberry pi running Bind acting as our DNS server, and a machine running attack scripts. Our main attack consisted of an attacker on the network listening and responding to DNS requests and responding with a spoofed response. We experimented with this attack on multiple different security surfaces to determine the attack vectors. 3.2 Adversarial Model There are three main types of adversaries to be considered. A simple script kiddie attack was the focus of our investigation. Two additional types of adversaries exist, although these are not covered in our lab. These include a more intelligent hacker running a botnet or more sophisticated nation-state interested in cyber exploitation. Both adversaries could accomplish attacks at a higher level, like a DNS DDoS attack. However, we have limited our considerations to a simple attacker. 8 Dukhovni, V. DANE TLSA implementation and operational guidance May 2013, DANE Draft http://tools.ietf.org/html/draft-dukhovni-dane-ops-00 Our experiment assumes an adversary with some minimal knowledge of DNSsec sniffing and spoofing. This can be a simple script kiddie attack, our hypothetical adversary. Considering the attack is from a script kiddie implies we are assuming a computationally bounded adversary. In other words, they are running on a single server with a self-signed SSL certificate and that they have limited running time and processing power to accomplish their attacks. This prevents our hypothetical adversary from forging a TLSA record. We assumed our script kiddie adversary has the ability to access open source tools, like Kali Linux or OpenSSL. Our hypothetical attacker has a very low and limited budget and unable to purchase their own legitimate SSL certificate. In our scenario, the goal of the adversary is simply to attack the network s security to see if it can be defeated and the transferred secrets can be discovered. A script kiddie motivation is mostly to prove that they can do something, not because there is something to steal. Other attackers could have other motivations. For example, a hacker running a botnet often wants to increase their computational power, and therefore they turn other computers into zombie machines. Nationstates are attacking for espionage purposes, to obtain documents and plans that would otherwise be kept secret. SSL/TLS and DNSsec are used to protect all kinds of data transfers, financial, classified or otherwise, so securing those communications is significantly important. 3.3 Scenario 1: Traditional DNS In this setup, there is no protection against a DNS spoofer attack, the attacker only must answer faster than the legitimate DNS server to succeed, which is easily done while on the same network. If an HTTPS session assumes the Certificate Authority was not 5

compromised there will be a raised error message saying that the given SSL certificate does not match the URL. If the requested URL is of a subdomain (i.e. docs.google) it is possible to forge a CNAME record for the domain and alias the requested URL to a slightly misspelled URL which has a legitimate Certificate Authority approved certificate for the misspelled domain (i.e. docs.gooogle.com, notice the third o ). This would bypass the warning message saying the certificate is invalid. 3.4 Scenario 2: DNSsec In this scenario, the success of the attack depends on whether or not the client refuses Traditional DNS responses when asking for a DNSsec query. If the client accepts, the attacker could use the above attack and mark DNSsec not supported in the response. If the client only accepted DNSsec responses, then the attacker would have to forge a signature for the given forged record (which is computationally difficult). If the attacker were to try to perpetrate a subdomain attack it would have to forge a signature for the given CNAME record and a second A record. 3.5 Scenario 3: DANE Similar to the DNSsec scenario, if the client accepts traditional DNS responses, then all DANE s protections can be bypassed. If it does not, the attacker would have to include a TLSA record for the SSL certificate of their malicious site. This can be easier for the attacker because the DANE protocol allows for self-signed certificates which would eliminate the need for taking over a Certificate Authority or forging a Certificate Authority s signature. Again, the attack would need to forge the DNSsec trust chain signature. DANE would trade one single point of failure (CA s) for another (the DNSsec trust chain). A remedy to the situation would be to not allow self-signed certificates, however this decision would not be without its obvious tradeoffs. Section 4: Results Although DNSsec has always meant that DNS operators would have more security functions, DANE deployment will give them an explicit effect on application security, acting as arbiters of who can authenticate under a given name in TLS. Nonetheless, we found that DANE is still vulnerable to a DNSsec spoofing attack. DANE binds an SSL certificate to an IP address in addition to the URL binding that DNSsec does. DNS operators will play an analogous role to the one Certification Authorities play today a compromise in a DNS operator will allow an attacker to masquerade as a victim domain. However, if the DNSsec response cannot be trusted, the DANE response also cannot be trusted. Essentially, DANE trades one attack vector for another. As an adversary, instead of having to compromise the Certificate Authority and the DNS server to attack DANE, s/he would only need to take over the DNS Server because the DANE protocol allows self-signed SSL certificates (similar to the certificates we used in our lab). Additionally, DANE does not have a way to validate selfsigned certificates, so attacking the DNS server is sufficient with a self-signed certificate. Section 6: Discussion During this research project, a new vulnerability in OpenSSL was discovered. DANE currently works with OpenSSL. As a result, DANE is still vulnerable to the Heartbleed vulnerability. However, DANE also works with TLSLite, which is not vulnerable to the Heartbleed bug. DANE is designed to bind the appropriate certificate to an IP address, adding security and simplicity by ensuring certificates used are in the correct country and 6

location for the IP address being used. Heartbleed is not something that attacks DANE, it attacks OpenSSL and if DANE is on top of OpenSSL it doesn t fix holes in OpenSSL. This will be true for any future vulnerabilities discovered in SSL. However, it is important to consider the scope of DANE when drawing our results and conclusions. The DANE Digest is careful to clarify what is and is not relevant when testing DANE. Initially, our project description intended to evaluate DANE, compared to a number of other solutions. Our goal was to provide an explicit evaluation of several proposed solutions, critically reviewing them based on a standard metric. We had planned for our metric to be based on vulnerabilities, specifically focusing on usability, especially regarding understandability and ease of access. Our goal was to force security analysts and creators of web service security solutions to consider how effective their work was regarding the end user. We believed that this would ultimately create a more secure internet because the end user would know why they should care about security. However, we realized that evaluating DANE from a usability perspective and from a vulnerability perspective would be too large a scope for a one semester project, and decided to focus on the vulnerability analysis. A usability study is a different scope of research, focused on human response over technical details or errors. If we were to continue this project in the future, we would try to develop a user installation guide for DANE and a user survey to see how effective our installation guide is in encouraging system admins to install DANE. One of the main problems we discovered while analyzing DANE is the lack of information available about the system. DANE is still in an experimental stage, and for it to become truly popular and widely accepted, industry admins must understand how and why they should add DANE to their existing server side security. Section 7: Open Problems From the vulnerability analysis side, developing an exploit specifically for DANE would be a possible future problem. Our analysis tests DANE s ability to protect against known vulnerabilities in SSL and DNSsec. It does not analyze the TLSA certificates or the DANE implementation for new vulnerabilities. From the DANE developer forums, we know there are places in the existing DANE protocol that could be exploited, but developing the technical details of this attack would be another possible project. Throughout the duration of our analysis, we have been subscribed to the DANE IETF digest mailing list. As a subscriber, the list gave us a lot of insight on the future developments of DANE. Each of these insights has the potential to be a future project, either as an additional study or as a potential exploit. For example, DANE Digest Volume 37, Issue 2 noted that, The near-future course of the DANE project at NIST will now focus on SMTP uses, for both MUAs and MTAs...the issues with the HTTP use case are not protocol-specific and will crop up again with SMTP. Exploiting the HTTP use case would be one way to develop an attack against DANE. Finally, developing a client side attack against DANE would appear to be possible. DANE Digest Volume 36, Issue 30, notes that, the client still typically has no corresponding certificate in hand, and so, if the server does not provide a matching certificate in the TLS handshake, the client cannot "compare" the TLSA record with the server's chain. However, if the server's chain starts with a certificate signed with the trust anchor key in question (obtained from the TLSA record), the client can in principle verify the chain. This statement 7

would seem to point to the fact that DANE could be attacked by attaching a false trust anchor to the front of a certificate chain, and investigating this further would be worthwhile. Section 8: Conclusions DANE is meant to be an extension to SSL/TLS certificate authorities, not a replacement. Our experiment tested known DNSsec vulnerabilities against DANE s TLSA records and found that TLSA records can be spoofed and sniffed like other DNSsec records. Additionally, our tests involved self-signed SSL certificates, not a certificate authority. As a result, we discovered that forging a TLSA record is possible, and that an adversary could claim a self-signed SSL certificate to bypass DANE s certificate authentication. If DANE is used with existing SSL/TLS certificate authorities and a strong DNS server protecting itself against sniffing and spoofing, DANE will provide an additional level of security and reduce the attack vectors, as shown in the previous work section. However, DANE cannot stand alone in defending a network. 8