Encrypted DNS Request and Replies

Unlike most DNS services ENUM requests contain the sort of information that the NSA and telcos were caught up in the previous couple of years. Of late we have implemented our own name server software so we felt compelled to extend this to encrypt DNS requests and replies. We can only assume the only reason that the NSA is the only government spy agency that has made the news is because they were the only ones to get caught, not because they are the only ones doing it, or if others aren't doing it now they most likely will be within the next decade or so.

Besides the obvious government spy efforts, even if you have nothing to hide from any government, at least at this point in time, that doesn't mean you don't want to hide or conceal your personal information from your neighbours, employers, employees, your business competitiors or whoever the list can really go on and is unique to our own situations and what it is we're doing that we don't want others to know we're doing. No matter what you are doing there is bound to be someone you don't want sticking their nose into your business. After all, if we weren't worried about everyone knowing everything occurring in our lives we wouldn't put curtains up in our houses.

Currently there is no internet draft nor RFC covering this subject as far as I/we are aware, but that will be the next step for us from here.

The actual code doesn't decode the DNS response, I have compared the responses to a normal response and they matched but my intention wasn't to re-invent the wheel only prove that encrypted and unencrypted DNS lookups could utilise the same name servers without too much trouble.

http://www.e164.org/wiki/DNS_Encryption#head-638e1d7a237b652f496dc035e54930af9b74fe2b

If you really did want to do a dig replacement using this code it wouldn't be that difficult since most of the code is written, all you have to do is parse the information returned, then again I'm pondering about finishing the code simply so it can be easily integrated into things like FreePBX.

I'll probably get yelled at by the DNS purists because I hacked it together and cheated a little in the process, but again my intent wasn't
to do anything more than a simple proof of concept to prove that it could be done.

I haven't designed the system to be ENUM specific and should be usable for any DNS although it's possibly not the best way to do things and I'd be open to further discussions on this topic.

Just a quick update on this, it seemed to me that DNS is a little bit complicated for most people and those most likely to make use of this, such as those using FreePBX etc, might need a little extra help implementation wise. In the current form it can only be used directly from the command line, but I'm willing to work with others to integrate this with their software.

That said I extended the proof of concept to be a full dig replacement, well more or less, it has a rather limited number of DNS types implemented, the same number that e164.org supports funnily enough

The coding is done in the simplest way possible so that everyone should be able to pick it up and use it, obviously PHP code isn't the most efficient, at least when the code has to be started up over and over. If on the other hand it is being run as a daemon or fast-cgi/agi or as a module in something else then that is a different matter.

So if anyone is the slightest bit curious for a fully working cryptographic DNS request/reply example, I have posted the full source to the wiki:
http://www.e164.org/wiki/DNS_Encryption#head-638e1d7a237b652f496dc035e54930af9b74fe2b

I've also coded an AGI script for Asterisk, has IPv6 support, although this isn't 100% correct, and it would be better if it was a fastagi daemon instead of just a regular agi script that asterisk calls each time from the dial plan.

If it was a daemon ideally you would want to be able to track which DNS servers it was getting the quickest responses from and primarily favour making DNS requests to those servers first, not to mention disabling IPv6 requests if IPv6 lookups fail.

It's a work in progress I suppose, and the more I do the more ideas I come up with.

http://www.e164.org/enum2.phps

I've also coded and submitted a patch for FreePBX:

http://freepbx.org/trac/ticket/2797

Just because I like to be a gluten for punishment I've also made a proper Encrypted ENUM Lookup FastAGI PHP script. I had a look at a couple of other FastAGI scripts made in PHP and I couldn't find one that didn't cheat! They all used inetd or similar instead of containing any sockets and forking code of their own.

This is a pretty basic first crack at it, but it is a self contained daemon, you can you -v to prevent the main process from forking, but connections will still be forked to prevent locking while DNS lookups occur.

The 128bit key is only generated once during start up, this is both good and bad, good because urandom won't get hammered, bad because the memory could get extracted by another user, maybe a config option to regenerate might be in order.

It didn't occur to me that other enum lookup scripts we've produced didn't come with extension.conf examples too, so I've tried to document this script better.

http://www.e164.org/enumlookup.fagi

Bunch of todo stuff at the end of the top comment block, no doubt I have overlooked some thing or other, and there is sections that could be implemented better. I wonder if some people aren't taking me seriously because these proof of concepts were developed using PHP.

woprr schrieb:

hey evilbunny, old rabbit
sorry to stop Your blog, but pls forget this idea on the wrong ISO-OSI layer

Zum Vergrößern anklicken....

If there was a key handshake involved and because it's UDP I'd be inclinded to agree with you, but since DNSSec is going no where fast we can assume there won't be any wide spread DNS encryption any time soon either, so I avoided the whole key exchange and just distribute the public key with the clients.

and enable opportunistic strong IPSec encryption on Your servers instead and Your're done for clients doing direct dns req to Your servers.

Zum Vergrößern anklicken....

IPsec is overkill for what I'm trying to achieve, not to mention the potential load it would have on our servers. The whole idea with what I did was being able to encrypt the request/reply using the minimum amount of latency/packets possible. Currently 2 packets, 1 each way

Your solution offers too many possible side-channels for attackers

Zum Vergrößern anklicken....

Right tool for the right job, in this case one of the major attacks occouring all the time on the internet is passive attacks. While active attacks are possible, they are much more difficult, especially if you wish to run them over prolonged periods time.

there will be no h/w encryption support.

Zum Vergrößern anklicken....

Why not? I've used RSA and AES, both of which are heavily utilised with HTTPS.

I do appreciate the reply though, seems very few people know much about what drives some of the most important protocols on the internet.

woprr schrieb:

overkill... the NSA will break Your static key-system in months time. this sounds like WEP to me.

Zum Vergrößern anklicken....

Lets start with a little background here, as there is a vast difference between WEP and RSA encryption.

WEP used the RC4 algorithm, RC4 was chosen because it only takes 10 lines of code to implement not because it was robust or secure, originally most devices only supported 64 bit keys especially export devices out of the US due to export restrictions, although there were devices that supported 128 bit keys too.

However WEP as a protocol is fundamentally flawed in its design basically over how it handles and re-uses IVs, which is why it didn't really matter if 64 or 128 bit WEP was being used, it took roughly about the same time to break both. With decent encryption it should take exponentially more time to break a 128 bit key compared to a 64 bit key, in this case the protocol was much weaker then the encryption in this case.

So things went to WPA, which was also found to have flaws, so they came up with WPA2 which as far as I know doesn't have any of the flaws WPA or WEP have. Some where along the way things switched from RC4 to AES, and you can use RSA based public/private keys to authenticate instead of passwords.

Back to the topic at hand, 3072 bit RSA keys, NIST.gov recommends 3072 bit keys to protect 128 bit AES keys, and they estimate it should be secure until about 2030.

It's reasonable to assume that the NSA does have a technology advantage, however the question is how much CPU power do they have and can they waste it trying to break our key? Even at conservative estimates it will still be at least a decade before even they have enough CPU power at their disposal to break large RSA keys within a year or two, let alone a few months.

When anyone can break 3072 bit RSA keys in a few months time or less, breaking our key should be about the least of anyones worries, because most root certificates in browsers, which also use RSA public keys similar to our one, are only 2048 bit although some are 4096 bit. I hope there is no 1024 bit root certificates still, but up until recently there was.

others have made this design error before.

Zum Vergrößern anklicken....

This is exactly why I used RSA and AES, both are widely used and well proven technologies, I most certainly wasn't trying to come up with my own encryption system, if someone breaks these encryption systems we're all in trouble, not just e164.org

voipd schrieb:

Auch wenn ich englisch halbweg beherrsche, faende ich es gut wenn jemand auf deutsch eine kurze Zusammenfassung der Ursprungsbeitrages erstellen koennte.

Zum Vergrößern anklicken....

I'm sorry I don't speak German, but I know someone that does that might be able to explain this if he is about.

woprr schrieb:

all this You say is right. but against the NSA I fear You're just putting a lonely bar in the middle of a desert

Zum Vergrößern anklicken....

You seem to have more faith in the NSA's ability then I do. Based on the numbers/math I just can't see how even they would have the CPU power needed to crunch the numbers fast enough to break RSA keys. After all it's much easier to stick backdoors into systems then it is to break keys.

woprr schrieb:

agree. but remember we thought the same on Enigma in world war 2.

Zum Vergrößern anklicken....

Ummm I have a slightly different perspective here since I'm from an Australian background, so the propaganda you got was different from the propaganda I got

and NSA is about anti-terror now, those guys are motivated.

Zum Vergrößern anklicken....

Nah, mass domestic surveillance is the order of the day, the terrorism just happened to be a convenient excuse as to why, prior to all this the domestic spying occurred, but the NSA had to get the Canadians, or the British, or the Australians, or the .... to do the spying on their behalf...

So most attacks to be worried about are passive, the easiest way to beat them is to use encryption, virtually anything will work since they are tied up recording and sorting everything and due to the sheer volume of packets it becomes difficult to deal with anything that they don't know about.

So a little strong encryption goes a long way

and the concept of breaking encryption by CPU power is as old as the Britain electronic tube computer used in world war 2.

Zum Vergrößern anklicken....

There is numerous ways to break encryption, brute force is merely the slowest way possible.

today, they've got surely better in secret new cryptanalysis algorithms, e.g. consumer tech was always mostly only the waste of military tech.

Zum Vergrößern anklicken....

There is nothing published showing RSA or AES to be weak, RSA has been in use for over 20 years and there is a number of very smart guys that have been looking over it for a long time. Then of course we come to the banks and other financial institutions, I'm sure it's in their best interests to make sure there is no weakness in RSA or AES.

The whole point of cryptography is to come up with an algorithm that makes an attacker waste CPU till the end of time and still not be able to break or find the key, but in reality it's a trade off which is why NIST has recommended dates like by 2010 they suggest to stop using 1024 bit, and 2030 to stop using 2048 bit.

They put out reviews based on estimates of the known time to break keys of those lengths, however to the best of my knowledge it's highly unlikely even the NSA would be able to break 2048 bit keys in a reasonable time frame before 2030, which is why they prefer to backdoor things instead

If you don't trust NIST.gov there is other estimates produced, check out: http://www.keylength.com

woprr schrieb:

why should they publish? the U.S. is not a free country anymore.

Zum Vergrößern anklicken....

Anyone is free to publish, like the Chinese researchers that published the papers showing MD5/SHA were weaker then many first expected. I don't expect the NSA to publish such papers, but they aren't the only ones doing research in this area.

and banks use their own insulated networks You cant access. for customers, they've easily diverted the high risks by their lawyers: customer is responsible for using online-banking systems, read the terms.

Zum Vergrößern anklicken....

They can't write terms that goes against any banking laws, but that's besides the point most encryption these days is pretty standardised even if their networks are firewalled, although most financial problems occur in retail systems, not bank systems, customers don't wear that.

woprr schrieb:

in Your dreams, they can and they do

Zum Vergrößern anklicken....

In a 1998 ruling, a German court described DES as "out-of-date and not safe enough" and held a bank liable for using it.

http://web.archive.org/web/20000520.../archives/cryptography/html/1998-09/0095.html

Debian OpenSSL bug

Unfortunately the RSA key I generated for e164.org for use with encrypted DNS requests/replies was on a machine affected by the OpenSSL bug, which means it needed to be regenerated and the public key published previously is no longer valid.

The new key is:


and I've updated the php code on the wiki:

DNS Encryption - e164.org Wiki

Just a quick update on this, I've made a start on an internet draft document which can be found http://wiki.taug.ca/wiki/Draft-groth-dns-encryption . As above I initially was only going to use RSA+AES encryption and skip public keys/certificates but the only way to get strong crypto then would be to get all name servers from . up to support it which is a little optimistic at best.

I briefly thought about X.509 and ended up settling on using GPG keys instead as this has the potential to offer more flexibility in this particular case.

I almost have a working proof of concept, few little bugs to squash yet, but should be worked out soon I hope, once done the internet draft and the code examples should match up.