DNS over TLS: A Brief Analysis

The following is a quick write-up I presented to my senior leadership regarding DNS over TLS. It was rooted in the mistake presumption that Google was going to “enforce DNS-over-TLS”. In short. Interestingly, this system is currently in use by Android, but I do not believe this will ever attain mainstream adaptation.

High Level Summary

DNS over TLS is a 2016 protocol that allows clients to resolve a hostname over the HTTPS (TLS) protocol. The client will issue a GET request specifying the hostname and request type and the server will respond with the requested data in JSON. All requests are over TCP/853.

The implementation of DNS over TLS is in the user-space resolution libraries and should not may even be unnoticed by user-land application. From a security perspective, this has a noticeable but easily manageable security impact around TLS security and allowing traffic over port 853.

Except for Android, currently no major operating system natively supports DNS over TLS. I do not foresee this protocol gaining mass implementation nor do I see Google’s public DNS servers mandating it for all clients.

Relation to DNSSEC

DNSSEC and DNS over TLS are parallel features of the DNS protocol. DNSSEC is a DNS protocol extension that provides integrity, but fails to provide confidentiality. As such, a Man-in-the-Middle (MitM) attacker could identify potential endpoints or targets. The DNS over TLS protocol provides both integrity and confidentiality, independent of DNSSEC. Additionally, the DNS over TLS client and server does not communicate over the DNS protocol.

Security Implications

There are three (3) broad security implications from implementing DNS over TLS. These implications are specific to TLS, not DNS over TLS.

FIPS 140-2 Encryption Module

The FIPS 140-2 publication is a recommended standard for encrypted modules. As such, any encryption on government IT systems are subject to this standard. In the case of DNS-over-TLS, this must be through an approved encryption module, most typically OpenSSL.

TLS is not an encryption cipher. TLS is a protocol that provides three aspects of protection: Authentication via a certificate or user certificate, an encryption cipher and hashing mechanism.

Protocol Version

Any implementation of TLS over DNS would have to ensure that the TLS version is free from publicly known or feasible attacks. The current version of TLS is revision 1.2, with TLS 1.3 in draft format. All versions of TLS below 1.1 and all versions of Secure Socket Layer (SSL) are vulnerable to various attacks, namely POODLE and ORACLE.

Certificate Chain

Proper TLS implementations typically utilize a certificate signed by a trusted certificate authorities. In the case of DNS-over-TLS, this requires additional dependence on the certificate authorities for every resolution. This may not be a problem for an end-user who trusts commonly trusted root-level certificate authorities. However, root-level certificates are often subject to distrust or influence from hostile state actors and high-secure environments should not blindly trust the decision of Microsoft or Redhat.

Encryption Cipher and Hashing Mechanism

TLS is a mechanism to facilitate encryption over a network and the hashing algorithm provides data verification. Both encryption ciphers and hashing mechanisms are in slow flux and should be closely followed. For example, in 2015 numerous agencies and security researchers reported that they could compromise RC4 cipher. Google Security researchers reported that they can perform a collision attack against the SHA1 hashing algorithm. Both algorithms were widely implemented in the industry.

Open Connections

A TLS connection initialization is computationally expensive. Therefore, the RFC suggests that the client maintain an indefinite open TCP connection over port 853. This may require an additional firewall rule to the DNS server.


The DNS over TLS protocol was formalized in 2016. Due to its relatively young age, currently there are currently very few implementations.

As the RFC documentation specifies, DNS over TLS should be implemented at the host resolution library level, particularly the getaddrinfo(3) and gethostbyname(3) functions. As such, the operating system only needs to maintain library ABI compatibility, but the application does not need implement anything. Currently, only the Android operating system has implemented DNS over TLS while some Linux user-land tools can perform DNS over TLS resolutions.

Google Resolution

Google has currently implements DNS over TLS on,, 2001:4860:4860::8888 and 2001:4860:4860::8844. Google also offers a web-interface which submits a JSON GET request.

For example, to URL https://dns.google.com/resolve?name=farhan.codes would resolve the hostname farhan.codes. The formatted response is as follows:

Standard Implementation Method

There are several implementations of DNS over TLS encapsulated in simplified Docker containers. In summary, the containers utilize a standard web server to handle the HTTP layer and communicates to the DNS server over the DNS protocol. This is a standard method of isolating the HTTP layer from the application layer.

Future Speculation

I do not believe that the DNS over TLS protocol will attain mass implementation, nor that Google will mandate it for use of their DNS servers. There are three (3) primary reasons why:

  1. Architecture: Historically, short-term add-ons to a protocol are superseded by permanent change to the protocol or a parallel revision. If the goal is confidentiality, this can be achieved via an extension to the protocol.
  2. Performance: Per Google research, DNS is a bottleneck when a URL has multiple external sources. However, I suspect the current DNS resolution is still significantly faster. A UDP-based connection requires only a UDP socket with a simple sendto(2) call, whereas DNS over TLS requires multiple layers of conversion across potentially multiple machines. Specifically, from TLS to HTTP across the internet, converted to the DNS server and back across the same route.
  3. Standardization: There does not appear to be a TLS over DNS standardization. Most implementations utilize HTTP, but this is not specified in the RFC. Additionally, the JSON format differs between the implementations.


This paper is based on multiple sources. The primary sources are cited below.

Two Types of Penetration Testers

There are two types of penetration testers in the industry.

Those who identify risk and vulnerabilities beyond a simple Nexpose/Nessus/Qualys scan. And those who want to “win”.

The job of the “winner” is to get DA on their client’s network. Great! But once they’ve gotten it, they show off. Look how much information I can get with the DA account! I can get access to these databases and these spreadsheets. Sensitive Information! Be afraid! I pwned you noobs!!!

The other type of penetration tester also seeks DA. He finds it. Great! Now he moves on to another vulnerability. And then another. Can I get DA another way? Maybe? Okay, what else is exploitable here. Along the way if he finds sensitive information, he presents it to the client. But his job is not focused on presenting information, its on finding avenues to find information.

If the “winner” focuses on one issue. He writes his report and presents it to the client. The client is enamored, impressed, even afraid. But if another “winner” penetration tester were to come in tomorrow, because the first only focused on one issue, the second would just find another avenue. A third might find a third issue. Until they are merely playing wack-a-mole.

The second type reports the issues he identified, an array of vulnerabilities, ranked by severity. He may briefly present information he was able to access, but then moves on. His job is to work towards resolution, not playing hacker. Overall security is enhanced.

Thoughts? No? I didn’t think so, no one reads this blog.

Four Simple Technologies for Privacy We Should All Know

This recently PRISM scandal has made me concerned about security and privacy, even more than before. I truly do not think that the government is spying on me as an individual and will (hopefully) never kick down my doors and take me to the Ministry of Luv. I have nothing to hide. But that’s not the point. Its the principle. You have no right, neither moral nor practical, to monitor my communication. In fact, we have explicit rights protecting us!

But in the wake of the PRISM scandal, we now know with certainty that the government is actively monitoring everyone. Therefore, I would like to impart my knowledge of encryption to the public. Here are four simple ways to keep yourself safe from the government.

A) Pretty Good Privacy (PGP) – This is a widely used, tried and tested method of encrypting text and files prior to sending them to the end user. Because all encryption is done prior to the connection, this is one of the better systems out there.

Here’s how it works: You exchange public keys with whoever you want to communicate with. When you want to send the other person a message, you encrypt the data his public key (not your own). The end-user will decrypt the data with his private key (not yours). Conversely, if someone wants to send you a message, he will encrypt the message with your public key and you will then decrypt it with your (not his) private key.

If that’s confusing, think of it like giving people a lock-box that they can put contents in and lock and no one can unlock it but you. That lock-box is your public key. The key to the lock-box is your private key.

So, a few drawbacks to this method:

  • PGP’s major drawback is that without an infrastructure, anyone can create a fake public key in your name and send it around in your name. Then, he can intercept messages to you, decrypt them, modify them if desired, and send them back to you using your actual public key, and no one would be the wiser. Its a bit complicated, but entirely possible.
    • You easily can get around that by creating a “web of trust”, but it involves a bit more work.
    • You can create an infrastructure for PGP if you want. MIT hosts their famous key server, but there are several infrastructural problems with it.
  • Lets be real, its not 100% user-friendly or intuitive. Mailvelope is the best attempt I have seen to make it more user-friendly and I personally use it when not on Linux.
  • It is feasible that the NSA has the CPU and GPU power to brute-force a low-bit key.

If you are concerned about having your keys broken into, you can try using;

$ gpg --batch --gen-key << EOF > Key-Type: RSA
> Key-Length: 8192
> Key-Usage: Auth
> Name-Email: [Your email here]
> Name-Comment: [Some comment]

B) Tor, The Onion Protocol – The Tor protocol is a method of obscuring the originating source of a network connection. Tor accomplishes this by bouncing connections off of servers around the world. Each computer you bounce your connection off of knows the previous source and next destination, but does not know the two connections prior or two after. And given that all data through the network is encrypted, no one is able to meaningfully modify the intended next sources. After a number of hops, a final end-point will initiate the actual connection to the intended destination. That final destination perceives the end-point as the source of the connection, but does not know the original source.

Tor is largely used for anonymous web-surfing, but because it functions as a SOCKS5 proxy, it can be used for just about anything!

Another innovation of Tor is Hidden Services. In the aforementioned configuration, the client knows who the server is, but the server does not know who the client is. A Hidden Service is when a server hides its identity, but the client is still able to connect to it. The mechanisms are too complex to explain here, but you can read them on the Tor website.

You can download Tor here.

C) Bitcoin – Bitcoin is an operational electronic currency that are independent of any government. It offers security, anonymity, and is accepted by thousands of people worldwide.

Anonymity – User accounts, called Bitcoin addresses or simply addresses,  appear as 27-34 arbitrary numbers and letters such as 31uEbMgunupShBVTewXjtqbBv5MndwfXhb. In reality, addresses are the equivalent of public keys that are used by payers to sign transactions. Address are completely independent of names, addresses, numbers or any other identifying information. The user has control over them by having the corresponding private key, which again, does not have any associated identifying information.That’s more anonymous than a Swiss bank account!

Secure – Bitcoin uses the robust public-private key infrastructure to secure encryption between bitcoin sender and receiver. The sender of bitcoin (payer) obtains the receiver’s bitcoin address and digitally signs his bitcoins to the receiver. This makes electronic theft done by utilizing the Bitcoin system next to impossible.

The Bitcoin infrastructure has several components. Therefore, if you’re interested, I suggest you watch the following video. Its a bit dated, but n

D) Disk Encryption – Disk Encryption is when data is encrypted while it is stored on your hard-drive.

If someone were to obtain physical access to your machine, either through theft or government seizure (same thing?), they would be able to access everything on your machine, including services and systems you were currently logged in on such as Gmail or Facebook. Disk Encryption is a method of preventing the bad guys from accessing your machine. There are dozens of types of disk encryption. Before I talk about the exact implementations, I want you to understand the concept.

Disk Encryption means that everything on your computer is encrypted, rather than encrypting individual files one by one. However, files are only encrypted when they reside on the hard-drive. So, if you email out a file, it will not be encrypted during transmission. For that, you will need to use PGP or a related technology.

Windows has two main tools, the first is Microsoft Full Disk Encryption. However, this service is proprietary and will require you to have Windows Professional. A free alternative is TrueCrypt, which functions in a similar manor.

One note about disk encryption tools: It is more than theoretically possible to recover the hard-drive encryption keys from the memory. It requires the attacker to literally freeze the RAM with a cooling agent, soft-reboot the machine, then boot into a custom system that performs a RAM-dump via Firewire — I have personally seen this done, it is not just theory.

Conclusion and Comments

The aforementioned technologies are, to the best of my knowledge, technically secure against even to the most sophisticated attackers. However, there is one major weak link in this chain: the end-user. Many times, users make simple mistakes which allow attackers to circumvent the entire protective scheme.

For example, PGP and Disk Encryption ultimately require a password to protect the encryption, in the event that the attacker is able to gain physical access to the hard-drive or private keys. If your password is weak, such as being under 20 characters, your data is liable for decryption.

In the future, I hope that all of these technologies become more easy to use and user-friendly.

The only exception I can think of is if the computing power of the NSA is strong enough to break any of these mechanisms. That’s entirely possible. And violence trumps even that — put a gun to the head of even the most rabid Zionist and I’ll give anyone want they want to save his life.

That aside…happy encrypting!

Hotspot Hijacking & Password Capturing

Unless you know enough about security to know what’s going on behind the scenes, Wifi is beyond insecure. Even with SSL as an attempt to secure a web connection, your connection is still fundamentally insecure. This is an explanation of how someone would capture passwords and other variables sent over an SSL connection that uses Wifi. In essence, its a Man in the Middle (MiM) attack over Wifi that modifies the victim’s HTTP connection and thus gathers GET and POST variables. I was not the first to create it, but I independently thought of it and then combined a few techniques together.

Here’s how it works:

Lets say you go to a Starbucks and they offer an open Wifi connection. Suppose the AP name is attwifi. First, the attacker connects his computer to the legitimate AP so that he can go online. The attacker can use a separate means to get online, I just find this most convenient.

Using a second wifi card that can go into Master mode, set the IP address to something the legitimate Wifi network does not use. No one uses, so when I was testing this I used that. Since the attacker’s machine will balance between the legitimate AP and fake AP, it needs to be able to distinguish between the two and prevent collisions. So works great.

ifconfig wlan0
ifconfig wlan0 up

Then, the attacker must configure dhcpd, in my case, located in /etc/dhcp/dhcpd.conf:

subnet netmask {
	option domain-name-server;
	option routers;

On the second wifi card the attacker must then create an AP by the same name as the legitimate AP. Most public APs are Open networks without any encryption or anything. But even if they weren’t open, the host would likely just give you the password upon request. To create an open network, the attacker must set the following settings in /etc/hostapd/hostapd.conf:


Finally, start to turn stuff on. First, the layer 3 routing and NAT rules:

echo 1 > /proc/net/ipv4/ip_forward # Allows routing
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # Turns on NAT
iptables -A FORWARD -j ACCEPT # Accepts everything

Then turn on dhcpd:


Then I start broadcasting the Access Point:

hostapd /etc/hostapd/hostapd.conf

At this point, anyone who connects to attwifi will either connect to the attacker, or the authentic AP. As of now it makes no difference who they connect through. If they connect through the attacker’s AP, they will just be forwarded through the real attwifi AP anyways with a unnoticed extra hop.

Up to this point you’ve simply done a Man in the Middle (MiM). The final step is where the magic lays. The attacker must redirect connects to port 80 through sslstrip, a tool that intercepts a victim’s web requests, and removes all references of SSL (ie, changes ‘https’ to ‘http’) and logs all relevant variables that are passed over. For the record and so that I don’t come across as a complete script kiddie, I wrote a tool similar to sslstrip, but sslstrip is significantly better and cleaner written.

The attacker would do this:

iptables -t nat -A PREROUTING -p tcp -s --dport 80 -j DNAT --to-destination
python ./sslstrip.py -w attwifi.log -l 31337

At this point, the attacker’s machine will be logging GET and POST variables directed through his machine, even if the connection was intended to be secured with SSL. The only sign the victim may notice is that his usually SSL-encrypted connection is no longer secure. A savvy user might notice this, but the vast majority will not. In fact, the way most sites are written, such as Facebook, you enter your credentials onto an initial insecure page! While the form‘s GET or POST target is secure, the page you received is certainly not. Unless he checks the initial page’s code, he would never know that his connection is being tampered with.

There’s one final optional step. A client might be connected to the correct AP for hours without any reason to disconnect. With Windows, if there are multiple APs by the same name and the user is experiencing connection issues on one, Windows will automatically switch to the other AP. You can break a user’s connection and force him to connect through you using the following command:

aireplay-ng -0 0 -a 00:AA:BB:CC:DD:EE -c 01:12:34:56:78:9A ath0

Where 00:AA:BB:CC:DD:EE is the access point and 01:12:34:56:78:9A is a client. This last step is particularly insidious.

The fundamental issue here is not a weakness in SSL, but in Wifi that allows for an easy MiM. However, there are some steps a web site can take to help fix the problem:

  1. Require users to go to https://www.site.com instead of http://www.site.com. A simple redirection or link will not do, as sslstrip and similar programs can capture the redirection-attempt.
  2. Javascript code that does client-side verification to scan for for page modifications
  3. Two-factor authentication, such as an RSA token. While this will not stop the attacker from capturing your variables, it makes re-authentication as the victim impossible. Also a great solution, but won’t prevent against data leakage.
  4. Have the user click a link that requests login. Once at the new page, have an image pointing up at the URL bar and asking the user to verify if SSL is being used. But, this requires too much user-verification.
  5. Change the port from 80 to 8080, or so, thus temporarily thwarting the iptables rule. But obviously a broader or more focused iptables rule would counter-thwart that.

Your thoughts…?

I doubt I have to legally add a disclaimer, but I’ll do it anyways… don’t do anything illegal! You are responsible for your own actions!