在项目正常运转过程中,安全部发来一个安全报告,两个中危,裂开了。。。
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 位分组密码的支持。
具体涉及套件:
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 加密算法套件。
参考链接:https://help.aliyun.com/document_detail/198572.html
方式二(比较难):
如果你足够牛*的话,就找阿里云,让他们针对你们的服务来去处理该加密算法套件。
方式三(不推荐):
升级TLS版本,不过1.3的版本对Java8并不是很支持,要全系统测试一遍,代价比较大,还比较麻烦。
支持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
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
有什么不对的还望指正,书写不易,觉得有帮助就点个赞吧!