LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityEFF analyzes SSL certificates and certificate authoritiesThe Electronic Frontier Foundation (EFF) undertook a lengthy study of the web's publicly-visible SSL certificates earlier this year, logging the certificates and analyzing their makeup. EFF's Senior Staff Technologist Peter Eckersley and iSEC Partners' Jesse Burns presented the project at DEFCON 18, paying particular attention to what the data reveals about SSL certificate authorities (CAs), which are the entities that sign SSL certificates and are the basis of the trust that web browsers place on certificates. As one might suspect, there are potential vulnerabilities discovered "in the wild" encompassing everything from cryptographically weak certificates to CAs that employ troublesome signing behavior. The dataOver a period of three months, the SSL Observatory project collected SSL certificate data from around the Internet. The process began by scanning with Nmap for hosts that were listening on port 443 and logging the results. A Python client then initiated an SSL connection handshake with each host, dropping the connection before the key exchange, but saving the certificate and other data for later analysis. The certificates then needed to be parsed, which is not a trivial task due to the many quirks, options, extensions, missing fields, and other oddities found in real-world certificates. The certificate data was then stored in a MySQL database, that the team could query to examine particular facets of the certificates or the CAs themselves. The Observatory collected more than 4.3 million certificates, but for analysis purposes pared the list down to only those certificates that could be verified by a browser as valid (based on CA signature, date, key usage, and other attributes), and removed duplicates. That process left 1,377,067 individual certificates. The individual certificates were then mined for CA trust attributes. SSL uses the X.509 standard, in which each "leaf" certificate can be authenticated by a signature from a trusted CA. The browser retrieves the CA certificate, verifies that the CA's public key created the signature found on the leaf, and verifies the CA certificate itself by checking its signatures by higher-authority CAs, following such a path all the way back to a "root" CA. Browsers and operating systems come with a predefined list of trusted root CAs. The DEFCON slides note that Mozilla browsers recognize 124 trust roots, and Microsoft lists 19 in Windows — although the Windows list can be updated, silently, on demand. The reason for the large size discrepancy between the two sets is not explained; Mozilla makes its list public, however, and Microsoft periodically publishes a PDF list of trusted "root certificate program members" on its support site. Combined, those two sources of CA trust construct a graph of 1482 total CAs (including roots and subordinates), which was found by the SSL Observatory data to come from 651 distinct organizations when corporate ownership relationships are accounted for. AnalysisThe invalid certificates are a security problem in their own right (such as phishing sites masquerading as well-known organizations, or using mobile network operators operating WAP gateways with wildcard certificates), but the Observatory project was more interested in exploring the makeup of the valid certificates. The web of trust created by the CA model is taken for granted by most users, and developers, so problems with the valid certificates constitute a potentially more damaging security risk. The first peculiarity found in the certificate data is that a handful of certificates account for a startlingly high percentage of the Internet's signed leaf certificates. Of the 1,377,067 valid certificates, 300,224 of them were signed by a single CA certificate from web hosting company GoDaddy. Another 244,185 were signed by one certificate from Equifax. 89,216 were signed by a Thawte certificate that lacks a Subject Key Identifier (i.e. SKID, a required element that browsers are supposed to use to match the signing key's ID against the key ID found in the signatures on signed certificates), and 85,440 by a single Comodo certificate. Together, these four CA certificates account for signatures on 52.2% of all valid SSL certificates. The data also revealed a large number of unused certificates and valid CA certificates that share the same public signing key — situations that may be acceptable, but also entail risks. Unused CA certificates, for example, may be made available as a "safety switch" for the CA, allowing it to revoke a compromised certificate and switch to another one that is already known to the world's browsers. There are also situations where it makes sense for multiple CAs to share the same signing key, such as in the case of corporate mergers or acquisitions, where the CAs become legally one entity but continue to use their original issuer identities in business. But these situations can also cause trouble for browsers, who should not, for example, retain certificates that are unused because the CA has ceased operations. The DEFCON talk also explains how a CA can use the same signing key to artificially extend the life of a signature by creating a second CA certificate identical to the original, but with a later expiration dates. The data set found 80 distinct keys used in more than one CA certificate. Practical concerns and vulnerabilitiesThere are also examples of CAs signing what should not be considered valid certificates, such as RFC1918-reserved IP addresses or unqualified host names. There are, for example, more than 6000 certificates validated by trusted CAs for "localhost." Other problem areas include countries that do not use their own national CA for signing government web sites, certificates that feature conflicting settings (e.g., a certificate that indicates the subject is not a CA, but whose key advertises that it is a CA), and certificates with weak public keys. The presentation identified at least two trusted leaf certificates that use 508-bit RSA keys, signed by Equifax and Thawte. A more serious problem is certificates that use keys generated by the vulnerable OpenSSL package included in Debian between 2006 and 2008. SSL Observatory cataloged around 28,000 vulnerable certificates, although only 500 are still valid today. Eckersley said that EFF is working with the sites found to fix the vulnerability before it releases the SSL Observatory data set for public consumption. Aside from the issue of sites still relying on such vulnerable certificates, however, the analysis also found that some CAs still have not issued revocations of the vulnerable certificates that they themselves signed. Finally, the Observatory team generated a "CA map" connecting the trust relationships between the various root CAs and the subordinate CAs found in the data set. A PDF version of the map is available on the SSL Observatory site. Analysis of that graph, the team noted, reveals some potential problems, including the large number of subordinate-of-subordinate CAs, and important entities that are subordinate CAs — such as Google and the US Department of Homeland Security. There are only 46 countries that have valid root CAs, and there are some surprising absences, such as the Russian Federation and the United Arab Emirates. The precise risks of a large or important entity not operating its own trust root are probably open for discussion. Surely in the national governments' cases, though, it is unwise to outsource the government's trust to a private third-party, especially a foreign one. Corporations with only a subordinate CA may be at risk to being "held up" by a company beyond their control. The future of CA trustThe DEFCON presentation closes by posing questions about the future of CA-based SSL. As the site puts it, "the security of HTTPS is only as strong as the practices of the least trustworthy/competent CA," so perhaps the security model needs to be revised, at least reducing complexity and cost. The project stops short of endorsing specific reforms, instead saying that it hopes the data it has collected so far will serve as a useful research tool for others, and foster more openness and accountability of CAs. Eckersley said that the full data set will be published on August 23, after the team has completed its work to privately discuss the insecure certificates it uncovered. Mozilla's Johnathan Nightingale applauds the project on his blog, discussing the considerable effort the browser maker puts into maintaining its trusted root CA list, and hopes that the EFF will continue to collect certificates and update the data set on an ongoing basis. At the very least, this batch of work serves an important purpose, pulling back the curtain on a security layer the web depends on, but which rarely gets discussed. The concerns raised by the analysis thus far cover a wide range: some, like the 6000 "localhost" certificates, are bright red flags, but others are not so straightforward. Is there an attack vector that exploits the fact that more than 300,000 sites all rely on the same GoDaddy CA certificate? Perhaps not, but the mess that would be created if GoDaddy's signing key were to fall into nefarious hands tonight would be tremendous in scope, causing widespread confusion to the majority of the public when the registrar revokes the key and has to re-sign all of its customers' certificates. The CA-based SSL certificate system has been the target of usability work at Mozilla for quite some time — such as the introduction of "Larry the Passport Officer" in Firefox 3. But there is still a long way to go before the average user will be well-informed about all of the potential risks. X.509 certificates themselves may be more complicated than the average layperson wants to understand, so high-level analysis like SSL Observatory's helps simply by shedding light on the potential problems.
Brief items Security quotes of the week
Q: What could such a worm do on my phone?
-- F-Secure's
FAQ on the JailbreakMe iPhone vulnerabilities
A: Anything. It could do anything you can do on your phone, and more. So it could destroy or steal all of your data. Track your location. Spam your friends. Listen to your phone calls. Dial the presidents of every country in the world. Anything. And you would pay for all the charges it would create, too.
It's also clear that users should have different rights with respect to
each data type. We should be allowed to export, change, and delete
disclosed data, even if the social networking sites don't want us to. It's
less clear what rights we have for entrusted data -- and far less clear for
incidental data. If you post pictures from a party with me in them, can I
demand you remove those pictures -- or at least blur out my face?
-- Bruce
Schneier in "A Revised Taxonomy of Social Networking Data"
The EFF SSL ObservatoryThe EFF has put up a new page for a project which it calls the SSL observatory. They have spent months collecting information about SSL certificates across the net; as one might expect, they have found some interesting things. Those results are really only available as a set of slides [PDF] for now, but it's worth a look. It seems there are over 6,000 valid certificates out there for "localhost"...
Weekend Project: Secure Instant Messaging with Off The Record (Linux.com)Linux.com has an article by Nathan Willis about Off The Record (OTR). "Instant messaging, just like email or VoIP traffic, needs to be secure from eavesdroppers, man-in-the-middle attackers, and other security threats. Many IM clients can tunnel messages over transport layer security (TLS) to provide encryption, including XMPP (a.k.a. Jabber), IRC, and the OSCAR protocol used by AIM. TLS provides authentication and encryption at a low level, but a considerably secure solution for IM is a protocol called Off The Record (OTR). Pull up a chair and secure your instant messaging today."
New vulnerabilities base-files: arbitrary code execution
dbus-glib: denial of service
freetype: arbitrary code execution
git: arbitrary code execution
kernel: multiple vulnerabilities
kernel: denial of service
openconnect: man-in-the-middle attack
php5: denial of service
socat: arbitrary code execution
strongswan: code execution
wget: code execution
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||