SSL/x.509 certificate infrastructure

After working with x.509 (SSL) certificates a bit, I think some changes in the infrastructure are needed. It's become obvious to me that the major CAs aren't entirely secure, there've been too many compromises of them. In addition they make it too costly to truly use certificates effectively.

For client certificates, StartSSL has the right idea: charging based on the cost of the verification, not per certificate. They'll give you a free SSL client certificate for your e-mail address, because it's all automated and they don't really incur any significant costs above normal operation doing it. If you want a certificate where actual identity's verified by checking passport etc., you pay for the verification when it's done. After that you don't pay anything for getting certificates issued unless/until issuing one requires a new verification. This needs to be the norm for client certificates. In addition we need ways for an organization to issue certificates for it's members. Your employer, for instance, is a much better source of a client certificate tied to your position as an employee because they know for certain who their employees are while a CA doesn't. Ditto my bank: if they issue me a client certificate saying I have such-and-such an account with them, that certificate should be more acceptable to financial sites than a CA-issued one because my bank knows for certain that I've got that account with them and they've followed the required-by-law checks on my identity before giving me that account. And we need to move certificate generation/issuing into mail clients as well as browsers. It's not that hard since most mail clients these days use a browser component to display HTML e-mail and fetch remote content. That component can be used to go through the same process as a browser would. The critical thing is that private key generation is done on the client side and that private key can never exist on the server at any point.

Server certificates are where the real costs come in. It's prohibitively expensive to get server certificates, that's one of the reasons many places haven't gone to strong SSL. It's also difficult to determine from the certificate whether the server really belongs to the organization, because the CA issuing the certificates doesn't know which servers really belong to the organization. I'd much rather see CAs verifying the identity of the organization and giving out a signing certificate that let the organization issue it's own server certificates, with that signing certificate restricted so only certificates claiming the servers belong to that organization are valid. Then companies could issue certificates without worrying about how much it was going to cost. It'd also facilitate issuing client certificates for employees and system-to-system communication. It's not like actually issuing certificates is hard, you can set up Web pages to do it automatically without much trouble and the database to hold all the needed information is fairly trivial if you only need to handle your organization instead of every organization in the world the way CAs have to. Yes, most organizations won't employ the high-level security measures the CAs do to protect the signing keys. OTOH, each organization would be a much less lucrative target because a compromise would only affect one organization's certificates. Because of the way most organizations operate, it'd actually be harder to get at the signing certificates because most of the time they could be on a USB drive in the sysadmin's desk drawer and while physical access might be easy it requires the attacker to be physically at that location and most of them won't be on the same continent as their target.

The above would also make it easier to validate Web sites from the user's end. When I set up access to my bank's Web site, for instance, my browser would ask me to verify the organization issuing certificate. If I said it was OK, the browser would then tie that certificate to a human-readable name for the organization and tie the site I'd visited to that certificate. When I visit a site again, if the organization certificate matches what I have on file the browser lets me in. If the site isn't tied to an organization certificate, it'd prompt me to check the one the site presented and tell it what identity I wanted it tied to. If it was another of my bank's sites (or servers), I'd just tell it "This site belongs to my bank." and it'd make the connection. If the site and the organization certificate didn't match (eg. I thought I was visiting my bank's site but it's not using my bank's organization certificate) I can tell it "No match." and it'd block access. And if I had a match on file but it didn't match what the server was presenting, I'd get a similar prompt but with a stronger warning so I can correct an error if I really need to (eg. the bank's changed things around and I need to change my stuff to match) but it's really likely something malicious is going on and I need to be really sure before I accept it.

All of this would destroy the current business model for certificate authorities, their revenue comes from issuing individual certificates and these changes would mean CAs wouldn't be issuing more than a single certificate per organization instead of dozens to thousands. But there are other opportunities. PGP introduced the idea of "network of trust", where no single signature identified a key as truly belonging to a given individual and you evaluated how many signatures it had and how trustworthy each signature was when making the decision whether the key belonged to who it claimed to or not. The same thing could be done with certificates. I go and get a client certificate from StartSSL. Then when my employer wants to issue me a client certificate I can at the same time submit my own certificate and have my employer sign that as well. When I open a bank account, I can have my bank sign my client certificate as well as issuing me a bank one, leaving my client certificate with 3 signatures on it. Now, suppose my employer's compromised and their signing keys are stolen. My company-issued certificate's invalid, obviously, but my own certificate's still good because StartSSL's and my bank's signatures are still trusted. Same with StartSSL, if they're compromised my own client certificate's still OK because I've got 2 other signatures on it from uncompromised entities. As long as I have at least one uncompromised signature, I can avoid catastrophic failure. This applies to organization and server certificates too, and CAs could replace their revenue stream with one based on cross-certifying certificates so that single compromises wouldn't be fatal to a large number of certificates.

Future plans for Silverglass

I've got two general plans. One is to move a chunk of the site over to Google Sites as a short-term measure. XMission's done a good job of hosting the web site and e-mail, but I'm wanting to do things I can't do on their service. I want to run my own e-mail server, for instance, so I can provide service to a few friends. I want an external shell server, and I want a Web server I can set up to host other domains if I want to. I need my own host under my control for all that. The problem is I can't set all of that up overnight, so I need a temporary place to hold the web site while I sort out all the rest.

Long-term I want to set up CMS and website-editing software that'll let me do a lot more with the site without having to mess with editing HTML directly, and move the site completely onto my own server. Google Sites is nice for content, but I can't run custom back-end applications on it. I've got a few webapps I want to play with, and I need a server I can run them on. I may start by keeping the text portion on Google Sites and using my own server only for the webapps, but long term I want to be self-sufficient. The trick will be to find software that lets me create page templates and fill in just the content without limiting me to only doing that. Oh, and a model that lets me create/edit everything locally and publish to the site only when it's all correct is a must. Live editing of the site is a no-no.

URL shortener problem

If you use Twitter, you're probably familiar with the bit.ly URL shortener service. Even if you don't, you're probably familiar with TinyURL, bit.ly, vb.ly or other URL shortener services. They seem convenient. No more having to type or remember long URLs, just create a short one. No problem.

Until vb.ly went off the air. The domain was siezed by the Libyan registrar that controls the .ly hierarchy, because content at the locations pointed to by vb.ly violated Libyan morality laws.

This is why URL shorteners are a bad idea. They create URLs that are under the control of a third party and which can be disrupted at any time. Since there's no direct mention of where the shortened URL points, once disruption happens it's impossible to locate the original destination. If you use the actual full URL, disruption can only occur if the actual site referred to is taken off-line.

Note also that this is why you should make your own copy of content if you really care about having it available. If you merely link to it, it's vulnerable to the destination taking it down or just changing what it says. Only when you control the copy can you insure that it doesn't change or become unavailable in the future. This may annoy copyright holders, however I feel that if I'm writing commentary on what someone said then making a copy to insure I can prove they did in fact say what I claim they said falls under fair use, and making a complete copy is neccesary to show that I'm not merely cherry-picking and taking bits out of context to misrepresent what was actually said and so also falls under fair use.

DNS root zone is now signed

The DNS root zone is now signed via DNSSEC. The idea behind DNSSEC is that the owner of a zone (roughly a domain) generates a public key and their DNS servers will digitally sign the records they serve up. Intermediate DNS servers will preserve those signatures, allowing querying machines to determine whether the records have been altered from what the authoritative nameserver sent. This makes it a lot harder to do a man-in-the-middle attack against DNS, hijacking a caching nameserver (say one belonging to an ISP) in order to re-route traffic to an attacker's servers. Not impossible, but it's a lot more involved. That's because the public key needed to verify a signature is returned from the zone above the signed zone and is signed by that zone, eg. the public key for silverglass.org's records is returned from the .org zone's server and the key for the .org zone is returned by the root nameservers. So for an attacker to forge silverglass.org records, he has to subvert the entire chain back to the root. Each verifying machine has the single key for the root zone pre-loaded (and presumably verified out-of-band to make sure it's valid), so it's infeasible to fake signatures on records for the TLDs (eg. .com, .org, .us). If I can control the records returned for .org queries I can substitute my key for silverglass.org's, allowing me to forge signatures on silverglass.org records. But since I can't substitute my key for the root key I can't fake signatures of the .org records containing the silverglass.org key, and any verifying server will detect my forgery.

That's great for security, but it poses a problem for some (IMO unethical) ISPs and DNS providers like Network Solutions. That's because they've been playing a game: when someone asks for a domain that doesn't exist, instead of returning NXDOMAIN (non-existent domain) for the query they've returned a valid result for the name pointing at their servers which serve up advertising, search results and the like. Essentially they take ownership of every single invalid domain and slap their advertisements on it. But as soon as downstream DNS servers (eg. the ones in every home router) start verifying DNSSEC signatures, the gravy train ends because those ISPs and DNS providers have no way of forging valid signatures. The only exception is that the registry operator can forge results for completely unowned domains within it's scope, and the most common DNS software around has a flag to stop that (TLD servers are expected to only delegate to 2LD servers, they should never return actual results so any results they try to return must be faked and should be treated as NXDOMAIN).

Web fail

A challenge most Web designers today fail: design a generic Web page. It must display readably on a 24" widescreen LCD monitor at 1920x1200 resolution, and readably on the 320x200 pixel display of a Web-capable cel phone. It must not fail to render because the browser lacks Flash, or Java, or .Net or anything else not present in the basic browser installation. It must not fail to render because the user isn't running any particular browser.

For extra points, it must render readably on a 24" widescreen LCD monitor running in 640x480 16-color mode (user has failed their check vs. INT to set the correct monitor type and Windows has defaulted to a minimal known-good resolution).