web/SSLNoTrust written at 23:10:20; Add Comment
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:
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.)
solaris/OurZFSSanFailoverAnswer written at 15:05:57; Add Comment
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 '
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
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.)
* * *
Atom feeds are available; see the bottom of most pages.