| < December 2008 | Matthew Loar > Blog | February 2009 > |
Yay 23.
Interestingly enough after my ramblings on PGP and authentication yesterday, the House decided that my birthday should coincide with National Data Privacy Day.
As seen on IRC:
14:50 <@mloar> apparently my birthday will coincide with "National Data Privacy Day" this year 14:50 <@benley> you should have a gpg keysigning party. 14:50 <@mloar> haha 14:50 <@benley> with gin. 14:50 <@mloar> even better
I was looking at the OpenSSH code the other day and I saw some code related to retrieving fingerprints from DNS. I had never heard of this, and I wondered how that could be secure.
Reading RFC 4255, the answer to that was simple: DNSSEC. This really makes a lot of sense: if you're trusting DNSSEC to guarantee the integrity of the value of the A record providing you the IP address to connect to, why not trust it for the encryption key to expect when you connect? This is actually quite nice, since DNSSEC protects you against DNS spoofing but doesn't protect you against IP spoofing.
Of course, there's no reason it has to stop with SSH. It turns out that there is a CERT RR defined in RFC 2238 which is designed for storing X.509 or PGP certificates in DNS. This is particularly interesting given the way that the trust chain for X.509 certificates for HTTPS currently works. The only guarantee you are connecting to the real HTTP server for www.amazon.com and not one run by an attacker is trusting that none of the Certificate Authorities that your browser trusts would issue a certificate for www.amazon.com to anyone other than Amazon.com, Inc. And for the vast majority of users, the CAs their browser trusts are the ones that their browser or operating system vendor saw fit to include, which is generally a very long list of CAs run by private companies whose rationale for why you can trust them seems to range from "we charge money" to "we charge obscene amounts of money."
However, if it were possible to securely publish SSL certificates in DNS, the need for these shady authorities would be eliminated. And in turn, not needing to shell out money for SSL certificates would hopefully lead to greater proliferation of SSL for general web browsing, not simply for things like order forms and online banking. The true beauty is that this is backward-compatible - there is no reason why you couldn't obtain a certificate from a CA and publish it in DNS. CAs might even continue to serve a purpose for those who want to go to the hassle of getting an Extended Validation certificate.
Likewise, the CERT record could be used for storing public keys for signing and encryption of email. It would be much simpler for someone wishing to send you an encrypted message to find your key if it were published in DNS, as they would not have to determine which keyserver your key was on and whether it was in fact your key. Having such a key in DNS would also make verification of signed messages easier for tools such as SpamAssassin or even MTAs. Greater proliferation of signed email could help in the neverending battle against spam.
Keys stored in such a manner could also be used to solve the longstanding problem of having to remember passwords for the myriad websites you visit. Many websites already use email addresses as usernames. In a future world, this email address might be used to look up a public key, which could be used for a challenge-response authentication. Though there's no reason sites couldn't ask for a PGP public key instead of a password when creating an account today - the main problem is that there is no protocol I know of for doing web authentication using PGP keys - instead browsers support SSL client authentication, which appears to me to be very unwieldy and I have never personally seen it used.
And I think that about sums it up - there are several separate public-key
cryptography systems that serve overlapping purposes: X.509 certificates, PGP
keys, and SSH keys. Each has a different trust model. But imagine if hosts
and users on the internet were able to authenticate themselves to each other
based on a single trust apex at the DNS root. Maybe this is all
pie-in-the-sky, but I have to hope that the future will bring resolution of the
awful mess we have now.
And you thought The Fourth Protocol was long and boring.
Upon further testing of my GSSAPI key exchange support, I discovered that if one's GSSAPI credentials have expired when a rekey occurs, another key exchange method will be chosen, which will result in a verification dialog if the key is unknown. Since the main imputus behind GSSAPI key exchange is to not need to collect host keys a priori, this is a problem.
A closer reading of RFC 4462 revealed that this is the purpose behind the SSH2_MSG_KEXGSS_HOSTKEY message. In particular:
In order to facilitate key re-exchange after the user's GSS-API credentials have expired, client implementations SHOULD store host keys received via SSH_MSG_KEXGSS_HOSTKEY for the duration of the session, even when such keys are not stored for long-term use.
So I have done just that, and pulled in the latest changes from upstream as well. Unfortunately, Simon Wilkinson's patch for the OpenSSH server does not send this message, so this won't help when connecting to OpenSSH servers. I intend to work on that (patch his patch?), but in the meantime I tested against Sun SSH, which does send the HOSTKEY message.
It looks like I also should implement the "Null Host Key Algorithm" support to be fully compliant, but I have not yet done so.
You can find the source and MSI on the PuTTY page.
I heard a strange noise a little while ago, and it took me a while to figure out what it was:
How in the world did it freeze in the refrigerator? I can only guess that it is because it was sitting under the vent, as the bottle next to it is still liquid. The sad thing is I don't even like Perrier. I only have it because Safeway.com was giving it away as a promotion. It has been in there for like a year.
Anyway, I'm finally back to a sane sleep schedule and I'm not going to ruin it
for this. Those green glass shards can wait for morning.
My method of choice? Rewriting managed code projects in C++.
I've been doing that for a couple of things, namely Neztu and most recently bloog. The former actually makes sense, since I have blogged before about my issues with Mono. My most significant qualm about it is its lack of support for fully precompiled sites, which means your clients get wonderful 5-10 second delays when it decides it needs to recompile something. I had been under the impression that writing a web application in C++ would be an exercise in pain and suffering, but it turns out that when you combine cgicc with the absolutely excellent pqxx, you get a (relatively) rapid development platform, and combined with the magic of FastCGI you get the performance and stability that is sorely lacking on so many sites these days. I have my new C++ Neztu in a very functional state, but I wanted to implement all of the features of my 0.1 release before I make a formal release. In the meantime, you can look at the hg repo, under the neztu-cxx branch. I have also decided to drop the liquidsoap support. It seemed cool at the time, but forcing two tracks into a "not queued but not playing" state is kind of a dealbreaker, and the methods of interacting with the rest of Neztu were kludgey at best.
My other project was pretty stupid, as other than being managed code, there wasn't anything terribly wrong with bloog. But my philosophy is that if I enjoy it, it's not really wasting time. Which is good, because thanks to wmwork I can tell you that I spent 15 hours rewriting it in C++. The two main benefits were that I discovered the original bloog had some bugs in date parsing that meant it didn't handle timezones correctly (all my latest entries are timestamped in UTC, but older ones need adjustment). Also, even my get-it-done sloppy unperformant C++ is 22% faster than the Boo version. Like the original Boo version, I don't intend to make any formal release of this code, both because it's hardly production quality and because I seriously doubt its usefulness to anyone else, but it is in Mercurial.
| < December 2008 | Matthew Loar > Blog | February 2009 > |