When a process is modeled in IT systems, it is normally designed with a large set of assumptions about the real world. The assumptions are just that – assumptions and sometimes wrong or incomplete. This leads to processes which do not “support” the full complexity of the real world. As a consequence, operational personal can spend a significant effort on “troubleshooting” the IT systems which are impacted by the process.
For instance – an order fulfillment process does not support the order to be cancelled after a certain point in the process, where in reality a customer can still exceptionally cancel his order through contacting the support staff and escalation. The IT system process will run to completion – requiring cleanup of the cancellation afterwards.
I call this the “Process Reality Disconnection”. It can make an organization incur significant running costs. It is worth specifying and implementing compensating / exceptional processes in IT systems with well defined pre and post conditions of each process outcome, because real world processes are always more complicated than initially assumed.
DNS is one of the major functional pillars upon which the internet is constructed. Its function of resolving human useful domain names to IP addresses has effectively been around since the beginning of internet time, where the internet was a peaceful place where only academics roamed….No surprises that security was not the major priority back then. I’ve intuitively known that DNS is “insecure”, but in the sense of my blog “If you think you’ve understood something – you probably haven’t” – my understanding of the technical mechanisms are superficial.
What brought me onto the subject of DNSSEC is a bit convoluted: I was investigating into the vulnerabilities of HTTPS with client authentication for a project of mine called SMT – Secure Messaging Transport. I remember reading a research paper from Vitaly Shmatikov about the flaws in SSL implementations – The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software where it was mentioned that clientAuthentication vulnerabilities would be looked into later. So what caught my interest was Vitaly’s 2010 paper called the hitchhikers guide to DNS cache poisoning.
As an engineer rather than hacker – its more interesting for me what the countermeasures are for attacks rather than exploiting vulnerabilities. The essential fact about the DNS cache poisoning is that DNSSEC would be essential to protect against this type of attack. I’m not sure if this is true for DNS hijacking which i haven’t had time to look into. Wikipedia claims that DNS forgery is still a problem.
In the future – DNSSEC has the potential to revolutionize the X.509 certification validation mechanisms. If for one’s own domains, the signature of valid host certificates were stored in trustworthy DNS then this would prevent some current vulnerabilities in HTTPS which were discovered by Moxie Marlinspike and demonstrated in his Blackhat 2009 slides
Recently Google announced that their public DNS resolver supports DNSSEC. This gives me hope that “we get it for free” if we wait for all ISP’s. But is it so simple? Google stated that:
“Effective deployment of DNSSEC requires action from both DNS resolvers and authoritative name servers. Resolvers, especially those of ISPs and other public resolvers, need to start validating DNS responses. Meanwhile, domain owners have to sign their domains.”
Its clear to me that domain owners will “sign their domains” if it means that clients connecting to their domains are better protected – there’s a natural motivation there. It’s not clear to me what a DNS client ( say a Java application ) needs to do to make sure it’s DNS queries are certified valid. This for me is the biggest question since in the end – it’s an application resolving the DNS domainname to IP address. What good is it to have an ISP’s DNS resolver sure of its domain information, but this never reaches a client. DNSSEC will not help solve any problems with physical security. If an intruder has physical access to the network – all bets are off. Arp Cache Poisoning and all the risks associated with this are still possible. This article shows how to use the Ettercap tool to do DnsSpoofing.
This will be one of my future missions – to find out the state of client support.