Recently, Elizabeth Warren's presidential campaign began using the domain name ewar.ren on Twitter. Links to this domain appear in the Senator's Twitter bio and in her Tweets.

It's a cute, short domain, but what's the deal with this .ren TLD? According to the ICANNWiki:

.ren is a Brand TLD delegated in ICANN's New gTLD Program. Beijing Qianxiang Wangjing Technology Development Co., Ltd. manages the TLD and is its Registry. The proposed application succeeded and was delegated to the Root Zone on 27 March, 2014. The proposed application succeeded and was delegated to the Root Zone on 27 March 2014.

Unfortunately, Senator Warren's use of .ren exposes her website to possible tampering by the Chinese government, which is of great concern after the 2016 election showed that political campaigns have to consider foreign governments as potential adversaries. The Warren campaign should probably switch to a more mainstream TLD operated in the United States, though by using a Certificate Transparency monitor such as Cert Spotter, they could at least detect if an attack occurs.

The Attack

Before someone can visit the ewar.ren website, their browser has to look up the IP address for ewar.ren using the Domain Name System (DNS). Their browser sends a DNS query to the user's resolver, which is a service typically operated by the user's Internet service provider, but could be another resolver such as Google's 8.8.8.8 or Cloudflare's 1.1.1.1. The resolver performs a series of DNS lookups until it finds the name server which is authoritative for ewar.ren.

Since DNS is a hierarchical system, the resolver first queries the Internet's root name servers. The root name servers refer the resolver to the name servers for the .ren TLD. When the resolver asks the .ren name servers, .ren returns a referral to the ewar.ren name servers. When the resolver asks the ewar.ren name servers, they reply with the IP address, which the resolver returns to the user's web browser. Finally, the browser connects to that IP address to retrieve the web page.

Instead of referring the user's resolver to the ewar.ren name servers, the .ren name servers could return a referral to rogue name servers that return an IP address for a rogue web server. The rogue web server could serve up disinformation intended to discredit Senator Warren.

There are a couple ways the Chinese government could execute this attack. The heavy-handed approach would be to compel Beijing Qianxiang Wangjing Technology Development Co., the operator of the .ren TLD, to update their DNS zone file to replace the real name servers with the rogue ones.

A far more devious approach would use the Great Firewall of China. Since the name servers for .ren are located in China, DNS queries for .ren that originate outside China have to pass through the Great Firewall. The Great Firewall could intercept the DNS queries and reply with referrals to the rogue name servers. We know from the Great Cannon attack against GitHub in 2015 that the Great Firewall has the ability to intercept requests originating from outside China.

Using the Great Firewall wouldn't require the involvement of the .ren TLD owners, and the attackers could be quite surgical in who they target, by letting some DNS requests through to the real name servers while intercepting others. At the very minimum, they could base their decision on the IP address of the user's resolver. If the resolver sends the client subnet of the user, as Google's 8.8.8.8 resolver does, the attackers could make their decision based on a prefix of the user's own IP address, which reveals the user's ISP and possibly their company and rough geographic location. For example, the attackers might be able to conceal their attack from known DNS monitoring services, the FBI, and the U.S. Congress. If the attackers are judicious in who they target, the attack could go undetected for quite some time.

Detecting the Attack with Certificate Transparency

Fortunately, if the user's web browser uses HTTPS to connect to ewar.ren, there is hope for detecting the attack. That's because the attackers must perform one additional step: obtain a valid SSL certificate for ewar.ren from a publicly-trusted certificate authority. This is not difficult for the attackers - since they can manipulate the DNS for ewar.ren, they can successfully convince certificate authorities that they control ewar.ren and are therefore authorized to receive a certificate for it.

However, this part of the attack can be detected. That's because both Chrome and Safari require that certificates be logged to public Certificate Transparency logs. So, as long as Senator Warren's campaign is monitoring Certificate Transparency logs for certificates for ewar.ren, they'll be notified when the attackers launch their attack. (Note the attackers could try to target only browsers that don't require Certificate Transparency yet, but that is a minority of Web traffic and they would need to be very careful not to accidentally target Chrome or Safari, which would cause a certificate error and increase the likelihood of detection.)

Since there are almost 50 logs to monitor, and millions of certificates to sift through every day, the easiest way to monitor Certificate Transparency logs is to use a Certificate Transparency monitor such as Cert Spotter. It's as simple as entering in your domain name and getting notified by email whenever a certificate is issued for your domain. If you get a notification about a certificate you didn't request, you know that something is wrong. Cert Spotter also has an easy API that lets you search certificates by domain name.

Even if Senator Warren switches to a TLD in the United States, it would still be a good idea for her campaign to monitor Certificate Transparency logs. That's because Certificate Transparency can help you detect compromises of your own DNS infrastructure, such as the recent Sea Turtle attacks which used stolen credentials to hijack the DNS of numerous organizations. In fact, the Department of Homeland Security now requires all federal agencies to monitor Certificate Transparency logs. (Certificate Transparency is also useful for non-security reasons, like cataloging your certificates to track their expiration dates.)

One last note - for Certificate Transparency to reliably detect DNS tampering, you need to make sure that visitors only access your website over HTTPS. Requests made over unencrypted HTTP don't need a certificate, so the attackers could intercept those requests without being detected by Certificate Transparency. To ensure visitors only use HTTPS, always use links that start with https://, and get your domain preloaded in the HSTS preload list so browsers will automatically upgrade HTTP links for your domain to HTTPS. (Currently, ewar.ren is not preloaded, and several of the Senator's Tweets include HTTP links to ewar.ren. The Warren campaign should fix both problems in addition to monitoring Certificate Transparency.)

Sidebar: DNSSEC: Not Even Once

It's impossible to talk about DNS security without someone claiming that DNSSEC, a standard for securing DNS that is still barely deployed despite existing for over 20 years, would solve the problem. The only difference DNSSEC would make here is that the attackers would need to know the DNSSEC keys for .ren so they could sign their rogue responses with a valid DNSSEC signature. Presumably, the Chinese government could compel the .ren TLD owners to hand over their DNSSEC keys. If they did, no one would know. It's this lack of transparency that makes DNSSEC vastly inferior to the Web PKI for securing Internet communication.