The IETF 83 technical plenary looked into browser security challenges, a timely topic as illustrated by ongoing work in several working groups (WGs) and debates in at least two lunch meetings on issues around web authentication. With a number of highly publicized security incidents in 2011, web security has gotten a lot of attention from the media, politicians, and governments, said Hannes Tschofenig, a member of the Internet Architecture Board (IAB).
“Even my favorite gaming platform, Steam, got hacked—it’s really bad,” said Tschofenig, an engineer who is also a driver of the IAB privacy effort. He also pointed to the fact that many aspects of browser security really require attention outside of the IETF. While the protocol work is done within the IETF and sister organizations like the W3C and its web security- and web authentication-related WGs, there is a longer chain of events that need to happen to ensure secure deployment.
Making Browser Communication More Secure
As Eric Rescorla, a developer of transport layer security (TLS) standards, said, “On paper, web security does not look that bad.” The TLS WG has delivered more than 27 RFCs, and every major browser vendor supports TLS. Yet Rescorla is not at all satisfied with the level of adoption.
The vast majority of web traffic (90 percent or more) is not encrypted. Only approximately one percent of sites offer secure http (https). “That number should be 100 percent, but the hassle of getting https running on a site has driven people away from it,” Rescorla said. He explained that even for the IETF.org site it was impossible to get a certificate working in 48 hours. “If a man with a Ph.D. can’t do this, who can?” he asked. Especially for noncommercial offerings, the cost-benefit analysis can result in deciding against making the effort.
Aside from the complexity of the technology, when https was introduced it sat beside http. At the time, there was a risk that mixed content allowed downgrade attacks leveraging the unfamiliarity of users with https. When users, for example, typed the familiar http string into their browsers and a man-in-the-middle blocked the redirect to https, both partners—user and site—thought everything was all right, when in fact it was not.
Looking toward potentially useful alternatives, Rescorla pointed to having certificates stored in the DNS. This work is being done in the IETF DANE WG. Still, Rescorla advised that existing practices and standards would be here for a long time. Shedding legacy technology is slow and difficult, he explained, as any server that wants to have TLS must possess both credentials—the alternative solution doesn’t offer adopters any quick benefits.
Certificate Mess
Both Rescorla and the Mozilla Foundation’s Tom Lowenthal bemoaned the problems of a fragmented and confusing certification market. According to Lowenthal, fixing cryptography is not the problem; fixing implementation is. Major mistakes, Lowenthal said, are that of the roughly 1,500 certificate authorities many, if not a majority, routinely sign things that are wrong. They issue certificates for names that do not exist (or cannot exist), or for names that are unqualified domain names, such as .mars domains.
Moreover, certificate providers often reside in different regions with different legal or cultural norms. For some, Lowenthal said, it has been okay to intercept secured traffic; in general the whole technology just had that “one little dependency in the middle” that made it completely imperfect in some way. Lowenthal pointed out that he had no real solution for dealing with the problem. Currently, Mozilla is working on an alternative solution for web authentication. For its browser ID concept, Mozilla tries to exclude a middleman, similar to the web ID provider from the architecture.
How to Protect Existing Applications from Security Problems Created by your New App
Web Sockets coauthor Ian Fette, developer at Google for Chrome, reported how engineers tried to fix three kinds of problems detected during the development of web sockets: breach of established security boundaries, cross-protocol attacks, and interoperability issues. To protect (sometimes undocumented) security boundaries, for example between the open and the corporate network sitting behind a firewall, the web socket WG added an “origin header” (RFC 6454: The Web Origin Concept) that allows a check before accepting packets from across the security border.
An additional challenge-response established by the web socket client should help avoid cross protocol attacks. “The web-socket client,” Fette explained, “would send a key that gets hashed and that signals acceptance of the connection response.” Fette also pointed out that despite these measures, many servers passed on requests.
Fette drew several conclusions from the web-socket experience, mainly that developers were “deploying into an environment that had existing security assumptions.” Therefore developers need to protect the existing infrastructures against new attacks enabled by the new protocol.
Transition to Greener, More Secure Fields?
Chris Weber from Casaba Security described what developers were up to in their attempt to secure Web communication. “You pretty much have to be a rocket scientist to get it right these days,” he said. Cryptography, for example, exists on different levels: the transport level, the session level, and the application level.
As Weber explained, if developers miss one tiny thing in complex environments, it can compromise the entire operation. What causes difficulty between the life of a developer and the life of a security evangelist is that all browsers have tiny differences, even in the application of existing standards. “Chrome, Firefox, Internet Explorer, each one implements things a little differently, especially things like URL handling and the way URLs are parsed, the way post messages might be treated or XML is treated,” said Weber. “In addition, implementers are not delving as much into new standards as developers might hope. Therefore, it could create pain and vulnerabilities.”
Despite all the warnings and all of the problems, PayPal’s Jeff Hodges said the [Internet] world was better off today than it was a few years ago—due mainly to the rise of a multivendor market against an earlier monopoly market that saw a lot of proprietary development. Thanks to the multivendor efforts and the convergence on open standards, many more eyes are looking at the problems, said Hodges. He also spoke about transition, yet underscored that he saw “attack surfaces arguably shrinking.”
World IPv6 Launch, New TLDs, and a New RFC Editor
During the Technical Plenary, ISOC chief Internet technology officer Leslie Daigle described World IPv6 Launch on 6 June, in which participants will make their services available over IPv6 and keep them enabled permanently. “This time it’s for real,” said Daigle, quoting the Launch’s motto.
Newly appointed RFC editor Heather Flanagan provided participants with a look at future work.
With regard to ongoing IAB activities, there was discussion about the recent IAB statement on new generic TLDs and IDN TLDs. According to the IAB, an update of relevant RFCs is needed.