系统管理员如何快速高效的部署SSL和TLS？

SSL/TLS是一种简单易懂的技术，很容易部署，也很容易运行。不过存在主要的问题是加密不太容易部署，为了确保TLS提供必要的安全性，系统管理员和开发人员必须花费很大的精力来正确配置其服务器并开发相应的应用程序。所以，我们的目标就是帮助管理员和程序员减少在部署安全站点或Web应用程序上的巨大消耗。

1 私钥和证书

在TLS中，所有安全性都以服务器的加密身份开始，这就需要一个强大的私钥来防止攻击者进行模拟攻击。同样重要的是拥有一个有效和强大的证书，它会授予私钥来代表一个特定的主机名。

1.1使用2048位私钥

对于大多数网站都来说，由2048位RSA密钥提供的安全性就已经足够了。 由于RSA公钥算法应用广泛，从而使得它成为安全的默认选择。对于2048位的RSA密钥来说，能够提供大约112位密钥。如果你想要更高的安全性， RSA密钥则不能很好地进行扩展。比如，要获得128位的密钥，就需要3072位的RSA密钥，这显然运行较慢。 椭圆曲线数字签名算法ECDSA显示为你提供了更好的安全性和更好的性能。以ECDSA256为例,，ECDSA密钥提供了128位的密钥。

1.2保护私钥

为了保护你的私钥产，我们提供了以下5条建议：

（1）要在具有足够熵的可信计算机上生成私钥。

（2）从一开始就要为密钥设置密码保护，以防止在存储到备份系统中时受到攻击。私钥密码在实际运行中不会有太大的安全保障，因为攻击者完全可以随时从进程内存中检索密钥。利用硬件设备（硬件安全模块或HSM），即使在服务器受损的情况下也可以保护私钥，但是这些设备是昂贵的，因此仅适用于对安全有严格安全性要求的机构。

（3）被攻击后，撤销旧证书并生成新密钥。

（4）每年更新证书，最好你的设备可以自动执行此过程，因此具有较短使用周期的证书在实践中更为安全。

（5）除非特殊情况，否则每当获得新证书时，就应该生成相应的新私钥。

1.3确保证书覆盖所使用的网站

确保你的证书覆盖你所使用的网站，避免无效的证书警告。

即使你只有一个域名，你也应确保证书与www前缀有关，例如，example.com和www.example.com。安全的Web服务器的每个DNS名称都应该配置一个有效的证书。

还有访问私钥的人越少越好，要注意的是，证书共享会创建一个绑定，可以将漏洞从一个网站或服务器传输到使用相同证书的所有其他站点和服务器（即使底层私钥不同）。

1.4从可靠的CA获取证书

选择从可靠的CA获取证书，选择CA时，请注意以下5方面：

（1）所有CA的安全状态都要经过定期审核，建议你查看不同CA的安全历史，更重要的是，他们如何对攻击作出应对。

（2）选择那些把CA作为重要业务的机构

（3）你选择的CA应提供证书吊销列表（CRL）和在线证书状态协议（OCSP）撤销的支持，另外，你还应该考虑是否需要扩展验证（E）证书，大多数网站目前都使用RSA，不过ECDSA在未来可能会变得更加重要。

（4）如果你需要大量证书并在复杂的环境中运行，请选择能为你提供良好的CA管理工具的机构。

（5）选择能为提供各种功能支持的CA。

1.5使用强大的证书签名算法

证书安全性取决于用于签署证书的私钥的强度及签名中使用的哈希函数的强度。原来大多数证书都依赖于SHA1散列函数，不过现在已经证实这是不安全的。因此，目前的趋势是正在向SHA256转型。截止2016年底，SHA1证书将不再被网站支持。

2 配置

使用正确的TLS服务器配置，就可以确保将登录凭证正确地呈现给站点的访问者，使用安全的加密原语，能减少所有已知的漏洞。

2.1使用完整的证书链

在大多数部署中，只有服务器证书需要两个或多个证书来建立完整的信任链。如果只具有有效证书但没有必要的中间证书时，服务器就会发生常见的配置问题。为避免这种情况，就需使用CA提供给你的所有证书。

无效的证书链会让服务器证书无效并导致浏览器发出安全警告，实际上，这个问题有时候很难判断，因为有些浏览器可以重建不完整的链，而有些浏览器则不能重建。所有浏览器都倾向于缓存和重用中间证书。

2.2使用安全协议

SSL/TLS系列中有五种协议：SSL 2，SSL 3，TLS 1.0，TLS 1.1和TLS 1.2。SSL 2最不安全，请你不要使用。此协议版本设计的非常糟糕，即使它们位于完全不同的服务器（DROWN攻击）上也可以用来攻击具有相同名称的RSA密钥和站点。

由于SSL 3已经非常老了，所以当与HTTP（POODLE攻击）一起使用时，SSL  3非常不安全的，建议不要使用。

从理论上来讲，TLS 1.0也不应该被使用，但在实践中经常被使用。其主要弱点（BEAST）已在目前的浏览器中得到缓解，但其他问题仍然存在。

截至目前，TLS 1.1和 1.2都还没有什么安全问题，但只有 1.2提供了现代的加密算法。所以TLS 1.2应该是被使用的主要协议，因为它是唯一提供现代认证加密（也称为AEAD）的版本。不过从实际考虑，目前一些较老的客户端仍支持TLS 1.0。 但是，建议大家还是尽快淘汰TLS 1.0。 例如，支付卡行业数据安全标准PCI DSS将要求所有接受信用卡付款的网站在2018年6月之前放弃对TLS  1.0的支持。

目前IETF正在对TLS 1.3进行紧锣密鼓的研制，其目的是消除所有过时和不安全的功能，让未来几十年内的通信都处于安全状态。

与之前版本类似，TLS 1.3协议可分为握手协议和记录协议，前者负责密码组件的协商以及安全信道的建立，后者则是在已建立的安全信道中传输秘密信息。TLS 1.3设计的第一个重要目标就是避免之前版本存在的缺陷，比如禁用RSA密钥传输算法、禁用一些安全性较弱的密码原语如MD5的使用、不再支持重协商握手模式、握手消息采取了加密操作、实现了握手协议和记录协议的密钥分离、记录层只能使用AEAD（Authenticated Encryption with Additional Data）认证加密模式……

2.3使用加密套件

要确保通信的安全，你必须首先确定能与通信对象直接进行通信并安全地交换数据。在SSL和TLS中，加密套件就是服务器和客户端所使用的加密算法的组合，它明确了SSL握手阶段和通信阶段所应该采用的各种算法。通常加密套件包含3种算法，第一个是密钥交换，这个会使用非对称加密算法来生成会话密钥，因为非对称算法不会将重要数据在通信中传输；第二个是对称加密算法，主要是对传输的数据进行加密传输用的，如果性能允许，这里可以不需要，因为非对称加密算法太耗性能，再者有些非对称加密算法有内容长度的限制，所以真正要传输的数据会使用对称加密来进行加密；第三个是会话校验算法，为了防止握手本身被窜改（这里极容易和证书签名算法混淆）。

不过目前要主要依靠提供强身份验证和密钥交换的算法，使用至少128位加密的AEAD加密算法套件。

不过有几个过时的加密原语必须禁止使用：

（1）匿名Diffie-Hellman（ADH）套件不提供身份验证。
（2）NULL加密套件不提供加密。
（3）导出加密套件在连接协商时不安全，但也可以针对更强大的套件（FREAK攻击）的服务器使用。
（4）弱密码（通常为40和56位）的套件使用可以轻松被攻击。
（5）RC4是不安全的。
（6）3DES运行缓慢且易被攻击。

使用以RSA和ECDSA键为对象的以下套件配置作为起点：

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

我们建议你先在临时环境中测试你的TLS配置，只有确定一切正常工作时再进行协议的更改。请注意，以上只是一个通用列表，并不是所有系统（特别是较旧的）都支持所有套件，这就是为什么要先进行测试。

上述示例配置使用的就是标准TLS套件名称，但一些平台使用的是非标准名称，例如，以下套件名称将与OpenSSL一起使用：

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256

2.4选择最佳加密套件

在SSL  3及更高版本的协议版本中，客户端会先提交一系列支持的加密套件，服务器从列表中选择一个用于连接的套件。然而，并不是所有的服务器都能执行此操作，有些会固定的从客户端列表中选择第一个支持的套件，所以服务器主动选择最佳可用加密套件对于实现最佳安全性至关重要。

2.5使用前向保密

前向保密(Forward Secrecy)，有时也称为完美前向保密(Perfect Forward Secrecy)，是一种协议函数，可以实现不依赖服务器私钥的安全通信。它为客户端和服务器端提供了一种为会话创建共享密钥的办法，而这个密钥不会暴露给任何监测数据交换的人（即便监测者能够得到服务器的私钥，只要它只是个监测者而不是中间人）。使用ECDHE套件，以便通过网络浏览器进行前向保密。为了让前向保密得到更广泛的使用，你还应该使用DHE套件作为ECDHE的协商回退(fallback)方案。再次提醒，尽量避免使用RSA密钥交换。

2.6使用强大的密钥交换

对于密钥交换，公共站点通常可以选择经典的临时的Diffie-Hellman密钥交换（DHE）和椭圆曲线(ECC)的DH算法。还有其他的密钥交换算法，但是它们通常都不安全。 RSA密钥交换仍然很受欢迎，但不提供前向保密。

2015年，研究人员发现一个SSL加密安全漏洞LogJam，LogJam漏洞将影响任何支持DHE_EXPORT密码的服务器及所有浏览器，包括最新版的IE、Chrome、Firefox、Safari等。随后他们评估称学术派黑客可以破解768位的密钥，而国家支持的黑客更可以突破1024位的密钥。所以为了安全起见，如果部署DHE，至少要配置2048位的密钥。一些较老的客户端（例如Ja a 6）可能不支持这种高强度的加密。出于性能原因，大多数服务器应该更喜欢ECDHE，它们更强大，运行更快。在这种情况下，椭圆曲线算法secp256k1（也称为P-256）就是一个很好的选择。

2.7将威胁将至最低

近年来，对SSL和TLS发生了几次严重的攻击，在此，我们建议大家运行最新的软件并遵循本问中的建议。

3 性能

虽然安全是本文所讲的重点，但前提是要具备实用性的需要，否则我们不会为大家推荐的。通过正确配置以后，TLS运行可以相当快。使用最新的协议（例如HTTP/2），甚至可能比明文通信更快。

3.1避免一味的追求过高的安全性

使用太短的密码肯定是不安全的，但使用太长的密码也不一定安全，比如会导致操作的复杂。对于大多数网站来说，使用强于2048位的RSA密钥以及使用强于256位的ECDSA密钥会浪费CPU功耗，并可能会损害用户体验。类似地，增加临时密钥交换的强度对于DHE为2048位以及ECDHE为256位几乎没有什么好处，使用高于128位的加密也没有明显的好处。

3.2使用会话重用机制

会话重用机制是一种性能优化技术，SSL 会话重用机制的原理就是在服务端缓存所有的会话，客户端之后在每次和服务端握手时通过会话 ID完成会话重用机制，这是一种节省内存的机制。

3.3使用WAN优化和HTTP/2

其实TLS的运行性能的降低不是来自CPU进行高强度的加密操作，而是来自网络延迟。因为只有在TCP握手完成之后才能启动TLS握手，除此之外，还需要进一步交换数据包，通常跨接很大的物理范围。最小化延迟的最佳方法就是避免创建新的连接，换句话说，就是保持现有的连接时间足够长（keep-alives）。另外，提供良好优化效果的其他技术还包括最新的协议（如HTTP / 2）和使用WAN优化。

3.4缓存公共内容

通过TLS进行通信时，浏览器可能会把所有流量都视为敏感数据。这样，它们通常会使用内存来缓存某些资源，但一旦关闭浏览器，所有内容都可能会丢失。为了获得性能提升并实现对某些资源的长期缓存，可以将公共资源（例如图像）标记为公开。

3.5使用OCSP闭合

OCSP闭合(OCSP Stapling)是OCSP协议的扩展，这个技术节省了在客户端和OCSP响应者之间的一个来回，可以直接从服务器提供撤销信息作为TLS握手的一部分。因此，客户端不需要联系OCSP服务器进行带外验证，并且总体TLS连接时间显着减少。但并不是所有的网络服务器都提供了OCSP闭合技术。

3.6使用快速加密原语

尽可能使用支持硬件加速AES的CPU，如果你真的想要进一步提高性能，请考虑使用ECDSA密钥。

4 HTTP和应用安全

HTTP协议和应用交付平台在SSL诞生后快速发展。目前，应用交付平台的加密功能已经可以超过一般的秘钥了。下面我们就列出了这些功能，以及安全使用它们的方法。

4.1加密一切

加密的问题可能是当今最大的安全问题之一，比如：

（1）没有TLS的网站

（2）具有TLS但不执行TLS的站点

（3）混合了TLS和非TLS内容的网站，有时甚至在同一网页内

（4）编程错误的网站会破坏TLS

4.2消除混合内容

混合内容页面是通过TLS传输但是包含不通过TLS传输的资源（例如，JavaScript文件、图像、CSS文件）的页面。这样的页面非常不安全，这些不受保护的JavaScript资源会被中间人攻击所利用，例如劫持整个用户会话。即使你加密了整个网站，仍然可能会从第三方网站中检索出未加密的一些资源。

4.3了解并信任第三方

多数网站都是通过从另一台服务器下载的JavaScript代码来激活的第三方服务比如Google Analytics。包含第三方代码的网站会创建一个隐含的信任连接，有效地使对方完全控制你的网站。虽然第三方连接可能不是恶意的，但是这些服务背后的厂商可能被攻击，比如，如果一个服务器被攻击，那攻击者将自动访问所有依赖该服务器的站点。

如果你遵循第4.2的建议，至少你的第三方链接将被加密，从而避免MITM攻击。目前子资源完整性（SRI）可用于第三方资源减少潜在的风险，它是一项安全功能，可让浏览器验证其抓取的文件 (例如，从一个 CDN) 是在没有意外操作的情况下传递的。它的工作原理是允许您提供一个获取的文件必须匹配的加密哈希。

4.4安全Cookie

为了在保持性能的前提下，实现安全，网站需要TLS，而且所有的Cookie在创建时都被明确标记为安全的。否则就有可能被MITM攻击者利用，建议大家为你的Cookie添加加密完整性验证。

4.5安全的HTTP压缩

CRIME攻击通过利用压缩过程中的漏洞，可解密部分安全连接。而禁用TLS压缩可防止这种攻击。另外要注意，HTTP压缩可能被TIME和BREACH攻击利用。CRIME允许攻击者恢复HTTP的请求头,其中包含cookies和其他身份验证数据,而BREACH着力于另一个方向——使用压缩边信道攻击影响HTTP响应。与TLS压缩不同，HTTP压缩是必需的，不能关闭。因此，为了解决这些攻击，需要对应用程序代码进行更改。

TIME和BREACH攻击并不容易实现，但如果能实现，其攻击力相当于跨站请求伪造（CSRF）攻击。

4.6如何配置使用 HTTP 严格传输安全(HSTS)

HTTP 严格传输安全（HSTS）是一种安全功能，web 服务器通过它来告诉浏览器仅用 HTTPS 来与之通讯，而不是使用 HTTP。

要激活HSTS保护，你可以向你的网站添加一个新的响应头。之后，支持HSTS的浏览器就会执行它。

简单地说HSTS被激活后，它不允许与使用其网站进行任何不安全的通信。通过自动将所有明文链接转换为安全的链接，来实现了这一目标。

建议大家添加对HSTS的支持，这是为TLS安全性做出的最重要的保障。为了获得最佳安全效果，请考虑使用HSTS预加载，将HSTS配置嵌入到浏览器中。只要是在有效期内，浏览器都将直接强制性的发起HTTPS请求，但是问题又来了，有效期过了怎么办?其实不用为此过多担心，因为HSTS Header存在于每个响应中，随着用户和网站的交互，这个有效时间时刻都在刷新，再加上有效期通常都被设置成了1年，所以只要用户的前后两次请求之间的时间间隔没有超过1年，则基本上不会出现安全风险。

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

4.7部署内容安全策略

内容安全策略（CSP）是网站可以用来限制浏览器操作的安全机制。虽然最最初用意在于解跨站脚本攻击 (XSS) 和数据注入等攻击，但随着CSP不断发展，它目前不但可以支持TLS的安全性还能防止HTTPS混合内容错误并帮助改进HTTPS支持。

要部署CSP以防止第三方混合内容，请使用以下配置：

Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval';
                         connect-src https: wss:

不过这不是部署CSP的最佳方法，为了方便本文的讲解，我们不得不禁用某些默认安全功能。

4.8禁用敏感内容的缓存

由于使用基于云的应用平台正在增加，所以为了让所有敏感内容只让接收方收到，你必须小心对敏感内容作出处理。

5正确部署前的验证

也许在按着本文的方法在进行部署时，许多软件和硬件配置都有了新的版本，建议大家先对自己的SSL / TLS做个全面评估，以确保运行的安全。推荐大家使用此链接https://www.ssllabs.com/进行测试。