深入理解OpenSSL：网络安全实践指南

需积分: 0 178 浏览量更新于2024-06-27 收藏 2.3MB PDF 举报

"《O'Reilly - Network Security With OpenSSL》是由Pravir Chandra, Matt Messier和John Viega合著的一本关于网络安全和OpenSSL的书籍，由O'Reilly出版社于2002年6月出版。本书是唯一一本专注于OpenSSL的指南，深入探讨了网络安全的挑战，并详细介绍如何利用OpenSSL工具来应对这些挑战。内容侧重于实践应用，旨在提供安全有效使用OpenSSL所需的关键信息。" 本书共384页，内容涵盖了从加密基础知识到SSL协议的概述，以及SSL存在的问题和不足。作者们在书中讨论了OpenSSL的基础知识，包括它的功能和用途。章节内容包括： 1. **引言**：这部分介绍了密码学的基本概念，面向非专业读者，让读者理解加密技术的重要性。接着，作者概述了SSL（Secure Socket Layer）的作用，它是互联网上广泛用于安全通信的协议。 2. **SSL的概述**：详细阐述了SSL协议的工作原理，如何建立安全的连接，以及它在保护网络数据传输中的角色。 3. **SSL的问题**：分析了SSL在实际应用中可能遇到的问题，包括其局限性和潜在的安全风险。 4. **SSL做得不好的地方**：进一步探讨了SSL在某些情况下的不足之处，指出可能存在的安全漏洞或弱点。 5. **OpenSSL基础**：介绍了OpenSSL这个开源库的特性，包括它提供的加密算法、证书管理以及实现SSL/TLS协议的工具。书中还包含了其他章节，可能会涵盖OpenSSL的安装、配置、证书管理、安全策略制定以及如何处理安全事件等内容。此外，书中有助于读者理解和掌握OpenSSL实际操作的实例和最佳实践。《Network Security with OpenSSL》对于系统管理员、网络安全专家以及对加密和网络安全感兴趣的读者来说，是一本非常有价值的参考书。通过学习这本书，读者可以更好地理解如何利用OpenSSL来保护网络通信，增强系统的安全性。

Tampering

An attacker monitors network traffic and maliciously changes data in transit (for example,

an attacker may modify the contents of an email message).

Spoofing

An attacker forges network data, appearing to come from a different network address than

he actually comes from. This sort of attack can be used to thwart systems that authenticate

based on host information (e.g., an IP address).

Hijacking

Once a legitimate user authenticates, a spoofing attack can be used to "hijack" the

connection.

Capture-replay

In some circumstances, an attacker can record and replay network transactions to ill effect.

For example, say that you sell a single share of stock while the price is high. If the

network protocol is not properly designed and secured, an attacker could record that

transaction, then replay it later when the stock price has dropped, and do so repeatedly

until all your stock is gone.

Many people assume that some (or all) of the above attacks aren't actually feasible in practice.

However, that's far from the truth. Especially due to tool sets such as dsniff

(http://www.monkey.org/~dugsong/dsniff/), it doesn't even take much experience to launch all of

the above attacks if access to any node on a network between the two endpoints is available.

Attacks are equally easy if you're on the same local network as one of the endpoints. Talented high

school students who can use other people's software to break into machines and manipulate them

can easily manage to use these tools to attack real systems.

Traditionally, network protocols such as HTTP, SMTP, FTP, NNTP, and Telnet don't provide

adequate defenses to the above attacks. Before electronic commerce started taking off in mid-1990,

security wasn't really a large concern, especially considering the Internet's origins as a platform for

sharing academic research and resources. While many protocols provided some sort of

authentication in the way of password-based logins, most of them did not address confidentiality

or integrity at all. As a result, all of the above attacks were possible. Moreover, authentication

information could usually be among the information "snooped" off a network.

SSL is a great boon to the traditional network protocols, because it makes it easy to add

transparent confidentiality and integrity services to an otherwise insecure TCP-based protocol. It

can also provide authentication services, the most important being that clients can determine if

they are talking to the intended server, not some attacker that is spoofing the server.

1.1.2 Cryptographic Algorithms

The SSL protocol covers many cryptographic needs. Sometimes, though, it isn't good enough. For

example, you may wish to encrypt HTTP cookies that will be placed on an end user's browser.

SSL won't help protect the cookies while they're being stored on that disk. For situations like this,

OpenSSL exports the underlying cryptographic algorithms used in its implementation of the SSL

protocol.

Generally, you should avoid using cryptographic algorithms directly if possible. You're not likely

to get a totally secure system simply by picking an algorithm and applying it. Usually,

cryptographic algorithms are incorporated into cryptographic protocols. Plenty of nonobvious

things can be wrong with a protocol based on cryptographic algorithms. That is why it's better to

try to find a well-known cryptographic protocol to do what you want to do, instead of inventing

something yourself. In fact, even the protocols invented by cryptographers often have subtle holes.

If not for public review, most protocols in use would be insecure. Consider the original WEP

protocol for IEEE 802.11 wireless networking. WEP (Wired Equivalent Privacy) is the protocol

that is supposed to provide the same level of security for data that physical lines provide. It is a

challenge, because data is transmitted through the air, instead of across a wire. WEP was designed

by veteran programmers, yet without soliciting the opinions of any professional cryptographers or

security protocol developers. Although to a seasoned developer with moderate security knowledge

the protocol looked fine, in reality, it was totally lacking in security.

Nonetheless, sometimes you might find a protocol that does what you need, but can't find an

implementation that suits your needs. Alternatively, you might find that you do need to come up

with your own protocol. For those cases, we do document the SSL cryptographic API.

Five types of cryptographic algorithms are discussed in this book: symmetric key encryption,

public key encryption, cryptographic hash functions, message authentication codes, and digital

signatures.

1.1.2.1 Symmetric key encryption

Symmetric key algorithms encrypt and decrypt data using a single key. As shown in Figure 1-1,

the key and the plaintext message are passed to the encryption algorithm, producing ciphertext.

The result can be sent across an insecure medium, allowing only a recipient who has the original

key to decrypt the message, which is done by passing the ciphertext and the key to a decryption

algorithm. Obviously, the key must remain secret for this scheme to be effective.

Figure 1-1. Symmetric key cryptography

The primary disadvantage of symmetric key algorithms is that the key must remain secret at all

times. In particular, exchanging secret keys can be difficult, since you'll usually want to exchange

keys on the same medium that you're trying to use encryption to protect. Sending the key in the

clear before you use it leaves open the possibility of an attacker recording the key before you even

begin to send data.

One solution to the key distribution problem is to use a cryptographic key exchange protocol.

OpenSSL provides the Diffie-Hellman protocol for this purpose, which allows for key agreement

without actually divulging the key on the network. However, Diffie-Hellman does not guarantee

the identity of the party with whom you are exchanging keys. Some sort of authentication

mechanism is necessary to ensure that you don't accidentally exchange keys with an attacker.

Right now, Triple DES (usually written 3DES, or sometimes DES3) is the most conservative

symmetric cipher available. It is in wide use, but AES, the new Advanced Encryption Standard,

will eventually replace it as the most widely used cipher. AES is certainly faster than 3DES, but

3DES has been around a lot longer, and thus is a more conservative choice for the ultra-paranoid.

It is worth mentioning that RC4 is widely supported by existing clients and servers. It is faster

than 3DES, but is difficult to set up properly (don't worry, SSL uses RC4 properly). For purposes

of compatibility with existing software in which neither AES nor 3DES are supported, RC4 is of

particular interest. We don't recommend supporting other algorithms without a good reason. For

the interested, we discuss cipher selection in Chapter 6.

Security is related to the length of the key. Longer key lengths are, of course, better. To ensure

security, you should only use key lengths of 80 bits or higher. While 64-bit keys may be secure,

they likely will not be for long, whereas 80-bit keys should be secure for at least a few years to

come. AES supports only 128-bit keys and higher, while 3DES has a fixed 112 bits of effective

security.

[1]

Both of these should be secure for all cryptographic needs for the foreseeable future.

Larger keys are probably unnecessary. Key lengths of 56 bits (regular DES) or less (40-bit keys

are common) are too weak; they have proven to be breakable with a modest amount of time and

effort.

[1]

3DES provides 168 bits of security against brute-force attacks, but there is an attack that reduces

the effective security to 112 bits. The enormous space requirements for that attack makes it about

as practical as brute force (which is completely impractical in and of itself).

1.1.2.2 Public key encryption

Public key cryptography suggests a solution to the key distribution problem that plagues

symmetric cryptography. In the most popular form of public key cryptography, each party has two

keys, one that must remain secret (the private key) and one that can be freely distributed (the

public key). The two keys have a special mathematical relationship. For Alice to send a message to

Bob using public key encryption (see Figure 1-2), Alice must first have Bob's public key. She then

encrypts her message using Bob's public key, and delivers it. Once encrypted, only someone who

has Bob's private key can successfully decrypt the message (hopefully, that's only Bob).

Figure 1-2. Public key cryptography

Public key encryption solves the problem of key distribution, assuming there is some way to find

Bob's public key and ensure that the key really does belong to Bob. In practice, public keys are

passed around with a bunch of supporting information called a certificate, and those certificates

are validated by trusted third parties. Often, a trusted third party is an organization that does

research (such as credit checks) on people who wish to have their certificates validated. SSL uses

trusted third parties to help address the key distribution problem.

Public key cryptography has a significant drawback, though: it is intolerably slow for large

messages. Symmetric key cryptography can usually be done quickly enough to encrypt and

decrypt all the network traffic a machine can manage. Public key cryptography is generally

limited by the speed of the cryptography, not the bandwidth going into the computer, particularly

on server machines that need to handle multiple connections simultaneously.

As a result, most systems that use public key cryptography, SSL included, use it as little as

possible. Generally, public key encryption is used to agree on an encryption key for a symmetric

algorithm, and then all further encryption is done using the symmetric algorithm. Therefore,

public key encryption algorithms are primarily used in key exchange protocols and when non-

repudiation is required.

RSA is the most popular public key encryption algorithm. The Diffie-Hellman key exchange

protocol is based on public key technology and can be used to achieve the same ends by

exchanging a symmetric key, which is used to perform actual data encryption and decryption. For

public key schemes to be effective, there usually needs to be an authentication mechanism

involving a trusted third party that is separate from the encryption itself. Most often, digital

signature schemes, which we discuss below, provide the necessary authentication.

Keys in public key algorithms are essentially large numbers with particular properties. Therefore,

bit length of keys in public key ciphers aren't directly comparable to symmetric algorithms. With

public key encryption algorithms, you should use keys of 1,024 bits or more to ensure reasonable

security. 512-bit keys are probably too weak. Anything larger than 2,048 bits may be too slow,

and chances are it will not buy security that is much more practical. Recently, there's been some

concern that 1,024-bit keys are too weak, but as of this writing, there hasn't been conclusive proof.

Certainly, 1,024 bits is a bare minimum for practical security from short-term attacks. If your keys

potentially need to stay protected for years, then you might want to go ahead and use 2,048-bit

keys.

When selecting key lengths for public key algorithms, you'll usually need to select symmetric key

lengths as well. Recommendations vary, but we recommend using 1,024-bit keys when you are

willing to work with symmetric keys that are less than 100 bits in length. If you're using 3DES or

128-bit keys, we recommend 2,048-bit public keys. If you are paranoid enough to be using 192-bit

keys or higher, we recommend using 4,096-bit public keys.

Requirements for key lengths change if you're using elliptic curve cryptography (ECC), which is a

modification of public key cryptography that can provide the same amount of security using faster

operations and smaller keys. OpenSSL currently doesn't support ECC, and there may be some

lingering patent issues for those who wish to use it. For developers interested in this topic, we

recommend the book Implementing Elliptic Curve Cryptography, by Michael Rosing (Manning).

1.1.2.3 Cryptographic hash functions and Message Authentication Codes

Cryptographic hash functions are essentially checksum algorithms with special properties. You

pass data to the hash function, and it outputs a fixed-size checksum, often called a message digest,

or simply digest for short. Passing identical data into the hash function twice will always yield

identical results. However, the result gives away no information about the data input to the

function. Additionally, it should be practically impossible to find two inputs that produce the same

message digest. Generally, when we discuss such functions, we are talking about one-way

functions. That is, it should not be possible to take the output and algorithmically reconstruct the

input under any circumstances. There are certainly reversible hash functions, but we do not

consider such things in the scope of this book.

For general-purpose usage, a minimally secure cryptographic hash algorithm should have a digest

twice as large as a minimally secure symmetric key algorithm. MD5 and SHA1 are the most

popular one-way cryptographic hash functions. MD5's digest length is only 128 bits, whereas

SHA1's is 160 bits. For some uses, MD5's key length is suitable, and for others, it is risky. To be

safe, we recommend using only cryptographic hash algorithms that yield 160-bit digests or larger,

unless you need to support legacy algorithms. In addition, MD5 is widely considered "nearly

broken" due to some cryptographic weaknesses in part of the algorithm. Therefore, we

recommend that you avoid using MD5 in any new applications.

Cryptographic hash functions have been put to many uses. They are frequently used as part of a

password storage solution. In such circumstances, logins are checked by running the hash function

over the password and some additional data, and checking it against a stored value. That way, the

server doesn't have to store the actual password, so a well-chosen password will be safe even if an

attacker manages to get a hold of the password database.

Another thing people like to do with cryptographic hashes is to release them alongside a software

release. For example, OpenSSL might be released alongside a MD5 checksum of the archive.

When you download the archive, you can also download the checksum. Then you can compute the

checksum over the archive and see if the computed checksum matches the downloaded checksum.

You might hope that if the two checksums match, then you securely downloaded the actual

released file, and did not get some modified version with a Trojan horse in it. Unfortunately, that

isn't the case, because there is no secret involved. An attacker can replace the archive with a

modified version, and replace the checksum with a valid value. This is possible because the

message digest algorithm is public, and there is no secret information input to it.

If you share a secret key with the software distributor, then the distributor could combine the

archive with the secret key to produce a message digest that an attacker shouldn't be able to forge,

since he wouldn't have the secret. Schemes for using keyed hashes, i.e., hashes involving a secret

key, are called Message Authentication Codes (MACs). MACs are often used to provide message

剩余338页未读，继续阅读

森一郎

粉丝: 0
资源: 7

深入理解OpenSSL：网络安全实践指南

Network Security with OpenSSL

OpenSSL*与网络*信息安全--完整版

security_with_OpenSSL

OpenSSL网络安全实践指南

使用OpenSSL强化网络通信安全

使用OpenSSL实现网络通信安全

使用OpenSSL强化网络安全性

OpenSSL安全指南：实践与挑战

OpenSSL揭秘：网络通信安全实践指南

OpenSSL网络安全指南：实践与挑战

最新资源

OpenSSL与网络信息安全--完整版