OpenSSL安全指南：实践与挑战

4星 · 超过85%的资源需积分: 50 136 浏览量更新于2024-07-27 收藏 2.41MB PDF 举报

"《openssl.pdf》是一本由Pravir Chandra、Matt Messier和John Viega合著的专业书籍，由O'Reilly出版社于2002年6月出版。该书的ISBN为0-596-00270-X，共384页，专为学习者提供关于流行的开源SSL/TLS协议——OpenSSL的全面指南。OpenSSL是确保网络通信安全的关键工具，它在当前广泛应用于各种安全网络通信场景。本书的主要内容围绕如何有效地利用OpenSSL解决网络通信中的安全挑战展开。作者首先向非专业读者解释了加密的基本概念（1.1节），让普通读者也能理解这个领域的核心原理。接着（1.2节），作者概述了SSL的运作机制和其在网络安全中的重要性。然而，书中也指出了SSL存在的问题和局限性（1.3节和1.4节），以便读者对这个技术有更全面的认识。在实际操作层面，第1章的最后部分（1.5节）介绍了 OpenSSL 的基础知识，包括其在安全实践中的关键组成部分。对于那些需要保护第三方软件安全的读者，书中有专门章节（1.6节）讲解如何在应用中正确地集成和管理OpenSSL。第二章（2.1节）主要介绍OpenSSL的命令行接口，这是理解和操作OpenSSL的重要途径。随后章节分别深入探讨了消息摘要算法（2.2节）、对称密钥加密（2.3节）以及公钥加密（2.4节），这些都是构建安全通信链路的核心技术。通过这些内容，读者可以掌握如何通过OpenSSL进行数据加密、解密、签名和验证等操作，从而确保网络通信的安全性。《Network Security with 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页未读，继续阅读

user202

粉丝: 35
资源: 80

OpenSSL安全指南：实践与挑战

OpenSSL使用指南.pdf

openssl教程.pdf

SSL和OPENSSL 资料整理

升级openssh及openssl.pdf

Win IOCP中使用openssl.pdf

O' Reilly - Network Security With Openssl.pdf

Kubernetes RBAC with Openssl Authentication.pdf

openssl编程.pdf -<赵春平>

直接调用OpenSSL.rar

如何把OpenSSH公钥转换成OpenSSL格式.pdf

最新资源