SSL/TLS是一项看似简单的技术。部署简单，正常部署后即可运行。但是安全可靠地部署并不容易。这就使得系统管理员和开发者不得不花费额外的时间和精力去了解SSL/TLS相关技术，这样才能配置出高度安全的服务器或应用。
为了让系统管理员轻松部署安全的站点或应用程序，本文将解释SSL/TLS部署的最佳实践。
一.私人钥匙和证书
在SSL/TLS中，所有的安全性都从服务器的密码标识开始。因此，需要一个强私钥来防止攻击。此外，拥有一个有效且强大的证书也是必不可少的，它可以授予私钥代表特定主机名的权利。没有这两个基本构件，什么都不能保证。
1.1使用2048位私钥
对于大多数网站来说，2048位RSA密钥足以保证其安全性。RSA加密算法的广泛应用使得这种类型的密钥成为默认的安全选择。如果是2048位，这种密钥提供的安全性相当于112位。如果想要比这个更高的安全性，比如128位的安全性，就需要3072位的RSA密钥，但是RSA加密算法的扩展性不是很好，3072位的RSA密钥会影响性能。ECDSA密钥提供了一种替代方案，可以提供更高的安全性和更好的性能。ECDSA密钥为256位，提供128位的安全性。少数老客户不支持ECDSA，但现代客户可以。如果您不介意管理这些设置的开销，您可以部署同时支持RSA和ECDSA加密算法的SSL证书。
1.2保护私钥
私钥是最重要的资产之一，因此有必要限制访问私钥的人数。同时，建议您采取以下策略来保护私钥:
在可信的计算机上生成私钥，建议拒绝CA为您生成私钥。从一开始就对密钥进行安全保护，防止密钥存储在备份系统中时遭到破坏。证书被破坏后，撤销旧证书并生成新的私钥。每年更新SSL证书。如果您采用自动化管理证书，更新频率应更高。有效期较短的证书在实践中更安全。保持证书的公钥与私钥相匹配，否则每当您获得新证书时，还应该生成新的私钥。
1.3确保涵盖所有域名。
请确保您的SSL证书涵盖了您希望用于所有站点的域名，否则无效证书警告将会降低用户对此站点的信任。根据经验，安全的Web服务器应该有这样一个证书，它对指向它的每个DNS名称都有效。
通配符证书有其用途，可以满足更广泛的需求，但在跨团队或跨部门的情况下，使用通配符证书很容易将密钥暴露给很多人。为了控制访问私钥的人数并防止私钥被滥用，在这种情况下请避免使用通配符证书。
确保将所有必要的域名添加到用户可选名称(SAN)中，因为所有最新的浏览器都不会通过检查通用名称来验证。
1.4从受信任的ca获取证书
选择一个认真对待其证书业务和安全性的可信证书颁发机构，即CA。选择CA时，请参考以下标准:
对待安全的态度
。所有 CA 都会接受定期审计，但有些CA比其他CA更重视安全。找出在这方面哪个CA做的更好并不容易，但您可以做的一项是检查他们的安全历史记录，查看CA面对漏洞的反应是怎样，是否从错误中吸取了教训。
提供的服务
。您选择的CA应支持证书吊销列表 (CRL) 和在线证书状态协议 (OCSP) 吊销方法，并具有稳定的网络可用性和高性能。许多站点喜欢使用域名验证型DV证书，但您还应该考站点是否需要扩展验证型EV证书。但无论哪种情况，您都应该选择公钥算法。目前大多数网站都使用RSA算法，但ECDSA可能会因为其性能优势在未来变得重要。
证书管理
。如果您需要大量SSL证书并在复杂的环境中运行，请选择一个可以为您提供良好的管理工具的CA。
注意:为了获得最佳效果，请至少提前一周获取证书，以便可以正常部署和运行。这将有助于避免因计算机时间不准确而导致的证书不安全警告。此外，由于CA需要额外的时间来有效地将新证书发送到OCSP响应，因此最好提前获取证书，以避免证书吊销检查失败。因此，不要等到证书过期后再更换它们。
1.5使用强签名算法
证书的安全性取决于私钥的强度和签名中使用的哈希函数的强度。现在普遍认为SHA1哈希函数的证书是不安全的，所以最好安装使用SHA256哈希函数的证书。
1.6使用DNS CAA
DNS CAA是防止HTTPS证书被错误颁发的安全措施。CAA标准可以允许域名所有者限制可以为其域名颁发证书的CA。如果没有CAA记录，那么任何人都可以为这个域名生成CSR，获得CA颁发的任何证书。使用DNS CAA记录可以减少欺诈证书的发生，从而使网站更加安全。如果CA启用了自动颁发证书的过程，则应该检查DNS CAA记录，这样可以降低错误颁发证书的风险。
建议通过将CAA记录添加到您的证书来将CA列入白名单。添加受信任的CA以向您颁发证书。
二。配置
正确的SSL服务器配置可以向用户正常显示您的网站身份以增强信任，并使用安全加密原语来缓解所有已知缺陷。
2.1使用完整的证书链。
部署SSL证书时，仅有服务器证书是不够的，因此需要两个或更多证书来建立完整的信任链。如果您部署了有效的证书，但缺少必要的中间证书，则会出现常见的配置问题。为了避免这种情况，您需要以相应的顺序部署CA提供的所有证书。
2.2使用安全协议
SSL/TLS系列有六种协议:SSL 2.0、SSL 3.0、TLS1.0、TLS 1.1、TLS 1.2和TLS 1.3:
SSL 2.0不安全，不能使用。SSL 3.0与HTTP一起使用时不安全。它也已过时，建议不使用。TLS 1.0和TLS 1.1已于2020年1月弃用。TLS 1.2 和TLS 1.3都没有已知的安全问题。TLS 1.2或TLS 1.3是目前主要使用的安全协议，因为这些版本提供现代认证加密（也称为AEAD）。如果您的服务器不支持 TLS 1.2或TLS 1.3，那您的网站可能缺乏安全性。TLS 1.3相对来说更加安全，性能更强大。
2.3使用安全的密码套件
为了确保安全通信，您必须首先确保您正在与所需的一方(而不是***的其他人)直接通信，并安全地交换数据。在SSL和TLS中，cipher suite定义了如何进行安全通信。他们是由不同的积木组成的，他们的想法是通过多样性来实现安全。如果发现其中一个构建基块不牢固或不安全，您应该能够切换到另一个构建基块。
目前，我们主要依靠AEAD套件，它提供强认证和密钥交换、前向保密和至少128位加密。可能还有其他较弱的套件支持，前提是它们只与不支持任何更好套件的旧客户端进行协商。以下是一些过时的密码原语，不推荐使用:
ADH套件不提供身份验证。NULL密码套件不提供加密。导出密码套件在连接中协商时不安全，但也可以针对更喜欢更强大的套件（FREAK攻击）的服务器使用。弱密码（112 位或更少位数）的套件很容易被破解，是不安全的。RC4不安全。*** 位分组密码（3DES / DES / RC2 / IDEA）很弱。RSA密钥交换密码套件较弱。
建议使用AEAD或PFS密码套件:
AEAD密码套件-包括CHACHA20_POLY1305, GCM and CCM。PFS密码套件-包括ECDHE_RSA, ECDHE_ECDSA, DHE_RSA, DHE_DSS, CECPQ1和所有的TLS 1.3密码。
以下套件配置是专门为RSA和ECDSA密钥设计的:
注意:建议首先在临时环境中测试TLS配置，只有当您确定一切正常时，才转移到生产环境。请注意，以上为一般列表，并非所有系统(尤其是老系统)都支持所有套件，建议参考SSL服务器配置评级指南进行测试。
上面的配置示例使用标准的TLS套件名称。有些平台使用非标准名称；有关更多详细信息，请参见您的平台的文档。例如，以下套件名称将与OpenSSL一起使用:
2.4选择最佳密码套件
在SSL 3.0和更高版本的协议中，客户端需要提交它们支持的密码套件列表，服务器从列表中选择一个套件进行连接。然而，并不是所有的服务器都能做出最佳选择。一些服务器将从客户端列表中选择第一个支持的套件。因此，只有让服务器主动选择最佳可用密码套件，才能优化SSL部署的安全性。
2.5使用前向保密性
前向保密(也叫完美前向保密，简称PFS)是一种协议功能，它可以不依赖服务器的私钥实现安全对话。如果不使用forward secret密码套件，其他人可以恢复服务器的私钥，并解密所有之前记录的加密会话。ECDHE套件可以在Web浏览器中启用前向隐私。为了支持更广泛的客户端，您还应该使用DHE套件作为ECDHE的备份。除非绝对必要，否则避免RSA密钥交换。
2.6使用强密钥交换
对于密钥交换，公共站点通常可以选择Diffie-Hell***n密钥交换(DHE)或椭圆曲线变体ECDHE。RSA密钥交换被广泛使用，但它不提供前向保密性。当然还有其他的密钥交换算法，但是通常都是不安全的。
2015年，一组研究人员发表了针对DHE的新攻击，他们的工作被称为Logjam attack。研究人员发现，低强度(如768位)的DH密钥交换很容易被破解。为了安全起见，如果部署了DHE，请至少配置2048位。一些旧版本的客户端(如Java 6)可能不支持这个强度级别。与ECDHE相比，ECD HE具有更高的性能和更快的速度。Secp256r1命名曲线(又称P-256)是个不错的选择。
总结
近年来，出现了几次针对SSL和TLS的严重攻击，但是如果您运行的是最新的软件，并且遵循了本指南中针对SSL部署的最佳实践建议，那么您不必太担心这些问题。然而，没有什么是绝对安全的。最好的办法就是密切关注网络安全，及时解决安全漏洞。
有关SSL部署的更多问题，请访问
https://***.racent.com/ssl了解详情！
本文来自北蕭投稿，不代表舒华文档立场，如若转载，请注明出处：https://www.chinashuhua.cn/24/504145.html
微信扫一扫 
