01.openssl基础介绍

本章介绍SSL和OpenSSL库。 咱们给出一个概述涉及部署图书馆的最大安全风险，并讨论如何缓解他们在高层次。 咱们也看看如何使用OpenSSL和Stunnel来保护第三方软件，例如没有内置SSL支持的POP服务器。

1.1 Cryptography for the Rest of Us

1.1.1 Goals of Cryptography

有许多不一样的加密算法，每一个加密算法能够为应用程序提供如下一项或多项服务：

Confidentiality (secrecy)
即便数据是经过不安全的介质传输的，数据也会被保密。 实际上，这意味着潜在的攻击者可能会看到实质上“锁定”的乱码数据，可是若是没有正确的信息，他们就不能解锁数据。 在传统的密码学中，加密（加扰）算法是秘密。 在现代密码学中，这是不可行的。 算法是公开的，加密和解密过程当中使用密钥。 惟一须要保密的是关键。 另外，正如咱们稍后将要演示的，常见的状况是否是全部的密钥都须要保密。

Integrity (anti-tampering)
数据完整性背后的基本思想是，一个数据的接收者应该有一种方法来肯定是否在一段时间内进行了修改。 例如，可使用完整性检查来确保经过线路发送的数据在传输过程当中不被修改。 大量的着名校验和存在，能够检测甚至纠正简单的错误。 然而，这样的校验和在检测数据的熟练的有意修改方面不好。 若是正确使用，几个加密校验和不具备这些缺点。 请注意，加密不能确保数据的完整性。 整个类的加密算法都受到“翻转”攻击。 也就是说，攻击者能够改变经过改变相应的加密位数据来实现一位数据的实际值。

Authentication （认证）
密码学能够帮助创建身份认证的目的。

Non-repudiation
密码学可使鲍勃证实他从爱丽丝收到的消息实际上来自爱丽丝。 当Alice向Bob发送这样一条消息时，Alice本质上能够被追究责任，由于她不可否认（否定）她发送的消息。 在现实世界中，你必须假设攻击者不会损害特定的加密密钥。 SSL协议不支持不能否认性，但经过使用数字签名很容易添加。

Snooping (passive eavesdropping)
攻击者会在网络流量经过并记录有趣的数据时观察网络流量信用卡信息。

Tampering（篡改）
攻击者监视网络流量并恶意更改传输中的数据（例如，攻击者可能会修改电子邮件的内容）

Spoofing（欺骗）
攻击者伪造网络数据，彷佛来自不一样于实际来自的网络地址。 这种攻击能够用来阻止基于主机信息（例如，IP地址）进行认证的系统。

Hijacking(劫持)
一旦合法用户认证，欺骗攻击就能够用来“劫持”链接。

Capture-replay（重播）
在某些状况下，攻击者能够对网络交易进行记录和重放，从而产生不良影响。例如，假设您在出售单个股票的同时价格很高。 若是网络协议设计得不稳当，攻击者可能会记录该协议交易，而后在股票价格下跌的时候重播，直到你全部的股票都没有了

1.1.2 Cryptographic Algorithms

本书讨论了五种密码算法：对称密钥加密，公钥加密，加密散列函数，消息认证代码和数字签名。

1.1.2.1 Symmetric key encryption
对称密钥算法使用单个密钥加密和解密数据。 如图1-1所示，密钥和明文消息被传递给密码算法，产生密文。结果能够经过不安全的媒体发送，只容许有原始密钥的接收方解密消息，完成 经过将密文和密钥传递给解密算法。 显然，这项计划的关键必须保密。

对称密钥算法的主要缺点是密钥必须始终保密。 特别是，交换密钥可能很困难，由于一般您想要在您尝试使用加密保护的介质上交换密钥。 在发送密钥在使用以前清除，在攻击者甚至尚未记录密钥的状况下，可能会形成攻击者的可能性开始发送数据。

密钥分发问题的一个解决方案是使用密码密钥交换协议.OpenSSL为此提供了Diffie-Hellman协议，它容许密钥协商而不实际泄露网络上的密钥。 可是，Diffie-Hellman并不能保证与你交换密钥的一方的身份。 某种形式的身份验证机制对于确保您不会意外与攻击者交换密钥是必要的。

目前，Triple DES（一般是3DES，或者有时是DES3）是最保守的对称密码。 它被普遍使用，可是，新的高级加密标准AES将最终取代它做为最普遍使用的密码。 AES确实比3DES更快，可是3DES已经有了更长的时间，所以对于超偏执的人来讲是更保守的选择。 值得一提的是，RC4获得了现有客户端和服务器的普遍支持。 它比3DES快，但难以正确设置（不用担忧，SSL使用RC4）。 为了与既不支持AES也不支持3DES的现有软件兼容，RC4特别感兴趣。 咱们不建议在没有充分理由的状况下支持其余算法。 对于感兴趣的，咱们在第6章讨论密码选择。

安全性与密钥的长度有关。 更长的钥匙长度固然更好。 为确保安全性，您只能使用80位或更高的密钥长度。 虽然64位密钥多是安全的，但它们可能不会很长，而80位密钥在至少几年内应该是安全的。 AES只支持128位和更高的密钥，而3DES则具备固定的112位有效安全性[1]。 在可预见的将来，这两种方法都应该是安全的，以知足全部的密码需求。大型密钥多是没必要要的。 56位（常规DES）或更少（40位密钥常见）的密钥长度太弱; 他们已经证实是能够经过适量的时间和精力来解决的。

1.1.2.2 Public key encryption
公钥密码学提出了解决对称密码术的关键分布问题的解决方案。 在最流行的公钥密码体制中，每一方都有两个密钥，一个必须保密（私钥）和一个能够自由分配的密钥（公钥）。 这两个键有一个特殊的数学关系。 对于Alice使用公钥加密发送消息给Bob（见图1-2），Alice必须先拥有Bob的公钥。 而后，她使用Bob的公钥加密她的消息，并将其传递。 一旦加密，只有拥有Bob私钥的人才能成功解密邮件（但愿这只是Bob）

公钥加密解决了密钥分发的问题，假设有一些方法能够找到Bob的公钥并确保密钥真的属于Bob。 在实践中，公钥经过一系列称为证书的支持信息传递，这些证书由可信任的第三方验证。 一般状况下，一个可信的第三方是一个对那些但愿验证其证书的人进行研究（如信用检查）的组织。 SSL使用可信的第三方来解决密钥分发问题.

公钥密码学有一个显着的缺点，可是对于大消息来讲，速度慢得使人难以忍受。 对称密钥加密一般能够快速完成，以加密和解密机器能够管理的全部网络流量。 公钥加密通常受加密速度的限制，而不是进入计算机的带宽，特别是在须要同时处理多个链接的服务器上。

所以，大多数使用公钥密码系统（包括SSL）的系统尽量少地使用它。 一般状况下，公钥加密用于协商对称算法的加密密钥，而后全部进一步的加密都使用对称算法完成。 所以，公钥加密算法主要用于密钥交换协议以及须要不能否认的状况。

RSA是最流行的公钥加密算法。 Diffie-Hellman密钥交换协议基于公钥技术，能够经过交换对称密钥实现相同的目的，用于执行实际的数据加密和解密。 为了使公钥方案有效，一般须要有一个涉及与加密自己分离的可信第三方的认证机制。 大多数状况下，咱们在下面讨论的数字签名方案提供了必要的认证。

公钥算法中的密钥本质上是具备特定属性的大数字。 所以，公钥密码中密钥的比特长度不能直接与对称算法相比较。 对于公钥加密算法，应该使用1024位以上的密钥来保证合理的安全性。 512位密钥可能太弱了。 大于2048位的任何内容均可能太慢，而且极可能不会购买更实用的安全性。 最近有人担忧1,024位密钥太弱，但在撰写本文时尚未确切的证据.若是您的密钥可能须要保护多年，那么您可能须要继续使用2,048位键。

在为公钥算法选择密钥长度时，一般还须要选择对称密钥长度。 建议有所不一样，可是咱们建议您在使用长度小于100位的对称密钥时使用1,024位密钥。 若是您使用的是3DES或128位密钥，咱们推荐使用2,048位公钥。 若是您偏执到使用192位密钥或更高，咱们推荐使用4096位公钥。

若是您使用的是椭圆曲线加密（ECC），那么对密钥长度的要求就会发生变化。这是对公钥加密技术的一种修改，可使用更快的操做和更小的密钥来提供相同的安全性。 OpenSSL目前不支持ECC，对于那些但愿使用它的人来讲，可能会有一些悬而未决的专利问题。 对于对此主题感兴趣的开发人员，咱们推荐Michael Rosing（Manning）撰写的“实现椭圆曲线加密”一书。

1.1.2.3 Cryptographic hash functions and Message Authentication Codes
加密哈希函数本质上是具备特殊属性的校验和算法。 您将数据传递给哈希函数，并输出固定大小的校验和（一般称为消息摘要），或者简称为摘要。 将相同的数据传递给哈希函数两次将老是产生相同的结果。 可是，结果没有提供有关输入到该功能的数据的信息。 另外，找到两个产生相同消息摘要的输入其实是不可能的。 通常来讲，当咱们讨论这样的功能时，咱们谈论的是单向功能。 也就是说，在任何状况下，输出和算法都不可能重构输入。 固然有可逆的哈希函数，可是咱们在本书的范围内并不考虑这种状况。

对于通用的用法，一个最小安全的密码哈希算法应该有一个摘要是最小安全对称密钥算法的两倍。 MD5和SHA1是最流行的单向加密散列函数。 MD5的摘要长度只有128位，而SHA1是160位。 对于某些用途，MD5的密钥长度是适合的，对于其余用户来讲，这是危险的。 为了安全起见，咱们建议只使用产生160位摘要或更大的加密散列算法，除非您须要支持传统算法。 另外，因为部分算法存在一些密码上的弱点，MD5被普遍认为是“接近破碎”。 因此，咱们建议您避免在任何新的应用程序中使用MD5。

密码散列函数已被用于许多用途。 它们常常用做密码存储解决方案的一部分。 在这种状况下，经过在密码和一些额外的数据上运行散列函数来检查登陆，并根据存储的值检查登陆。 这样，服务器没必要存储实际的密码，所以即便攻击者设法获取密码数据库，选择的密码也是安全的。

人们喜欢用加密哈希来作的另外一件事就是在发布软件的同时发布它们。 例如，OpenSSL可能会与归档的MD5校验和一块儿发布。当您下载归档时，还能够下载校验和。 而后，您能够计算归档上的校验和，并查看计算出的校验和是否与下载的校验和相匹配。您可能但愿若是两个校验和匹配，那么您已经安全地下载了实际发布的文件，而且没有获得一些特洛伊木马的修改版本 在里面。 不幸的是，状况并不是如此，由于没有涉及的秘密。 攻击者能够用修改后的版本替换存档，并用有效值替换校验和。 这是可能的，由于消息摘要算法是公开的，没有秘密信息输入给它。

若是您与软件分销商共享密钥，则分销商能够将存档与密钥结合起来，以产生一个攻击者不该该伪造的消息摘要，由于他不会有这个秘密。 用于使用密钥散列的方案，即涉及密钥的散列被称为消息认证码（MAC）。MAC一般用于为通用数据传输提供消息完整性，不管是否加密。 事实上，SSL使用MAC来达到这个目的。

1.1.2.4 Digital signatures
对于许多应用来讲，MAC并非很是有用，由于它们须要就共享密钥达成一致。 可以认证消息而不须要共享秘密将是很好的。 公钥密码学使这成为可能。 若是Alice用她的秘密签名密钥签署消息，则任何人均可以使用她的公钥来验证她是否签署了该消息。 RSA提供数字签名。 基本上，公钥和私钥是能够互换的。 若是Alice用她的私钥加密一条消息，任何人均可以解密它。 若是Alice没有对消息进行加密，则使用她的公钥解密消息将致使垃圾。

很像公钥加密，数字签名很是缓慢。 为了加快速度，算法通常不会对整个要签名的消息进行操做。 相反，消息被加密散列，而后消息的散列被签名。 尽管如此，签名计划仍然很昂贵。 为此，若是发生任何类型的安全密钥交换，则MAC是优选的。

因为数字签名是公钥加密的一种形式，所以您应该确保使用1024位或更高的密钥长度来确保安全

1.2 Overview of SSL

SSL是目前应用最普遍的安全协议。 它是安全HTTP（HTTPS）背后的安全协议，所以负责网络浏览器角落的小锁定。 SSL可以保护经过TCP工做的任何协议。

SSL事务（见图1-3）从客户端向服务器发送握手开始。 在服务器的响应中，它发送它的证书。 如前所述，证书是包含与服务器关联的公钥和其余感兴趣信息的数据片断，例如证书全部者，其到期日期以及与服务器关联的彻底限定的域名[2]

在链接过程当中，服务器将使用其私钥证实其身份，以成功解密客户端使用服务器公钥加密的挑战。 客户端须要接收正确的未加密数据才能继续。 所以，服务器的证书能够保持公开 - 攻击者须要证书副本以及相关的私钥，以假装成已知的服务器

可是，攻击者老是能够拦截服务器消息并呈现攻击者的证书。伪造的证书的数据字段能够看起来是合法的（例如与服务器关联的域名和与证书关联的实体的名称）。在这种状况下，攻击者可能创建到目标服务器的代理链接，而后窃听全部的数据。这样的攻击被称为“中间人”攻击，如图1-4所示。为了彻底阻止中间人攻击，客户端不只要对服务器证书进行完全的验证，并且还要有一些肯定证书自己是否可信的方法。肯定可信度的一种方法是将有效证书列表硬编码到客户端中。这个解决方案的问题是它不可扩展。想象一下，在开始浏览网页以前，须要为每一个安全的HTTP服务器提供证书，这些服务器可能但愿在存储在网络浏览器中的网络上使用。

这个问题的实际解决方案是涉及一个可信的第三方，负责保存有效证书的数据库。 可信的第三方（称为认证中心）使用其私钥对有效的服务器证书进行签名。 签名表示认证机构已经对拥有证书的实体进行了背景检查，

客户端能够验证当局的签名，假设它在本地拥有认证中心的公钥。 若是检查成功，则客户能够合理确信证书由可信第三方已知的实体拥有，而后能够检查存储在证书中的其余信息的有效性，例如证书是否过时。

虽然不多，服务器也能够从客户端请求证书。 在证书验证完成以前，客户端和服务器就要使用哪些加密算法达成一致。 在证书验证以后，客户端和服务器使用安全密钥协商协议（使用对称密钥加密算法传输数据）就对称密钥达成一致。 一旦全部的谈判都完成，客户端和服务器能够随意交换数据。

SSL协议的细节稍微复杂一些。 消息认证码普遍用于确保数据完整性。 另外，在证书验证期间，一方能够去证书吊销列表（CRL）的证书颁发机构，以确保看起来有效的证书实际上没有被盗取

咱们不会深刻到SSL协议（或其后继者，TLS）的细节。 就咱们的目的而言，咱们能够把全部其余事情看成黑箱。 再一次，若是您对这些细节感兴趣，咱们推荐Eric Rescorla的书籍SSL和TLS。

1.3 Problems with SSL

SSL是一个很好的协议。 像许多工具同样，它是有效的在谁知道如何使用它的人的手中，但容易被误用。 人们在部署SSL时会遇到许多陷阱，其中大部分能够经过一些工做来避免。

1.3.1 Efficiency
SSL比传统的不安全的TCP / IP链接要慢不少。 这个问题是提供足够安全性的直接结果。 当一个新的SSL会话正在创建时，服务器和客户端交换了至关数量的信息，这些信息是他们相互验证和赞成用于会话的密钥所必需的。 最初的握手包括大量使用公钥加密，正如咱们已经提到的那样，这种加密很慢。 这也是使用SSL时最大的放缓。 在当前的高端我的电脑硬件上，OpenSSL在实际工做负载下努力实现每秒100个链接。

一旦初始握手完成并创建会话，开销就会大大下降，但仍然有一部分与不安全的TCP / IP链接相比。 具体来讲，更多的数据传输比正常。 数据以包的形式传输，包含SSL协议所需的信息以及正在使用的对称密码所需的任何填充。 固然，也有加密和解密数据的开销，但好消息是对称密码正在使用，因此一般不是瓶颈。 对称密码的效率能够根据所使用的算法和密钥的强度而有很大的变化。 然而，即便是最慢的算法也是有效的，因此它们几乎不是瓶颈。

因为公钥密码学效率低下，许多人在乎识到没法处理足够大的负载时决定不使用SSL。 有些人根本就没有安全感，这显然不是一个好主意。 其余人试图设计本身的协议来弥补。 这是一个糟糕的主意，由于有不少不明显的缺陷可让你感到困惑。 不熟练的密码员设计的协议不可避免地会有问题。 SSL的设计确实考虑了效率; 它只是不肯意牺牲安全来提升速度。 你应该怀疑使用更高效的协议。

有办法在不放弃协议的状况下改善这个问题。 SSL确实支持链接恢复机制，这样在断开链接以后不久就能够从新链接的客户端能够这样作，而不会产生创建链接的所有开销。 虽然这对于HTTP颇有用，但对于其余协议一般不起做用。

1.3.1.1 Cryptographic acceleration hardware
加速SSL的一种常见方法是使用硬件加速。 许多供应商提供PCI卡，能够从您的处理器卸载加密操做的负担，OpenSSL支持其中大部分。 咱们讨论使用硬件加速的具体细节

1.3.1.2 Load balancing
用于管理SSL效率问题的另外一个受欢迎的选择是负载均衡，即简单地在多个机器之间透明地分配链接，使得该机器群体出于全部意图和目的而做为单个机器出如今外部世界。 这可能比加速卡更具成本效益的解决方案，特别是若是您已经有硬件躺在附近。 然而，负载均衡一般须要更多的工做来确保持久数据随时可用于后端的全部服务器。 负载平衡的另外一个问题是许多解决方案将新的链接路由到任意的机器，这能够消除链接恢复的大部分好处，由于在从新链接期间不多的客户机实际上将链接到原始机器。

一种简单的负载均衡机制是循环DNS，其中多个IP地址被分配给单个DNS名称。 为了响应DNS查找，DNS服务器在发送相同地址两次以前，遍历该DNS名称的全部地址。 这是一个流行的解决方案，由于它是低成本的，不须要特殊的硬件。 链接恢复通常适用于这个解决方案，由于机器每每会保留DNS结果的短时间记忆.

硬件负载均衡器的价格和功能各不相同。 那些可以记住外部机器并经过多个链接将它们映射到同一台内部机器的人每每会更昂贵，并且对于SSL更有效

1.3.2 Keys in the Clear
在典型的SSL安装中，服务器维护凭据，以便客户端能够验证服务器。 除了在链接时提供的证书以外，服务器还维护一个私钥，这对于证明提供证书的服务器实际上呈现本身的证书是必需的。

该私钥须要住在服务器上的某个地方。 最安全的解决方案是使用加密加速硬件。 这些设备中的大多数能够生成和存储密钥资料，而且另外防止私钥被入侵到机器的攻击者访问。 为此，私钥仅在卡上使用，除特殊状况外不容许关闭。

在硬件解决方案不可行的状况下，没有绝对的办法来保护得到root访问权限的攻击者的私钥，由于在处理新的链接时，密钥必须至少在内存中不加密。[4] 若是攻击者拥有root权限，她一般能够将一个调试器附加到服务器进程中，并提取未加密的密钥。

在这些状况下有两种选择。 首先，您能够简单地将密钥保存在磁盘上。 这是最简单的解决方案，可是若是他具备物理访问权限，攻击者的工做也会变得简单，由于他能够关闭计算机并拔出磁盘，或者直接重启到单用户模式。 或者，您可使用密码在磁盘上保存密钥，管理员在SSL服务器启动时必须键入该密码。 在这种状况下，密钥只能在服务器进程的地址空间中未加密，所以对于能够关闭机器并直接访问磁盘的用户是不可用的。

此外，许多袭击者正在寻找低洼的水果，即便他们有这样的技能，他们也不可能追随他们。 这个解决方案的不利之处在于无人参与重启是不可能的，由于不管什么时候机器重启（或者SSL服务器进程崩溃），都必须输入密码，这一般不太实际，特别是在无人环境中。 明显存放钥匙显然不存在这个问题。

不管哪一种状况，最好的防护措施是使用最好的锁定技术（包括物理锁定技术）来保护主机和网络。 这样的解决方案超出了本书的范围。

若是服务器的私钥被泄露，究竟意味着什么？ 最明显的结果是攻击者能够假装成服务器，咱们将在下一节讨论这个问题。 另外一个结果（可能不那么明显）是全部使用密钥的通讯均可能被解密。 若是攻击者可以泄露私钥，攻击者也可能记录了之前的通讯。 解决这个问题的方法是使用临时密钥。 这意味着在建立新的SSL会话时会生成临时密钥对。 而后这被用于密钥交换，并随后被销毁。 经过使用临时密钥，能够实现前向保密，这意味着若是一个密钥受到攻击，用之前的密钥加密的消息将不会受到攻击[5]。 咱们将在第5章更详细地讨论短暂的密钥和前向保密。

1.3.3 Bad Server Credentials
服务器的私钥可能被盗。 在这种状况下，攻击者一般能够假装成服务器而不受惩罚。 此外，认证机构有时也会为欺骗性地表明本身的人签署证书，尽管CA作出了努力来验证全部关于请求证书签名的一方的重要信息[6]。 例如，在2001年年初，VeriSign签署了声称属于微软的证书，但实际上并无。 可是，因为他们已经由一个知名的认证机构签名，因此他们对于验证这些证书签名的任何人都是真实的。

SSL有一个阻止这些问题的机制：证书吊销列表。 一旦证书颁发机构得知证书被盗或签名不当，证书颁发机构会将证书的序列号添加到CRL中。 客户端能够访问CRL并使用CA的证书验证它们，由于服务器使用其私钥签署CRL。

CRL的一个问题是漏洞的窗口可能很大。 一个组织可能须要必定的时间才能意识到私钥可能已经被盗，并通知CA. 即便发生这种状况，CA也必须更新其CRL，这一般不会实时发生（所需时间取决于CA）。 而后，一旦CRL被更新，客户端必须下载它们，以便检测出现的证书已被撤销。 在大多数状况下，客户端永远不会下载或更新CRL。 在这种状况下，被破坏的证书每每会一直受到损害，直至到期。

这种现象有几个缘由。 首先，CRL每每足够大，以至须要花费大量时间进行下载，而且本地可能须要至关大的存储空间，特别是当SSL客户端是具备有限存储容量的嵌入式设备时。 RFC 2560中指定的在线证书状态协议（OCSP）解决了这些问题。 不幸的是，这还不是一个被普遍接受的标准协议，也不会很快成为现实。 此外，普遍部署的惟一版本存在严重的安全问题（请参阅第3章了解更多信息）。 OpenSSL仅在0.9.7版本中增长了OCSP支持，甚至不多有CA甚至提供它做为服务。 其余权威机构能够增量更新CRL，只需最少的下载时间，但该解决方案仍然须要客户端或某种缓存服务器上的空间。

这些解决方案都须要CA的服务器高度可用，若是客户要有最新的信息。 有些客户端将部署在不可能链接到CA的环境中。 另外，查询CA的需求会增长链接时间的显着延迟，这对最终用户是不能容忍的。

因为围绕CRL的许多问题，采起一切可行的措施来确保SSL私钥不被盗用就显得尤其重要。 您至少应该设置入侵检测系统来检测您的私钥的泄露状况，以便您能够快速向CA报告泄密状况。

虽然SSL协议和TLS的第3版被认为是至关安全的（若是正确使用的话），[8] SSLv2（第2版）有基本的设计问题，致使后续版本的普遍变化（版本1从未公开部署）。 所以，您不该该支持该协议的版本2，只是为了确保攻击者不会启动致使客户端和服务器解决协议不安全版本的网络攻击。 您只须要拦截链接请求并发送响应，使其看起来像v3服务器不存在。 而后客户端将尝试使用协议的版本2进行链接。

请注意，服务器一般会根据客户端提供的受支持密码列表挑选密码。 咱们建议在可行的状况下只支持服务器中的强密码。 在其余状况下，确保选择客户提供的最强密码。 咱们将在第5章详细讨论密码选择

1.4 What SSL Doesn’t Do Well

1.4.1 Other Transport Layer Protocols
SSL在TCP / IP上运行良好。 可是，对于不是面向链接的传输层协议（如UDP和IPX），它根本不起做用。 也没有真正的方法来使这种协议工做，不管是。 对不能保证顺序和可靠性的协议的安全加密是一个挑战，而且超出了SSL的范围。 咱们在第6章中概述了加密UDP流量的解决方案。

在第10章中，咱们将讨论如何使用S / MIME签名加密的消息。 经过在发送数据以前签署数据，可使用相同的技术经过SSL发送消息。 或者，能够简单地经过SSL链接发送S / MIME消息以实现相同的结果。

1.5 Securing Third-Party Software

虽然本书的大部份内容都着重于如何使用OpenSSL API来为您的应用程序添加安全性，但您一般会但愿使用OpenSSL来保护其余人的应用程序。 已经构建了许多应用程序来支持OpenSSL。 例如，OpenSSH普遍地使用OpenSSL密码学基础，而且要求在编译以前该库存在。 在这种特殊状况下，安装软件的正常过程将会处理全部的细节，只要你在系统上的一个熟知的地方安装了一个OpenSSL版本便可。 不然，能够在配置软件时明确指定OpenSSL的位置。