Geoff Huston, APNIC
The front page story of the September 13, 2011, issue of the International Herald Tribune said it all: "Iranian activists feel the chill as hacker taps into e-mails." The news story relates how a hacker has "...sneaked into the computer systems of a security firm on the outskirts of Amsterdam" and then "...created credentials that could allow someone to spy on Internet connections that appeared to be secure." According to this news report, the incident punched a hole in an online security mechanism that is trusted by hundreds of millions of Internet users all over the network.
Other news stories took this hyperbole about digital crime and tapping into e-mail conversations on the Internet to new heights, such as The Guardian's report on September 5, 2011, which claimed that the "...DigiNotar SSL certificate hack amounts to cyberwar, says expert." 
If application-level security is so vulnerable to attack, then this incident surely calls into question the basic mechanisms of trust and security upon which the entire global Internet has been constructed. By implication it also calls into question the trustworthiness of services operated by the major global Internet brands such as Google and Facebook, as much as it raises doubts about the levels of vulnerability for the use of online services such as banking and commercial transactions.
Just how serious is this problem? Are we now at the end of civilization as we know it?
Is digital cryptography now broken? Has someone finally managed to devise a computationally viable algorithm to perform prime factorization of massively large numbers, which lies at the heart of much of the cryptography used in the Internet today?
I really don't think so. (At the very least, if someone has managed to achieve this goal, then that person is staying very quiet about it.)
Does this situation represent a systematic failure of security? Do we need to rethink the entire framework of cryptography and security in the Internet?
Not this time.
As far as I can tell, there has been no dramatic failure in the integrity of the digital technology used for security in the Internet today. Yes, some were surprised by this failure, including the Netherlands government, which uses certificates issued by the compromised certification authority, DigiNotar (http://www.diginotar.com) as part of its online service infrastructure. But the hacking incident was not based on a successful direct attack on the technology of cryptography by itself, and there is no reason to suppose that the strength of today's encryption algorithms is any weaker today than yesterday.
But in observing that the basic technology tools of the Internet security framework are still operating within acceptable bounds of integrity, and observing that this hacking attack did not create a gaping hole in our commitment to digital cryptography, what cannot be claimed is that the use of these cryptographic tools in today's Internet service environment is similarly trustworthy. The hacking attempt apparently was successful in so far as it provided the capability for third parties to impersonate trusted services and thereby capture users' private data, and evidently some people did indeed do precisely that, and that is not good at all.
Let's look a little more closely at this hacking episode and examine the way in which security is applied to the world of web browsing and the manner in which the vulnerabilities in this security framework were evidently exploited.
Securing a Connection
When I point my browser at my online banking service—or at any other secure website for that matter—a part of the browser navigation bar probably glows a reassuring green, and when I click it I get the message that I am connected to a website run by the Acme Banking corporation, and that my connection to this website has been encrypted to prevent eavesdropping. However, the website certificate was issued by some company that I have never even heard of. When I ask for more information, I am told the domain name, the company to whom the certificate for this domain name was issued, the identity of the certificate issuer, and the public key value. I am also reassuringly informed that the message I am viewing was encrypted before being transmitted over the Internet, and that this encryption makes it very difficult for unauthorized people to view information travelling between computers, and it is therefore very unlikely that anyone could read this page as it passes through the network. All very reassuring, and for the most part true, to the extent that we understand the strength of cryptographic algorithms in use today. The connection is using a Transport-Layer Security (TLS)  connection and the traffic is encrypted using a private session key that should be impenetrable to all potential eavesdroppers.
But that is not the entire truth, unfortunately.
It may well be that your conversation is secure against eavesdropping, but it is only as secure as the ability of the other party to keep its private key a secret. If the other side of the conversation were to openly broadcast the value of its private key, then the entire encryption exercise is somewhat useless. So, obviously, my local bank will go to great lengths to keep its private key value a secret, and I rely on its efforts in order to protect my conversations with the bank.
But even then it is not quite the full story.
Am I really talking to my bank? Or in more general terms, am I really talking to the party with whom I wanted to talk?
The critical weakness in this entire framework of security is that the binding of certificates and keys to Domain Name System (DNS) names is not an intrinsic part of the DNS itself. It is not an extension of Domain Name System Security Extensions (DNSSEC) [3, 4]. It has been implemented as an add-on module where third parties generate certificates that attest that someone has a particular domain name. Oddly enough, these Certification Authorities (CAs) may never have actually issued that particular domain name, because they are often disconnected from the DNS name registration business. Their business is a separate business activity where, after you have paid your money to a domain name registrar and secured your domain name, you then head to a domain name Certification Authority and pay them money (commonly they charge more money than the name registration itself) and receive a domain name certificate.
Who gets to be a Certification Authority? Who gets to say who has which domain name and what keys should be associated with that domain name?
Oddly enough the answer is, at a first level of approximation, just about anyone who wants to! I could issue a certificate to state that you have the domain name www.example.com and that your public key value is some number. The certificate I issue to that effect would not be much different from the certificates issued by everyone else. Yes, my name would be listed as the certificate issuer, but that is about all in terms of the difference between this certificate and the set of certificates you already trust through your browser.
So what is stopping everyone from being a Certification Authority? What is preventing this system from descending into a chaotic environment with thousands of certificate issuers?
For this situation the browser software folks (and other application developers of secure services) have developed a solution. In practice it requires a lot of effort, capability, diligence, and needless to say, some money, to convince a browser to add your Certification Authority public key to its list of trusted Certification Authorities.
You have to convince the browser developers that you are consistently diligent in ensuring that you issue certificates only to the "correct" holders of domain names and that you undertake certificate management practices to the specified level of integrity and trust. In other words, you have to demonstrate that you are trustworthy and perform your role with consistent integrity at all times. You then get listed with all the other trusted Certification Authorities in the browser, and users will implicitly trust the certificates you issue as part of the security framework of the Internet.
How many trusted Certification Authorities are there? How many entities have managed to convince browser manufacturers that they are eminently trustable people? If you are thinking that this role is a special one that only a very select and suitably small number of folks who merit such absolute levels of trust should undertake for the global Internet—maybe two or three such people—then, sadly, you are very much mistaken.
Look at your browser in the preferences area for your list of trusted Certification Authorities, and keep your finger near the scroll button, because you will have to scroll through numerous such entities. My browser contains around 80 such entities, including one government ("Japanese Government"), a PC manufacturer ("Dell Inc"), numerous telcos, and a few dedicated certificate issuers, including DigiNotar.
Do I know all these folks that I am meant to trust? Of course not! Can I tell if any of these organizations are issuing rogue certificates, deliberately—or far more likely—inadvertently? Of course not!
The structural weakness in this system is that a client does not know which Certification Authority—or even which duly delegated subordinate entity of a Certification Authority—was used to issue the "genuine" DNS certificate. When a client receives a certificate as part of the TLS initialization process, then as long as any one of the listed trusted Certification Authorities is able to validate the presented certificate, even if it is the "wrong" Certification Authority, then the client will proceed with the session with the assumption that the session is being set up with the genuine destination.
In other words the entire certification setup is only as strong—or as weak—as the weakest of the certification authorities. It really does not matter to the system as a whole if any single Certification Authority is "better" at its task than the others, because every certified domain name is protected only to the extent that the "weakest" or most vulnerable trusted Certification Authority is capable of resisting malicious attack and subversion of its function. Indeed, one could argue that there is scant motivation for any trusted Certification Authority to spend significantly more money to be "better" than the others, given that its clients are still as vulnerable as all the other clients of all the other Certification Authorities.
In other words, there is no overt motivation for market differentiation based on functional excellence, so all certificates are only as strong as the weakest of all the Certification Authorities. And therein lies the seed of this particular hacking episode.
The hack itself now appears to have been just another instance of an online break-in to a web server. The web server in question was evidently running the service platform for DigiNotar, and the hacker was able to mint some 344 fraudulent certificates, where the subject of the certificate was valid, but the public key was created by the hacker. A full report of the hacking incident was published by Fox-IT .
To use these fraudulent certificates in an attack requires a little more than just minting fraudulent certificates. It requires traffic to be redirected to a rogue website that impersonates the webpage that is under attack. This redirection requires collusion with a service provider to redirect client traffic to the rogue site, or a second attack, this time on the Internet routing system, in order to perform the traffic redirection.
So minting the fraudulent certificates is just one part of the attack. Were these fake certificates used to lure victims to fake websites and eavesdrop on conversations between web servers and their clients? Let's look at the client’s validation process to see if we can answer this question.
When starting a TLS session, the server presents the client with a certificate that contains the server public key. The client is expected to validate this certificate against the client's locally held set of public keys that are associated with trusted certification authorities. Here is the first vulnerability. The client is looking for any locally cached trusted key to validate this certificate. The client is not looking as to whether a particular public key validates this certificate. Let's say that I have a valid certificate issued by the Trusted Certification Authority Inc. for my domain name, www.example.com. Let's also say that the server belonging to another Certification Authority, Acme Inc, is compromised, and a fake certificate is minted. If a user is misdirected to a fake instance of www.example.com and the bad server passes the client this fake certificate, the client will accept this fake certificate as valid because the client has no presumptive knowledge that the only key that should validate a certificate for www.example.com belongs to the Trusted Certification Authority Inc. When the key belonging to Acme Inc validates this certificate and ACME is a trusted entity according to my browser, then that is good enough to proceed.
Actually that is not the full story. What if I wanted to cancel a certificate? How do certificates get removed from the system and how do clients know to discard them as invalid?
A diligent client (and one who may need to check a box in the browser preference pane to include this function) uses a second test for validity of a presented certificate, namely the Online Certificate Status Protocol (OCSP) . Clients use this protocol to see if an issued certificate has been subsequently revoked. So after the certificate has been validated against the locally held public key, a diligent application will then establish a secure connection to the certification authority OCSP server and query the status of the certificate.
This secure connection allows for prompt removal of fraudulent certificates from circulation. It assumes of course that clients use OCSP diligently and that the Certification Authority OCSP server has not also been compromised in an attack, but in an imperfect world this step constitutes at least another measure of relative defense.
The OCSP server logs can also provide an indication of whether the fraudulent certificates have been used by impersonating servers, because if the certificate was presented to the client and the client passed it to an OCSP server for validation, then there is a record of use of the certificate. The Fox-IT report contains an interesting graphic that shows the geolocation of the source addresses of clients who passed a bad *.google.com certificate to OCSP for validation. The source addresses have a strong correlation to a national geolocation of Iran.
Obviously this attack requires some considerable sophistication and capability, hence the suspicion that the attack may have had some form of state or quasi-state sponsorship, and hence the headlines from The Guardian, quoted at the start of this article, that described this attack as an incident of cyberwarfare of one form or another. Whether this incident was a cyber attack launched by one nation state upon another, or whether this was an attack by a national agency on its own citizens is not completely clear, but the available evidence points strongly to the latter supposition.
Plugging the Hole?
This incident is not the first such incident that has created a hole in the security framework of the Internet, and it is my confident guess that it will not be the last. It is also a reasonable guess that the evolution of the sophistication and capability that lie behind these attacks points to a level of resourcing that leads some to the view that various state-sponsored entities may be getting involved in these activities in one way or another.
Can we fix this?
It seems to me that the critical weakness that was exploited here was the level of disconnection between domain name registration and certificate issuance. The holders of the domain names were unaware that fraudulent certificates had been minted and were being presented to users as if they were the real thing. And the users had no additional way of checking the validity of the certificate by referring back to information contained in the DNS that was placed there by the domain name holder.
The end user was unable to refine the search for a trusted Certification Authority that would validate the presented certificate from all locally cached trusted Certification Authorities to the one certification authority that was actually used by the domain name holder to certify the public key value. So is it possible to communicate this additional information to the user in a reliable and robust manner?
The last few years have seen the effort to secure the DNS gather momentum. The root of the DNS is now DNSSEC-signed, and attention is now being focused on extending the interlocking signature chains downward through the DNS hierarchy. The objective is a domain name framework where the end client can validate that the results returned from a DNS query contain authentic information that was entered into the DNS by the delegated authority for that particular DNS zone.
What if we were able to place certificates—or references to certificates—into the DNS and protect them with DNSSEC? The DNS-based Authentication of Named Entities (DANE) Working Group of the IETF 0, 7] is considering this area of study. They are considering numerous scenarios at present, and the one of interest here does not replace the framework of Certification Authorities and domain name certificates, but it adds another phase of verification of the presented certificate.
The "Use Cases"  document from the DANE working group illustrates the proposed approach. I will quote a few paragraphs from this document. The first paragraph describes the form of attack that was perpetrated in June and July this year on the DigiNotar CA. It is not clear to me if the text predates this attack or not, but they are closely aligned in time:
"Today, an attacker can successfully authenticate as a given application service domain if he can obtain a 'mis-issued' certificate from one of the widely-used CAs—a certificate containing the victim application service's domain name and a public key whose corresponding private key is held by the attacker. If the attacker can additionally insert himself as a man in the middle between a client and server (for example, through DNS cache poisoning of an A or AAAA record), then the attacker can convince the client that a server of the attacker's choice legitimately represents the victim's application service." 
So how can DNSSEC help here?
"With the advent of DNSSEC [RFC 4033], it is now possible for DNS name resolution to provide its information securely, in the sense that clients can verify that DNS information was provided by the domain holder and not tampered with in transit.
The goal of technologies for DNS-based Authentication of Named Entities (DANE) is to use the DNS and DNSSEC to provide additional information about the cryptographic credentials associated with a domain, so that clients can use this information to increase the level of assurance they receive from the TLS handshake process.
This document describes a set of use cases that capture specific goals for using the DNS in this way, and a set of requirements that the ultimate DANE mechanism should satisfy. Finally, it should be noted that although this document will frequently use HTTPS as an example application service, DANE is intended to apply equally to all applications that make use of TLS to connect to application services named by domain names." 
Does DANE represent a comprehensive solution to this security vulnerability?
I would hesitate to be that definitive. As usual with many aspects of security, the objective of the defender is to expend a smaller amount of effort in order to force an attack to spend a far larger amount of effort. From this perspective, the DANE approach appears to offer significant promise because it interlocks numerous security measures and forces a potential attacker to compromise numerous independent systems simultaneously. Within the DANE framework the attacker cannot attack any certification authority, but must compromise a particular certification authority, and the attacker must also attack DNSSEC and compromise the information contained in signed DNS responses for that domain in order to reproduce the effects of the attack described here. This scenario seems to fit the requirement of a small amount of additional defensive effort by the server and the client, creating a significantly larger challenge to the attacker.
But many preconditions must be met here for this approach to be effective:
It is probably not perfect, but it is a large step forward along a path of providing more effective security in the Internet.
Unfortunately, this solution does not constitute an instant solution ready for widespread use today—or even tomorrow. We could possibly see this solution in widespread use in a couple of years, but, sadly, it is more likely that securing the DNS for use in the Internet will not receive adequate levels of attention and associated financial resourcing in the coming years. It may take upward of 5 years before we see ubiquitous adoption of DNSSEC and any significant levels of its use by a DANE framework for certificates in the DNS. Until then there is the somewhat worrisome prospect of little change in the framework of Internet security from that used today, and the equally concerning prospect that this particular hacking event will not be the last.
I am indebted to Olaf Kolkman of NLnet Labs for a stimulating conversation about this attack and the implications for securing the Internet. NLnet Labs is one of a small number of innovative and highly productive research groups that has developed considerable levels of expertise in this area of security and the DNS. 
When you lose that essential element of trust, your continued existence as a trusted Certification Authority is evidently a very limited one. On Tuesday September 20, 2011, the Dutch company DigiNotar was officially declared bankrupt in a Haarlem court.
The views of this article do not necessarily represent the views or positions of the Asia Pacific Network Information Centre.