Web Certificate Economics
In a comment on “Build Irony In,” “Frank Hecker writes:”
First, note that the “invalid certificate” message when connecting to
buildsecurityin.uscert.gov using Safari is *not* because the certificate is from
an unknown CA (or no CA at all); it’s because the certificate is issued to the
server/domain buildsecurityin.us-cert.gov (note the dash) and thus doesn’t match
the hostname you specified. So IMO at least this particular problem has less to
do with the presumption that “identity needs to be ‘rooted’ at a certificate
authority”; it’s more analogous to the SSH error you get when you connect to a
host and the public key presented is different from what is cached at your end
for that site.Second, regarding this notion that it’s “expensive to deploy cryptographic keys,
which should be cheap”: Usable SSL/TLS server certificates are now available for
as low as $15 to $30 per year, comparable to the cost of the corresponding
domain name; see for example LiteSSL.com and the TurboSSL offering from
GoDaddy.com. I think there are still significant barriers to SSL/TLS adoption,
most notably the problem with supporting the use of virtual hosts sharing a
single IP address, but I think cost per se is rapidly becoming a non-issue.
Frank is absolutely correct on the first point, that the issue is a dash missing.I’ll note that, four days later, its not fixed, and I’d like to take a swing at why that might be. I don’t think its an issue of how many dollars it costs, but it is an economic issue, driven by the policies embedded in web browsers.
[That issue is explained in detail after the break.]
[Update: News.com has an article on the same subject, “Browsers to get sturdier padlocks.”]
Creating a new key is trivially easy. It takes a few seconds to generate a new key. It takes a few seconds more to generate a signature to attach data to the key. The expense comes in organizational friction. Which is to say, if this were a simple edit to apache.conf, it would likely be done already. In many organizations, there are several groups involved in anything touching a certificate. There’s operations, security, QA. There’s tickets to be opened and managed. Maybe even a change management committee. More important than the internal issues is coordination with a CA. The fact that whatever comes out is going to cost money will slow internal processes. No one wants to spend $300 twice. (Mr. Hecker is correct, there are cheaper certificates available, but the site is using Verisign certificates.) So let’s examine what we get from the CA in this case.
Given that the end user sees no difference between a Verisign and a LiteSSL certificate, I’ll consider the cheap one. After all, it serves exactly the same purpose of making the dialog boxes go away. There should be no illusion that anyone is doing any form of due diligence for $15. There may be some automated checks which are done, and those may be getting in the way. For example, do the email domain and the certificate domain match? If not, then they need to figure out how to send mail from uscert.gov, which may require a change at the .gov registrar.
So, on the one hand, it’s cheap, and shouldn’t be a big deal. On the other hand, what security do we gain for the friction? Could we gain that security in other ways? Before we go on, I’ll comment that $15 for a certificate could also pay for 3 months of cheap hosting service, which is a non-trivial amount to add. The ability to publish inexpensively on the internet is a huge boon for the poor, and I’d like for them to be able to gain the security of self-signed certificates without scary browser dialog boxes coming up.
That lack of due diligence is why some people want to put higher assurance certificates in place. But that will make the inter-organizational friction even greater. Is there a competence that a firm focused on issuing certificates can use to gain an advantage over a firm doing it in house? The only competence I can see is that they’re going through the process defined by web browser creators.
Perhaps a side effect of higher assurance certificates will be that the lower assurance certificates will not be needed, and that users will be able to have a secure (encrypted, integrity protected) connection be transparent, even if no certificate chain is in place.
There are other models that I think deserve consideration, such as tying SSL keys to domain (DNS) keys, where the only thing ‘certified’ is that the domain is the domain.
If your $15 bought you a domain CA key that could sign keys for any subdomain you operate, we’d be better off. We’d be better off because lower inter-organizational friction would reduce the effort to fix the site. We’d be better off because fewer sites would be exposing their passwords in the clear. (Although this may well have more to do with efficiency issues with cryptography, and the number of optimizations that must be abandoned when it is used.
The photo is from MikeyMo on Flickr.