使用OpenSSL强化网络安全性

5星 · 超过95%的资源需积分: 13 13 浏览量更新于2024-07-21 收藏 2.38MB PDF 举报

"Network Security with OpenSSL 免费" 《Network Security with OpenSSL》是一本由Pravir Chandra、Matt Messier和John Viega合著的专业书籍，由O'Reilly出版社于2002年6月出版，共计384页。这本书专注于网络通信安全，特别是使用OpenSSL这个开源软件来实现SSL/TLS协议，SSL/TLS是目前最广泛使用的安全网络通信协议。 OpenSSL是一个流行且高效的开源SSL/TLS实现，该书是唯一一本专门探讨该主题的指南。作者深入浅出地介绍了在网络安全中面临的挑战，并指导读者如何有效地利用OpenSSL工具来应对这些挑战。本书的定位是实践导向，只提供使用OpenSSL时必要的安全和有效信息。书中内容包括： 1. 引言（Introduction）：首先对加密学进行了简要介绍，让非专业人士也能理解基础概念。然后概述了SSL的作用和工作原理，同时也指出了SSL存在的问题，如其无法完全解决的安全隐患。 2. 命令行界面（Command-Line Interface）：这部分详细讲解了OpenSSL命令行的基本用法，包括消息摘要算法、对称加密算法以及公钥密码学等核心概念。这对于实际操作和配置OpenSSL非常关键。 2.1 基础部分：介绍了如何启动和使用OpenSSL命令行工具。 2.2 消息摘要算法：讲解了如MD5和SHA等用于验证数据完整性的算法。 2.3 对称加密算法：讨论了DES、AES等用于数据加密的算法。 2.4 公钥密码学：涵盖了RSA、DSA等非对称加密算法及其应用。 3. 预告章节还包括了如何加固第三方软件（Securing Third-Party Software），这可能涉及到如何在其他应用程序或系统中集成和使用OpenSSL来增强安全性。本书适合网络管理员、系统工程师、安全专家以及任何对网络通信安全感兴趣的读者。尽管出版时间较早，但OpenSSL的基础原理和技术仍然是现代网络安全的重要组成部分，因此这本书依然具有很高的学习价值。通过阅读此书，读者可以掌握OpenSSL的实用技巧，提升网络通信的安全性。

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

integrity for general-purpose data transfer, whether encrypted or not. Indeed, SSL uses MACs for

this purpose.

The most widely used MAC, and the only one currently supported in SSL and in OpenSSL, is

HMAC. HMAC can be used with any message digest algorithm.

1.1.2.4 Digital signatures

For many applications, MACs are not very useful, because they require agreeing on a shared

secret. It would be nice to be able to authenticate messages without needing to share a secret.

Public key cryptography makes this possible. If Alice signs a message with her secret signing key,

then anyone can use her public key to verify that she signed the message. RSA provides for digital

signing. Essentially, the public key and private key are interchangeable. If Alice encrypts a

message with her private key, anyone can decrypt it. If Alice didn't encrypt the message, using her

public key to decrypt the message would result in garbage.

There is also a popular scheme called DSA (the Digital Signature Algorithm), which the SSL

protocol and the OpenSSL library both support.

Much like public key encryption, digital signatures are very slow. To speed things up, the

algorithm generally doesn't operate on the entire message to be signed. Instead, the message is

cryptographically hashed, and then the hash of the message is signed. Nonetheless, signature

schemes are still expensive. For this reason, MACs are preferable if any sort of secure key

exchange has taken place.

One place where digital signatures are widely used is in certificate management. If Alice is willing

to validate Bob's certificate, she can sign it with her private key. Once she's done that, Bob can

attach her signature to his certificate. Now, let's say he gives the certificate to Charlie, and Charlie

does not know that Bob actually gave him the certificate, but he would believe Alice if she told

him the certificate belonged to Bob. In this case, Charlie can validate Alice's signature, thereby

demonstrating that the certificate does indeed belong to Bob.

Since digital signatures are a form of public key cryptography, you should be sure to use key

lengths of 1,024 bits or higher to ensure security.

1.2 Overview of SSL

SSL is currently the most widely deployed security protocol. It is the security protocol behind

secure HTTP (HTTPS), and thus is responsible for the little lock in the corner of your web

browser. SSL is capable of securing any protocol that works over TCP.

An SSL transaction (see Figure 1-3

) starts with the client sending a handshake to the server. In the

server's response, it sends its certificate. As previously mentioned, a certificate is a piece of data

that includes a public key associated with the server and other interesting information, such as the

owner of the certificate, its expiration date, and the fully qualified domain name

[2]

associated with

the server.

[2]

By fully qualified, we mean that the server's hostname is written out in a full, unambiguous

manner that includes specifying the top-level domain. For example, if our web server is named

"www", and our corporate domain is "securesw.com", then the fully qualified domain name for that

host is "www.securesw.com". No abbreviation of this name would be considered fully qualified.

Figure 1-3. An overview of direct communication in SSL

剩余337页未读，继续阅读

miaoxuerong

粉丝: 4
资源: 6

使用OpenSSL强化网络安全性

security_with_OpenSSL

Network Security with OpenSSL

cryptography network security 7th pdf

Network security with OpenSSL

O' Reilly - Network Security With Openssl.pdf

apache security 安全

OpenSSL网络安全实践指南

使用OpenSSL强化网络通信安全

使用OpenSSL实现网络通信安全

使用OpenSSL强化网络安全性

最新资源