在项目正常运转过程中，安全部发来一个安全报告，两个中危，裂开了。。。
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 位分组密码的支持。
远程主机支持带弱或不安全属性的 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).)
解决方案：重新配置受影响的应用程序以避免使用弱密码套件。
额，网上有很多解释，简单来说呢，就是应用程序之间提供身份认证和数据加密的加密协议。也可以说加密算法之类的吧。
参考链接：TLS与SSL之间关系：https://www.cnblogs.com/bonelee/p/10384442.html
下载nmap-7.93-setup.exe，双击安装。资源可从网上下载，也可在文末自取。
一键到底安装。
安装好之后，Win + R 输入 cmd，假设要检测的域名是 xxx.com
输入：nmap -sV --script ssl-enum-ciphers -p 443 xxx.com
即可。如图就是没问题的
查阅资料，发现需要升级OpenSSL，大概意思是高版本的会默认禁用该加密套件。
1. 确认当前版本，检查是否需要升级
openssl version
2. 备份旧版本文件
mv /usr/bin/openssl /usr/bin/openssl_back
3. 创建新目录 进行安装
cd /usr/local/openssl
4. 将压缩包(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 install
7. 创建软连接（分别执行一下三个命令）
ln -sf /usr/local/openssl/bin/openssl /usr/bin/openssl
echo "/usr/local/openssl/lib">>/etc/ld.so.conf
ldconfig -v
8. 查看版本
openssl version版本 1.1.1 及以上，就说明升级成功。
[root@80_19 ~]# openssl version
OpenSSL 1.1.1 11 Sep 2018为了让nginx和OpenSSL匹配，于是找到了这个网站，只不过没用到而已。
参考链接：自动生成nginx配置：https://ssl-config.mozilla.org/#server=nginx&version=1.15.8.3&config=intermediate&openssl=1.1.1&guideline=5.6
于是乎，带着期待的心情验证生产环境，但生产环境仍是下面这种样子，可惜可惜。
由于升级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 时，也就意味着手动禁用，就不会出现漏洞。
于是乎，再次带着期待的心情验证生产环境，但生产环境仍是下面这种样子，可惜可惜。
测试环境，域名直接打到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
也就是导致安全漏洞的原因所在了。
在解决问题的过程中，发现了下面这个链接
参考链接：阿里云的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 加密算法套件。
方式二（比较难）：
如果你足够牛*的话，就找阿里云，让他们针对你们的服务来去处理该加密算法套件。
方式三（不推荐）：
升级TLS版本，不过1.3的版本对Java8并不是很支持，要全系统测试一遍，代价比较大，还比较麻烦。
OpenSSL：https://pan.baidu.com/s/1RNsZojB45uZHGyVqyJjrjQ?pwd=3vya
提取码: 3vya
nmap-7.93-setup：https://pan.baidu.com/s/1zTax5nI8whstaFqYnmqQ0A?pwd=aviv
提取码: aviv
nmap-7.93-setup: https://download.csdn.net/download/qq_38254635/87349350
有什么不对的还望指正，书写不易，觉得有帮助就点个赞吧！
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
