27 March 2011

Comodo "SSL certificate" incident and what it means for you

For those of you who missed all the news coverage, here's a quick (and hopefully straightforward) explanation of the issue.

What is this?


Executive summary: The way secure communications is handled on the internet is broken, and a recent attack higlighted that. People running the latest version of their browsers are protected.

Whenever you visit a web site, your're either accessing that site through HTTP, the Hypertext Transfer Protocol, or via HTTP inside TLS (Transport Layer Security), aka HTTPS.

With HTTP, anything you do can be watched, recorded, etc by any entity between you and the site you are trying to visit. These entities include your ISP, various internet providers your ISP has peering agreements with, or anybody who is on the same Wifi (or sometimes wired) connection as you.

HTTPS encrypts your traffic to prevent such "man in the middle" attacks. Because the entire connection is private, it can be harder for organizations to filter out specific HTTPS sites.

My personal website is available via HTTPS, and your browser accepts that it is connecting to me and not an impostor because GeoTrust / RapidSSL checked the domain records to find my contact information, and called me up to make sure I am who I say I am.

To ensure that when you connect to a site, you are actually connecting to that site and not a malicious attacker, your web browser relies on Certificate Authorities, which vouch for a site's identity. Any CA can vouch for any domain, and there are almost 50 such entities which Mozilla Firefox fully trusts. Microsoft trusts hundreds, including a variety of governments ranging from France to South Korea to  Hong Kong.

What happened?


Recently one of these CAs, Comodo, was compromised, insofar as somebody was able to get a signed certificate for a domain they did not own. From what I understand, the attacker gained control of a reseller account at Comodo, and there were inadequate checks to prevent the now compromised account from issuing fraudulent certificates.

In this case, they were able to obtain certificates for the log in pages of Google, Yahoo, Windows Live, and Skype, as well as the Mozilla Addons site. Full details are in their incident report. Based on their initial analysis, the attack appears to be sourced from within Iran, and Comodo has concluded that the breach was orchestrated by the state.

Since Comodo's certificates are trusted by all major browsers, these sites can be impersonated by others, even though none of the targeted sites used Comodo.

Why should I care?


The Iranian government or another organization controlling those certificates can intercept usernames and passwords, and access private information. This is of primary concern to Iranian dissidents, but could be used by the government there to target anybody they don't like, given the right circumstances.

What can I do about it?


Well, this breach has shown that the process for revoking a certificate is horribly broken, since most browsers do not check to see if a certificate is still valid. Fortunately, the major browser vendors (Mozilla, Google, and Microsoft) have all issued updates, so if you are running the most updated version of your browser (which you should be doing anyway!) then you are protected against this specific attack. ((Well, Apple hasn't as of this writing, but you can work around it via this  method))

However, the incident shines light on the wider issue of the way our internet trust model works: allowing hundreds of unrelated organizations to vouch authoritatively that somebody else is who they say they are. This is a hard problem in information security to solve, and most of the proposed alternatives (cough DNSSEC) also suffer from having a trusted issuer. It will be interesting to see if any decentralized alternatives to CAs gain traction because of the Comodo affair.

01 March 2011

Trip to SCOTUS, Camreta v. Greene (09-1454) or: "Justices just want tohave fun"

I usually write about technical topics in this space, so pardon my digression. </metablogging>

Today my AP Gov't class took a trip to the Supreme Court of the United States (SCOTUS). We were fortunate to get reserved seating thanks to one of my classmates, so we skipped the line and were able to sit for an entire argument. We didn't get to choose which of the two arguments we saw, since half our group was randomly sent to each. I didn't get the one I had hoped for. Camreta v. Greene (the one I attended), however, proved to be much more entertaining than Schindler Elevator v. US ex rel. Kirk, at least based on the people I talked to. A quick search of the transcripts for each confirms this:
Argument    # of instances of "(Laughter)"
Camreta12
Schindler0

Facts of the case

The Huffington Post has a detailed overview of the circumstances surrounding the case, which didn't gloss over any details or strike me as overly biased; they certainly did a better job than I did. The whole story is rather sad, but what came before the court was this: whether a child can be questioned by the police, Child Protective Services, or other governmental agencies without parental consent, probable cause, or "extingent circumstances". If so, on what grounds can such questioning occur?

04 January 2011

Google Cr-48 first impressions

On a lark, I signed up for the pilot program of the Google Cr-48 about a week ago. To my surprise, I found the distinctive box on my doorstep a week later. After initially mistaking it for an overpacked, late-model OLPC XO-1 I would have to repair,  I sort of did a double-take as I realized what I had received.

Using Chrome OS




Wow, they weren't kidding about the boot time. Chrome OS responds (to suspend / resume and boot / power-off) very quickly.  Responsiveness elsewhere in the OS of course varies on system load and other factors. On the "terms" page, there is a "system security setting" which tells me I have a Trusted Platform Module, and that my TPM has a randomly generated password. The dialog could use some rewording; I'm pretty familiar with the idea of a TPM, but I'm still not sure what I'm to do with that information.

Cloud print is really a problem for me, right now. I use school printers for the majority of my work, which I was previously able to use by adding them by IP address. Unless there's some magic I'm missing here, I can't do that with Chrome OS, and such a feature will not be supported. (except by "connectors" on Windows and Mac computers)

General thoughts


I can't imagine using a system running Chrome OS as a primary computer. The biggest missing feature is PGP (or any sort of encryption) support for email. This is probably not terribly difficult to implement as an extension, but the idea of my cryptographic software being automatically updated is rather unsettling. I think I'll have to agree with Paul Buchheit that ChromeOS will have to merge with Android; there is a utility for local apps, even if they're becoming less and less critical.

08 December 2010

Simple two-factor authentication



Do you want to allow "Rebooting of Cluster 19" as Jane Doe, Foo Corp? Yes/NoI've been thinking a lot recently about information security and passwords. It's widely agreed that two-factor authentication, which combines something-you-know (a password) with something you have (eg. a smart card or some one-time-password) is superior to using a password by itself. Most solutions I've seen, short of client-side certificates, both require a trusted third party and provide little auditability.

I'm working on a project which attempts to address those problems. Basically, the idea is that you attempt to perform an action on a website, like logging in, moving some money between accounts, or restarting a cluster. Then, your mobile device ((iPhone used in the graphic to the right because a SVG was handy. Image adapted from work by Virgile Pypaert [CC-BY-SA-3.0], via Wikimedia Commons)) (Android, iPhone, or some custom hardware) starts buzzing, displaying the text of the action. When you approve or deny the action, your device uses a locally stored private key to sign the text of the approval and send it back to the server. The server checks that you approved the same transaction number and text, then allows the action. The server can store the approval notice to allow auditors later to determine that somebody in possession of the private key signed the action request.

So far, I've written a small Django server application, and a Python CLI device and client. They're not yet ready for a public release; I need to write up installation instructions and test it a bit more, but I'll publish them soon on Launchpad. On the usability side of things, I plan to conduct some trials in January comparing it to things like Google Authenticator.

This should be less susceptible to MITM attacks than one-time-passwords, since you can authenticate specific transactions, rather than entire sessions.

On the other hand, I'm no security researcher. Dear lazyweb, are there any problems with the above approach? Also, if I'm going to release this (as I plan to once I get something working), I need a name. Ideas?

11 October 2010

Key transition

As Christian mentioned, the Debian Keyring Maintainers did a "promote" this weekend of the new keyring. I figure it's an opportune time to perform a public key transition, since this had the effect of replacing my key on the keyring.

For my new key, 0xF9FDD506, I decided to opt for a 4096-bit RSA, which is stronger than I should have to worry about for the foreseeable future. The key is much better connected than my previous one, 0x0AC70206. I also have a transition document, ripped almost word-for-word from Christian's.

If you signed my previous key, you should sign the new one unless you're feeling extra paranoid today.

31 August 2010

Generating manpages with help2man

To quote the ftp-masters REJECT-FAQ :

  • Write manpages. Yes. Really. Write them. Well. It's basically: If your program/tool has a help and version commandline option you can simply run help2man and have a working start.


What may not be obvious to the recently REJECTed developer is actually how to use help2man. To try t0 explain the process a bit more verbosely, I took the liberty of writing a tutorial on the Debian wiki. Comments and corrections are welcome.


Of course, help2man-generated manpages are no substitute for real, hand-written manpages made of sweat, blood, and the Maintainer's tears, and it won't work for all packages. This is just a start, and is much better than no manpages at all.


There was a discussion on #debian-devel a couple of days ago when I brought up my creation of the above, and some wondered if it wouldn't be better to add hooks to man-db to allow package maintainers to enable manpage generation at runtime. I'm not sure if that idea will ever make it into a proposal, but, if the details of the implementation were worked out, would be much better than the above, manually generated method.

25 June 2010

Hello, (Planet Debian readers of the) world!

I'm a Debian Maintainer currently undergoing the New Maintainer process. I'm also an Ubuntu MOTU as of recently. I have several packages in a variety of categories, but I specialize in Python-based software.

I'm interested in exploring more ways to improve cross-distribution coordination, specifically as it relates to the Debian Sugar packages. I'm working to get all of the Ubuntu-specific Sugar packages included in Debian, which will probably be a summer-long effort.