14
with that public key. However, there is no mechanism to force further validation. As a result, man- in-the-middle attacks are often feasible.
First, developers must decide which Certification Authorities should be trusted, and must locate the certificates associated with each of those authorities. Thats more effort than most developers
are willing to exert. As a result, many applications using SSL are at the mercy of man-in-the- middle attacks.
Second, even those applications that install CA certificates and use them to validate server certificates often fail to perform adequate checking on the contents of the certificate. As a result,
such systems are susceptible to man-in-the-middle attacks in which the attacker gets his hands on credentials that will look legitimate to the client, such as a stolen set of credentials in which the
certificate is signed by the CA that has not yet appeared on any CRLs.
The best solution for thwarting this problem depends on the authentication needs of the client. Many applications can expect that they will only legitimately talk to a small set of servers. In such
a case, you can check appropriate fields in the certificate against a white list of valid server names. For example, you might allow any certificate signed by VeriSign in which the fully qualified
domain name mentioned in the certificate ends with yourcompany.com. Another option is to hardcode a list of known server certificates. However, this is a far more difficult solution to
manage if you ever wish to add servers.
Additionally, if you do not wish to trust the authentication mechanisms of the established CAs, you could consider running your own CA, which we discuss in
Chapter 3 of course, we are
assuming you control both the client and server code in such a situation. In environments where you expect that anyone can set up their own server, and thus managing DNS space or your own
Certification Authority is not feasible, then the best you can do is ensure that the DNS address for the server that the client tried to contact is the same as the one presented in the certificate. If that is
true, and the certificate was signed by a valid CA, everything should be fine if the certificate was not stolen or fraudulently obtained.
1.3.5 Poor Entropy
In the SSL protocol, both the client and the server need to generate random data for keys and other secrets. The data must be generated in such a way that a knowledgeable attacker cannot guess
anything about it. SSL implementations usually generate such data using a pseudorandom number generator
PRNG. PRNGs are deterministic algorithms that produce a series of random-looking numbers. Classical PRNGs are not suitable for use in security-critical situations. Instead, SSL
implementations use cryptographic PRNGs, which work in security-critical situations, as long as they are seeded properly.
A seed is a piece of data fed to the PRNG to get it going. Given a single, known seed at startup, the PRNG should produce a predictable set of outputs. That is, if you seed the PRNG and ask for
three random numbers, reseed with the same value, and then ask for three more random numbers, the first three numbers and the second three numbers should be identical.
The seed itself must be a random number, but it cant just be a cryptographically random number. It must be truly unguessable to keep the PRNG outputs unguessable. Entropy is a measurement of
how much unguessable information actually exists in data from the point of view of an attacker who might be able to make reasonable guesses about the state of the machine on which the
number is stored. If a single bit is just as likely to be a 0 as a 1, then it is one bit of entropy. If you have 128 bits of data, it can have up to 128 bits of entropy. However, it may have as little as 0 bits
of entropy—as would be the case if the datas value is public knowledge. The work an attacker must do to guess a piece of data is directly related to how much entropy there is in the data. If the
data has 4 bits of entropy, then the attacker has a 1 in 2
4
chance 1 in 16 chance of guessing right the first time. Additionally, within 16 guesses, the attacker will have tried the right value On
15
average, he will find the right value in 8 guesses. If the data has 128 bits of entropy in it, then the attacker will need, on average 2
127
guesses to find the seed, which is such a large number as to be infeasible for all practical purposes. In practice, if youre using 128-bit keys, its desirable to use a
seed with 128 bits of entropy or more. Anything less than 64 bits of entropy can probably be broken quickly by an organization with a modest hardware budget.
To illustrate, in 1996, Ian Goldberg and David Wagner found a problem with the way Netscape was seeding its PRNG in its implementation of SSLv2. Netscape was using three inputs hashed
with the MD5 message digest algorithm, the time of day, the process ID, and the parent process ID. None of these values is particularly random. At most, their PRNG seed could have had 47 bits of
entropy. A clever attacker could decrease that substantially. Indeed, in practice, Goldberg and Wagner were able to compromise real SSL sessions within 25 seconds.
If you try to use OpenSSL without bothering to seed the random number generator, the library will complain. However, the library has no real way to know whether the seed you give it contains
enough entropy. Therefore, you must have some idea how to get entropy. There are certainly hardware devices that do a good job of collecting it, including most of the cryptographic
accelerator cards. However, in many cases hardware is impractical, because your software will be deployed across a large number of clients, most of whom will have no access to such devices.
Many software tricks are commonly employed for collecting entropy on a machine. They tend to work by indirectly measuring random information in external events that affect the machine. You
should never need to worry about those actual techniques. Instead, use a package that harvests entropy for you. Many Unix-based operating systems now come with a random device, which
provides entropy harvested by the operating system. On other Unix systems, you can use tools such as EGADS
http:www.securesw.comegads , which is a portable entropy collection
system.
[7]
EGADS also works on Windows systems.
[7]
We realize that Linux isnt technically a Unix operating system, since it is not derived from the original Unix code base. However, we feel the common usage of the term Unix extends to any Unix-
like operating system, and thats how we use this term throughout the book.
If youre interested in the entropy harvesting techniques behind random devices and tools like EGADS, see Chapter 10 of the book Building Secure Software by John Viega and Gary McGraw
Addison-Wesley.
1.3.6 Insecure Cryptography
