LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityTrust, but verifyPublic-key cryptography has been an enormous boon for securing internet communication, but it suffers from a difficult-to-solve problem: authentication and key management. When presented with a public key over an insecure channel—as part of setting up a secure channel for example—how does one determine that the public key belongs to the entity that it purports to? There are several ways to solve that problem, but none are completely satisfactory. The Monkeysphere project seeks to turn the currently used system on its head, to some extent, and entrust users, rather than centralized authorities, with the power to bestow trust on a key. There are three main ways for a key to be "trusted": the key (or its fingerprint) is transferred via some secure channel (by phone or in person for example), the key is signed by an authority which has been entrusted to only sign valid keys, or the key is signed by "enough" different entities that are fully or partially trusted (i.e. a web of trust). Most of today's secure internet communications use SSL/TLS which requires keys that have been signed by certificate authorities (CAs), which are "trusted" authorities. There are two smaller subsets of secure communication, mostly only used by computer-savvy folks, that use other means for determining trust: SSH for interactive encrypted communication and PGP for encrypted email. SSH relies on key fingerprints being exchanged securely, at least in theory, while PGP relies on a web of trust. Monkeysphere's first project is to move the PGP web of trust into the SSH world. A web of trust is a decentralized, user-controlled key management scheme whereby keys are signed by multiple entities, each using its own keys. The signature can be verified based on the public key of the signer and the user can decide which signers are to be trusted—and at what level to trust them. In practice, if Adam signs Bonnie's key, and Clarisse trusts Adam, that means that Clarisse can trust Bonnie's key. Whether Clarisse should trust David's key, which is signed by Bonnie, depends to a large extent on how much she trusts Adam. Key signing only implies that the signer verified the identity of the key holder, i.e. that the key holder is the same person or organization that is identified in the key. It is not necessarily an indication that the key holder should be trusted in a general sense, only that the key holder is who they say (via the key) they are. The web of trust used by the Monkeysphere OpenSSH framework is based on the GNU Privacy Guard (GnuPG or GPG) implementation of the OpenPGP standard (RFC 4880). There are levels of trust that a user can place on a particular signer privately in the user's GPG configuration. They can also issue a trust signature that specifies publicly what trust level they have for a particular signer. So, from the example above, if Adam has published a trust signature for Bonnie saying that she is fully trusted by him, and Clarisse fully trusts Adam (publicly or privately), she is likely to trust David's key. The number of signatures and trust levels required to fully trust a key are configurable by the user, allowing users to decide what their trust parameters are. What Monkeysphere has done is to add some Perl around OpenSSH to manage keys, along with the known_hosts and authorized_keys files which normally live in the ~/.ssh directory. No modification to the OpenSSH client or server is required, though using Monkeysphere requires that all outbound connections go through the "monkeysphere ssh-proxycommand" command. On the server side, OpenSSH needs to be configured to use an alternate, Monkeysphere-managed AuthorizedKeysFile. The documentation page outlines the configuration needed for OpenSSH and GPG on the client or server sides. For SSH, especially for sites with lots of hosts, it means that users or system administrators don't have to laboriously propagate keys into authorized_keys files on each new system. Instead, they can say that any key signed by their organization's key is trusted. Each user then has their key signed and can log in to any machine. Of course, ensuring that the organizational keys don't get lost, or fall into the wrong hands, is imperative. While it is much more user-centric than a trusted authority mechanism, and does not require a separate secure channel for fingerprint exchange, a web of trust is no panacea. There are still issues with handling key revocations, especially if the user loses their key. A bigger problem may be getting a large enough web of trust, with enough trusted key signers, built such that users' keys, especially new users' keys, have a reasonable shot at being accepted. The very user-centrism that makes a web of trust so intriguing to those who care about secure communications may in fact be one of its biggest downfalls. Non-technical users have shown very little inclination towards wanting any control over which keys they accept or decline. Someone faced with trying to decide who to trust, and at what level, along with how many different signatures/types they require is likely to throw up their hands in frustration. Non-technical users typically don't use SSH or encrypted email, but they may use other services, like SSL/TLS encrypted web traffic that might also benefit from a web of trust model. LWN commenter dkg pointed to Monkeysphere (or similar techniques) as a possible solution for the problem of blindly trusting whatever CA root certificates a browser installs: "The more communications security is in the hands of the end users, with tools that are intelligible to end users, the more we can reject these abusive (or at least easily abused) centralized authorities." The italicized phrase is both the most important, and probably the hardest, part to get right. Tools like Monkeysphere, and efforts like those of CAcert, are good starting points. How well those can translate into workable, user-friendly, user-centric authentication and key management mechanisms is an open question. While those of us who are technically inclined will be able to use a web of trust if desired, it would be nice one day if our parents, siblings, and others who aren't so technical could also stop relying on potentially corrupt organizations for their internet communication security. A web of trust may be a big step down that path.
Brief items Debian to start deploying DNSSECThe Debian system administrators (DSA) have announced that they will soon be deploying DNSSEC for selected Debian zones. "The plan is to introduce DNSSEC in several steps so that we can react to issues that arise without breaking everything at once. [...] We will start with serving signed debian.net and debian.com zones. Assuming nobody complains loudly enough the various reverse zones and finally the debian.org zone will follow. Once all our zones are signed we will publish our trust anchors in ISC's DLV Registry, again in stages. [...] The various child zones that are handled differently from our normal DNS infrastructure (mirror.debian.net, alioth, bugs, ftp, packages, security, volatile, www) will follow at a later date." (Thanks again to Paul Wise.)
Mark Cox: Red Hat's Top 11 Most Serious Flaw Types for 2009Red Hat's director of security response, Mark Cox, has posted some information about which security flaw types were most prevalent in the security fixes made by Red Hat in 2009. He compares those fixes with the Top 25 Most Dangerous Programming Errors that were just published by MITRE and the SANS Institute. "This quick review shows us that 2009 was the year of the kernel NULL pointer dereference flaw, as they could allow local untrusted users to gain privileges, and several public exploits to do just that were released. For Red Hat, interactions with SELinux prevented them being able to be easily mitigated, until the end of the year when we provided updates. Now, in 2010, the upstream Linux kernel and many vendors ship with protections to prevent kernel NULL pointers leading to privilege escalation."
New vulnerabilities ajaxterm: denial of service
fetchmail: arbitrary code execution
flash-plugin: information disclosure
fwbuilder: symlink attack
gnome-screensaver: lock bypass
kernel: several vulnerabilities
mod_security: multiple vulnerabilities
openoffice.org: buffer overflows
openoffice.org: multiple vulnerabilities
openoffice.org: insufficient macro security
otrs2: SQL injection vulnerability
postfix: insecure default configuration
ruby: arbitrary code execution
samba: read/write access on protected files
sun-java: arbitrary code execution
tomcat6: multiple vulnerabilities
webmin: cross-site scripting
Page editor: Jake Edge |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||