2008-08-04
SSL does not create trust
One of the stories that people tell about SSL on the web is that proper, valid SSL certificates create trust (and thus do all sorts of good things, like facilitating Internet commerce). This is, how shall I say it, not actually true.
Here's how SSL certificates fail to create trust:
- simply having an SSL certificate doesn't mean you're especially
trustworthy, because anyone can get an SSL certificate.
- you might be able to trust an identity that's guaranteed by SSL,
except SSL's idea of an identity is wrong for the Internet.
(And even given that, certificate authorities have been fooled at least once for a high visibility case, and an unknown number of times for less visible people.)
- SSL solves the wrong problem. As lots of events demonstrate, the
vulnerable point is not the network or a sophisticated man in the
middle attack; the vulnerable point, and the most valuable place
to compromise, is the web server itself. And a web server having an
SSL certificate says nothing about how secure it is.
(The other valuable thing to compromise is the person sitting in front of the computer; hence phishing attacks.)
- finally, and hugely, SSL creates no trust because it creates no legal basis for trust for anyone. There are no contracts with terms, no duty, no guarantees, no liability, no nothing. You pay some money and you get some magic bits, and that is it. No one is on the hook if something goes wrong.
Trust is created by people having a motivation to act in your interest. One of the ways that this can happen is that you pay them; another is that they pay you if something goes wrong (ie, liability). SSL involves neither, and as a result the presence of an SSL certificate means nothing more than that someone got an SSL certificate.
(Yes, trust can be created by reputation, but since anyone can get SSL certificates having a valid one says nothing about your reputation.)
Another way to look at this is to ask if there is anything that you can rely on, either practically or legally, if you see a proper SSL certificate. The answer is clearly no, for the reasons above; you have no legal reliance at all, you have no real assurance of who the website is, and you have no idea if the website is (still) secure even if they are a trustworthy business.
The conclusion is inescapable: in both practical and legal terms, SSL creates no trust at all. Any 'trust' it creates is both misplaced and entirely in the minds of users.
(It is hopefully obvious why misleading users about security issues is a very bad idea.)
(None of this is original to me, but I feel like writing it down in one place that I can point to. See here and the link in the comment here for some sources I learned from.)
Our answer to the ZFS SAN failover problem
A while back I wrote about the ZFS SAN failover problem, and recently a commentator asked what we've decided to do about it. Our current answer to the problem is simple but somewhat brutal: we're not going to do failover as such.
We're still including basic support for failover in our NFS server environment, things like virtual fileserver IPs and a naming convention for ZFS pools that includes what fileserver they are part of, but we're not trying to build any explicit failover support, especially automatic failover. If we have to fail over a fileserver, it will be a by-hand process.
Note that ZFS makes by-hand failover for NFS servers not very much
work because almost everything you need is already remembered by the
pools. All we'd need to do is get a list of the pools on the down
fileserver (made easy by the naming convention and 'zpool import'),
import them all on another server, and add the virtual fileserver IP as
an alias on the new server.
Apart from the relative ease of doing manual failover if we have to, there are several mitigating factors that make this more sensible than it looks. First, it seems clear that we can't do automatic failover, because it is just too dangerous if anything goes wrong (and we don't trust ourselves to build a system that guarantees nothing will ever go wrong). This means that we are not losing much by not automating some of the by-hand work, and an after-hours problem won't get fixed any slower this way; in either case it has to wait for sysadmins to come in.
Second, given the slow speed of zpool import in a SAN environment,
any failover is a very slow process (we're looking at tens of
minutes). Since even automatic failover would be very user visible,
having manual failover be more user visible is not necessarily a huge
step worse. This also means that the only time any sort of failover
makes sense is when a server has failed entirely.
Third, we're using generic hardware with mirrored, easily swapped system disks. This means that if even a single system disk has survived, we can transplant it into a spare chassis and (with a bit of work) bring the actual server back online; it might even be faster than failing over the fileserver. So to entirely lose a server, we have to lose both system disks at once, which we hope is a very rare event.
(This is when operating system bugs and sysadmin mistake come into the picture, of course.)