1 : 问题背景

在项目正常运转过程中，安全部发来一个安全报告，两个中危，裂开了。。。

1.1、SSL/TLS类漏洞-Sweet32 攻击

Sweet32 攻击是一个 SSL/TLS 漏洞，允许攻击者使用 64 位分组密码破坏 HTTPS 连接。
在这里插入图片描述

具体涉及套件：
Cipher suites susceptible to Sweet32 attack (TLS1.0 on port 443):
TLS_RSA_WITH_3DES_EDE_CBC_SHA
解决方案：重新配置受影响的 SSL/TLS 服务器以禁用对废弃 64 位分组密码的支持。

1.2、SSL/TLS类漏洞-弱密码套件

远程主机支持带弱或不安全属性的 TLS/SSL 密码套件。
在这里插入图片描述

具体涉及套件：
Weak TLS/SSL Cipher Suites: (offered via TLS1.2 on port 443):
TLS_RSA_WITH_3DES_EDE_CBC_SHA (Medium strength encryption algorithm (3DES).)
解决方案：重新配置受影响的应用程序以避免使用弱密码套件。

2 : 解决思路

2.1、学习SSL/TLS是什么

额，网上有很多解释，简单来说呢，就是应用程序之间提供身份认证和数据加密的加密协议。也可以说加密算法之类的吧。
参考链接：TLS与SSL之间关系：https://www.cnblogs.com/bonelee/p/10384442.html

2.2、安装检测工具

下载nmap-7.93-setup.exe，双击安装。资源可从网上下载，也可在文末自取。
一键到底安装。
安装好之后，Win + R 输入 cmd，假设要检测的域名是 xxx.com
输入：nmap -sV --script ssl-enum-ciphers -p 443 xxx.com
即可。如图就是没问题的
在这里插入图片描述

2.3、升级OpenSSL

查阅资料，发现需要升级OpenSSL，大概意思是高版本的会默认禁用该加密套件。

1. 确认当前版本，检查是否需要升级openssl version2. 备份旧版本文件mv /usr/bin/openssl /usr/bin/openssl_back3. 创建新目录 进行安装cd /usr/local/openssl4. 将压缩包(openssl-1.1.1.tar.gz)放置该/usr/local/openssl路径下压缩包链接可从网上下载，也可在文末自取。5. 解压安装包(openssl-1.1.1.tar.gz)tar -zxvf openssl-1.1.1.tar.gz 6. 进入解压文件  cd  /usr/local/openssl/openssl-1.1.1分别执行下面两个命令./config --prefix=/usr/local/openssl   #如果此步骤报错,需要安装perl以及gcc包make && make install7. 创建软连接（分别执行一下三个命令）ln -sf /usr/local/openssl/bin/openssl /usr/bin/opensslecho "/usr/local/openssl/lib" >> /etc/ld.so.confldconfig -v8. 查看版本openssl version

版本 1.1.1 及以上，就说明升级成功。

[root@80_19 ~]# openssl versionOpenSSL 1.1.1  11 Sep 2018

为了让nginx和OpenSSL匹配，于是找到了这个网站，只不过没用到而已。
参考链接：自动生成nginx配置：https://ssl-config.mozilla.org/

于是乎，带着期待的心情验证生产环境，但生产环境仍是下面这种样子，可惜可惜。
在这里插入图片描述

2.4、调整加密算法

由于升级OpenSSL不行，不能通过高版本禁用加密算法。
无非就是禁止某些加密算法套件而已嘛，知道是啥意思了，那就开始手动禁用吧。

查阅资料，这个说的好像跟我们这个一模一样啊，开整吧。
参考链接：禁用3DES和DES弱加密算法，保证SSL证书安全：https://huaweicloud.csdn.net/637ee66adf016f70ae4c909f.html
既然要改nginx，那再参考参考吧
参考链接：Nginx 安全优化：https://blog.csdn.net/IT_ZRS/article/details/124459610

老规矩，测试环境先整。
修改nginx配置，增加配置
ssl_protocols TLSv1.2;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-SHA:AES256-SHA;

然后在参数 ssl_ciphers 后增加和减去 DES-CBC3-SHA，观察效果。
如果在添加上 DES-CBC3-SHA 时，会出现那个C的漏洞。
在去掉 DES-CBC3-SHA 时，也就意味着手动禁用，就不会出现漏洞。

于是乎，再次带着期待的心情验证生产环境，但生产环境仍是下面这种样子，可惜可惜。
在这里插入图片描述

3 : 总结

3.1、比较环境的不同

测试环境，域名直接打到nginx上，所以在nginx的配置上修改TSL相关配置，都可以直接在域名中体现，手动设置1.2并排除DES-CBC3-SHA加密算法套件，就可以解决改问题。（2.4可以印证）。
生产环境，开了阿里云的SLB，这导致域名并非直接打到nginx上。
域名先打到SLB上，然后SLB在负载到nginx上，于是基于这种机制，对于nginx的修改，并不会对域名相关的漏洞有影响。
不同点：SLB

参考链接：官网TLS安全策略说明：https://help.aliyun.com/document_detail/90740.html
在这里插入图片描述
上图可以看到SLB的TLSv1.2支持的算法加密套件中有 DES-CBC3-SHA
也就是导致安全漏洞的原因所在了。

3.2、解决该问题

在解决问题的过程中，发现了下面这个链接
参考链接：阿里云的SLB的安全漏洞–TLS弱密码加密算法漏洞：https://blog.csdn.net/m0_37268841/article/details/90715374
额，就很烦，如果早点看到这个链接，能少走很多的弯路啊。

为了解决问题，我们甚至要升级对java8并不友好的 TLSv1.3了，不过改动还挺大，就算了吧
参考链接：Java8支持TLSv1.3协议请求：https://blog.csdn.net/devzyh/article/details/122074632

解决该问题的方式：
方式一（推荐）：
使用自定义的加密算法套件，然后在自定义的加密算法套件中，禁止 DES-CBC3-SHA 加密算法套件。
参考链接：https://help.aliyun.com/document_detail/198572.html
方式二（比较难）：
如果你足够牛*的话，就找阿里云，让他们针对你们的服务来去处理该加密算法套件。
方式三（不推荐）：
升级TLS版本，不过1.3的版本对Java8并不是很支持，要全系统测试一遍，代价比较大，还比较麻烦。

3.3、查阅的资料

支持SSL中等强度密码套件
漏洞描述：
远程主机支持的SSL加密算法提供了中等强度的加密算法，目前，使用密钥长度大于等于56bits并且小于112bits的算法都被认为是中等强度的加密算法。
漏洞解决方案：
升级2021年年度版本或更新版本后，参照SSL/TLS 受诫礼(BAR-MITZVAH)攻击漏洞(CVE-2015-2808)解决方法进行修复（链接如下：https://zhiliao.h3c.com/Theme/details/130547 ），
其中加密套件禁用如下两种：
rsa_aes_256_cbc_sha
dhe_rsa_aes_256_cbc_sha