Digital certificate standard yields to hackers
Researchers at the Black Hat Briefings demonstrated exploits against the X.509 standard for digital certificates used by Secure Sockets Layer
Two researchers demonstrated exploits against Secure Sockets Layer — the Web protocol for establishing secure sessions between servers and clients — at the Black Hat Briefings in Las Vegas last month.
Dan Kaminsky, director of penetration testing at IOActive, said SSL is broken, and he is working with vendors to help them quickly patch their implementations.
SSL is a scheme using the X.509 standard for digital certificates to secure Internet connections for online transactions. But after more than a decade, the certificates are still not providing an adequate level of assurance. “We’ve been trying to get it done for 10 years, and it just isn’t working,” Kaminsky said.
“The X.509 standard is a total nightmare,” said hacker and yachtsman Moxie Marlinspike of Thoughtcrime.org. “In practice, the standard is weak and everyone does everything differently.”
That lack of standardization can make it possible to fool Web browsers and other clients into accepting certificates that are invalid or do not apply to the server to which the client is being directed. In separate presentations at the computer security conference, Kaminsky and Marlinspike demonstrated exploits against SSL.
Digital certificates use public/private key pairs to sign and validate the IDs as a way to authenticate the identity of a person, machine or application online. Authentication is a necessary element of security.
“The majority of [online] attacks happen because servers don’t know who they are talking to,” Kaminsky said.
Deputy Defense Secretary Robert Lentz, DOD’s chief information assurance officer, also speaking at the conference, cited identity authentication as a key security challenge for the department. DOD has fielded one of the world’s largest public key infrastructures based on its Common Access Card, which contains digital certificates. But “it still is not easy to use,” he said of PKI.
Kaminsky and Marlinspike independently came up with similar exploits, which Marlinspike called the null prefix attack. Using a man-in-the-middle attack to intercept a connection, a null character can be inserted following a legitimate URL, followed by a malicious URL, tricking most SSL clients into accepting the certificate for the malicious site, while displaying the URL for a legitimate site.
Kaminsky also described a technique to exploit a root zone that has been signed with an outdated hashing algorithm.“This will work soon, but not tomorrow,” he said. He estimated it would be about 18 months before advances in computing power make it practical.
Kaminsky said he has spent the past several months examining X.509. “Pretty much every corner we looked at in X.509 we found ugliness,” he said. “It is remarkably fragile. There are a lot of ambiguities in a technology that ought not to be ambiguous.”
Kaminsky has been working with vendors that implement the technology, such as Open SSL, Netscape and Microsoft, to patch the problems until a more permanent solution can be put into place. He would like to see X.509 replaced with a scheme built on the Domain Name System using the DNS Security Extensions.
“We have to start over,” he said. “The way to do this seems to be through the DNSSEC track.”
Kaminsky gained attention last summer with the discovery of a security flaw in the DNS protocols. He succeeded in getting industry support for a quick fix for that problem until DNSSEC could be implemented as a more complete solution. Full DNSSEC deployment is several years off, but Kaminsky still is a believer in DNS as the basis for cryptographically signing digital certificates and making keys available for authenticating clients and servers. Despite its flaws, DNS has scaled well and worked reliably for the last 25 years as the technology for directing Internet traffic to the proper addresses. “Let’s get cryptographic keys from it,” he said.
In the meantime, he said, vendors are cooperating to fix the X.509 implementations in their products in the short term.
“We have some lead time on this, as far as we know,” he said. “We have a chance to fix a problem now, before it blows up in our faces.”