LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityTACK: TLS key pinning for everyoneMoxie Marlinspike and Trevor Perrin have created a TLS enhancement called Trust Assertions for Certificate Keys (TACK) that is designed to protect users against SSL certificate fraud with minimal overhead or infrastructure. The TACK proposal has been submitted to the IETF, as has a competing key-pinning mechanism created by Google's Chrome team. Although the two systems share broad similarities, their implementations are quite different. The troubleTACK is designed to combat flaws with the certificate authority (CA) trust chain model used by applications to check the validity of a remote site's TLS public key. The entire CA chain can be undermined by one bad CA, but there are other difficulties, too. First, any given hostname (e.g., www.example.net) can map to several different servers, with several certificate and thus several different CA chains deployed at once (e.g., in different jurisdictions) — which makes it harder to verify a connection. Second, the CA chain itself may change at any time, due to CA actions that are outside the control of the www.example.net site administrators. There have been plenty of previous approaches to circumventing CA problems (including Marlinspike's own Convergence). "Certificate pinning" is a client-side technique in which the browser remembers (or "pins") a known-good SSL certificate across multiple browser sessions, and alerts the user if the certificate suddenly seems to change. The TACK proposal argues that certificate pinning is flawed because it binds the trust not to the server's TLS key but to the certificate, which includes the key plus the CA's signature and various other metadata. Thus, by extension, pinning the entire certificate ties trust of the server's TLS key to trust of the CA. Google Chrome added a key-pinning feature (which tracks known-good TLS keys, even though it is often erroneously referred to as "certificate pinning") with Chrome 13 in mid-2011. But the TACK project says that this, too, has its flaws. First, Chrome's key-pinning uses a whitelist approach, with the browser designating specific CAs as trustworthy. But as long as the CA chain includes a whitelisted CA anywhere in the chain, the whole chain is trusted. Second, if a server issues a new TLS key, it does not roll out to users until a new version of Chrome is released. TACKIn TACK, the identity-verification mechanism is also key-pinning, but rather than pinning a CA key, the browser pins a special "TACK" data structure created and controlled independently by the web site's administrators. The TACK includes a cryptographic signature of the site's TLS key, plus a public encryption key that the browser can use to verify the signature. Obviously the TACK public key and the TLS public key need to be different. In addition to this basic identity information, the TACK also includes an expiration date and a "generation" counter that gets incremented every time the site administrator creates a new TACK (so that old TACKs can be revoked if necessary). The final piece of the puzzle is that TACK is an extension to TLS itself, rather than an extension to HTTP as in Google's pinning proposal. In practice, when the client application initiates a TLS connection, it requests a TACK from the server as part of the handshake step. When the server sends a TACK back in return, the client checks the generation information against its current cache for the site (if it has one), checks the expiration date, and validates the signature. If everything checks out, the TACK is "pinned" locally for future reference. The client can still choose to verify the CA chain or use other means to cross-check the identity of the server. When the client pins a TACK, it is supposed to assign a cache lifespan to it equal to the amount of time between when it first saw the TACK and the present — up to a maximum of 30 days. In other words, a TACK that was first encountered seven days ago gets pinned for another seven days, while a TACK from one year ago gets the 30-day maximum. In the maximum-lifespan case, however, the TACK will only remain in the local cache if the user has returned to the site at least once every 30 days; otherwise it will have expired on the 31st day and a new pin will be created. The big drawback of the TACK mechanism is that, like other client-side key-pinning methods, it does not protect the user against a man-in-the-middle (MITM) attack during the very first connection attempt to the remote server. It relies on the client having known-good information pinned locally. On the other hand, the TACK generation, cache lifespan, and expiration date features are intended to mitigate the damage that a MITM attack can inflict. The worst-case scenario is a bad pin that lingers for 30 days, which is half the time the rogue google.com certificate issued by DigiNotar lingered in 2011 — and it could have lasted much longer had it not been discovered. Another advantage of TACK's design is that in the worst-case scenario, the server administrator can single-handedly push out an update, rather waiting on the CA or another party. But TACK's developers also note that there is no reason that TACKs must only be retrieved "live" by the browser. Search engines could index well-known TACKs and browser-makers could pre-load lists of them into their applications. The TACK team has posted example TACK code for Apache and OpenSSL, plus a Python tool for making TACK requests. Google, pins, and the futureGoogle submitted its own key-pinning proposal to the IETF, based on an evolution of its original feature in Chrome. The Google proposal is similar in many ways to TACK. For starters, unlike the built-in pinning currently found in Chrome, it allows each client application to check and cache its own pins rather than depend on a vendor-supplied list. It also pins individual site keys rather than CA keys, so it is independent of the CA chain-of-trust. Google's pin format includes a max-age field, which takes the place both of TACK's expiration date and its maximum cache-lifespan criteria. Google's proposal does not track generations, however. To recover from a lost or stolen pin-signing key, it instead mandates that server administrators keep a "Backup Pin" — a second, un-deployed signing key that the administrators must store offline. The key fingerprint of the Backup Pin is published by the server, though, so that clients will recognize it if it needs to be deployed. Presumably when the Backup Pin is deployed, the administrators will then need to create a new, backup backup Pin. There are other details that differ between the proposals (such as what signature algorithms are required), but the most fundamental difference is that Google's pinning proposal is an extension to HTTP: servers send their pinnable key signatures in a new HTTP header, rather than as part of the TLS handshake. TACK's proponents argue that because the CA weakness is fundamentally a TLS problem, it should be fixed in TLS itself, and that building an HTTP-based solution leaves other important protocols (e.g., IMAP and POP3) unprotected. HTTP proponents argue that an HTTP solution is easier to deploy due to the difficulty of setting up a TLS stack, and that HTTP protects the most attack targets. As of today, TACK is being discussed by the IETF's TLS Working Group. It is a new enough proposal that it is likely to see revisions before it advances any further in the IETF standards process. Google's key pinning proposal was accepted as an Internet-Draft by the Web Security Working Group in December. Whichever makes it to broad browser and server acceptance first, it is fair to say that users will start hearing more about "pinning" in one form or another — but they still should not expect the CA system to disappear any time soon.
Brief items Security quotes of the week
This has been a public service announcement made necessary by some damn' fool European Commission directive that confused a goal (securing web users' privacy) with a technology (cookies). Film at eleven.
-- Charlie
Stross
Let's say you chose NOT to accept any cookies from bbc.com (most people are going to tend toward a binary decision -- all or none -- not try to micromanage their cookies). The result of blocking all BBC cookies will be that (apparently) you'll be forced to see this banner over and over and over ... and over again. How do you stop it? By accepting BBC cookies of course!
-- Lauren Weinstein
When I helped to develop the open standards that computers use to
communicate with one another across the Net, I hoped for but could not
predict how it would blossom and how much human ingenuity it would
unleash. What secret sauce powered its success? The Net prospered precisely
because governments — for the most part — allowed the Internet to grow
organically, with civil society, academia, private sector and voluntary
standards bodies collaborating on development, operation and governance.
-- Vint
Cerf worries about the future of the internet
Even though humans produce distributions with pitifully few bits of
security, I think passwords will always be with us. As one component in a
system with many layers, passwords can be valuable as a low-cost
authentication mechanism which nearly all people can do with no special
equipment. The important thing is to stop considering them the first and
last step in authentication.
-- Joseph Bonneau
These days I'd argue that multi-user is such a corner case that it's
not worth optimizing for it as far as defaults are concerned. If
you're trying to run a secure multi-user system, you need to be an
expert system administrator, keep up with all security patches, and
even then, good luck to you. (The reality is that these days, no
matter what OS you're talking about, shell == root. And that's
probably even true on the most unusably locked down SELinux system.)
-- Ted Ts'o
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica)Over at Ars Technica, Dan Goodin writes about Trust Assertions for Certificate Keys (TACK), a proposed extension to SSL/TLS designed to discover fake certificates before they are accepted. "The opt-in system works by allowing SSL sites to sign valid SSL certificates, the domain name, and an expiration date with a TACK key. Once an end user has visited the site a few times using a TACK-compatible browser, a 'pin' for that site is activated on the user's computer. If the end user later encounters a forged certificate for that same site—as was the case when DigiNotar was breached—the browser will reject the session and return a warning to the user." One of TACK's co-creators is Moxie Marlinspike, who proposed the Convergence alternative certificate-management framework in 2011.
Android Malware Genome Project launched (The H)The H covers the debut of the Android Malware Genome Project by researchers from North Carolina State University. The team "has already collected more than 1,200 samples of Android malware, including GingerMaster and DroidKungFu, and has organised them into various malware families. [Xuxian] Jiang told Dark Reading that 'the purpose is to engage the research community to better our understanding of mobile threats and develop effective solutions against them.'" Access to the data set, however, is restricted.
Implementing UEFI Secure Boot in FedoraOn his blog, Matthew Garrett writes about plans for supporting UEFI secure boot in Fedora 18. In it he covers signing the first-stage bootloader with a Microsoft key, while signing GRUB 2, the kernel, modules, etc. with a Fedora key. It is a compromise to try to avoid problems for users who want to boot Linux on Windows 8 hardware. "The last option wasn't hugely attractive, but is probably the least worst. Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access), but it's cheaper than any realistic alternative would have been. It ensures compatibility with as wide a range of hardware as possible and it avoids Fedora having any special privileges over other Linux distributions. If there are better options then we haven't found them. So, in all probability, this is the approach we'll take. Our first stage bootloader will be signed with a Microsoft key."
New vulnerabilities chromium: multiple vulnerabilities
cobbler: remote code execution
dokuwiki: cross-site scripting/request forgery
kernel: denial of service
kernel: privilege escalation
mailman: information disclosure
net-snmp: denial of service
pidgin: multiple vulnerabilities
python: insecure file creation
python-tornado: HTTP header injection
request-tracker3.8: multiple vulnerabilities
strongswan: authentication bypass
wireshark: denial of service
xinetd: service disclosure flaw
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||