A crude system verification method
Suppose that you have a system that you are not entirely confidant of, and you want to look to see if bits of it have been modified from stock. The easiest way is to use your packaging system's verification support, but let us suppose that your package system doesn't have support for this (or at least that the support is optional and not installed at the moment).
If you happen to have another theoretically identical system lying
around (as we do), you can do a crude system verification with
rsync -n -a --delete -IOc root@hostA:/usr/ /usr/
Here hostA should be the machine that you want to verify, not the
machine that you want to verify it against. It also assumes that you
can do ssh root logins to hostA.
Some of these options are not obvious;
rsync ignore changed
directory times, while
rsync to always checksum
files to check to see if they're different, instead of trusting the size
and the timestamp.
(Package systems generally don't reset the directory modification time
when they update programs in a directory, so directories like
can naturally have different timestamps on different machines. Ignoring
them saves you from drowning in noise.)
This isn't likely to work on Linux machines that use prelinking, because prelinking can create different binaries even on machines with identical package sets.
Disclaimer: as a crude verification method, this should only be used if you are mostly confidant in the system to start with. If you are not, remember the zeroth law of compromised systems.
SSL's identity problem
One of the many problems of SSL, especially on the web, is that it gets its idea of identity wrong (in practice, in actual implementations). SSL's version of identity is all tied to abstruse X.509 things, all CN and O and OU and so on, but on the real Internet, users don't think of identity that way; they think of identity as websites, or more exactly of some personal label that they have for the entity that stands behind a website.
This matters because a great deal of SSL's claimed security is based on users understanding the identity of what they're talking to. If they don't, SSL cannot possibly create trust or protect against even moderately clever impersonation attacks, and indeed that is what we see all the time.
(For example, consider the various IDNA homograph attacks. If users actually used the SSL/X.509 idea of identity they would not be fooled in the least, but they don't; they look at the domain name, and the IDNA homograph attacks created lookalike domain names through Unicode tricks.)
Fortunately this is mostly a matter of how applications present SSL identity information, so it can be mostly solved in applications. Roughly speaking, we want to be able to tell users 'this website is the same people as www.microsoft.com' in some useful way. Given IDNA homograph attacks we can't tell the user literally this, but we can get around that by letting the user create tags for organizations and showing those tags as the 'this is part of' identity. (This is more useful for the user anyways.)
(Mechanically we can use the SSL certificate identity information to compare a new certificate's X.509 organizational information to a known certificate for the organization captured when the user made the tag.)
Note that you cannot let organizations assert tags for themselves in certificates, however convenient it would be, because then you are back to both IDNA homograph attacks and the 'we issued a certificate to Microsoft, but it wasn't the right Microsoft' problem.