先说个背景。最近在给一套基于EasyNVR的安防视频接入平台做例行安全巡检扫描器报了一个高危项服务端TLS配置中仍启用了3DES加密套件。这类问题在流媒体服务里其实挺常见的EasyNVR本身负责RTSP拉流、转码、H5页面播放对外暴露的HTTPS端口走的是内置Nginx弱加密套件一般就藏在Nginx的SSL配置里。我这边从漏洞确认到修复完成、再到验证通过前后花了大半个工作日把过程整理出来给遇到同样告警的朋友做个参考。1. 先搞清楚3DES漏洞到底是什么1.1 3DES加密算法的问题出在哪3DES是Triple DES的简称本质上就是把老的DES算法跑三遍用三个不同的密钥来增加密钥长度。DES本身是1970年代设计的算法密钥只有56位分组长度只有64位放到今天已经非常脆弱。3DES虽然把密钥长度提到了112位或168位但它的分组长度仍然是64位这成了它最大的软肋。问题就出在这个64位分组长度上。如果加密的数据量足够大碰撞攻击也就是常说的Sweet32攻击就能在约320亿次查询中恢复出部分明文信息。这个攻击需要的条件虽然苛刻——攻击者需要截获大量加密流量但对于HTTPS这种长期保持连接、不断传输数据的场景理论上是可行的。所以业界在2016年Sweet32攻击公开之后就基本把3DES判了死刑PCI DSS等合规标准也明确要求禁用。放在EasyNVR的场景里如果管理后台和视频播放页面的HTTPS握手仍然支持3DES套件扫描器就会直接命中这条告警。实际业务影响倒不是说马上会被攻击而是等保测评或客户的安全检查这一关过不去必须整改。1.2 扫描器为什么会报这个漏洞安全扫描器检测3DES的逻辑很直接建立TLS连接时把自己支持的加密套件列表发给服务端如果服务端选择了3DES系列套件就判定为存在风险。常见的扫描器比如Nessus、OpenVAS或者国内一些合规检查工具检测项里都有SSL/TLS弱加密套件这一条。EasyNVR的HTTPS端口通常默认是8443或443具体看部署配置。扫描结果里会明确标出检测到的3DES套件名称常见的有这几种套件名称OpenSSL中的标识TLS_RSA_WITH_3DES_EDE_CBC_SHADES-CBC3-SHATLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHAECDHE-RSA-DES-CBC3-SHATLS_DHE_RSA_WITH_3DES_EDE_CBC_SHAEDH-RSA-DES-CBC3-SHA扫描报告里看到任何一个都说明Nginx的ssl_ciphers配置里没有把3DES排除干净。接下来就是定位配置、确认影响面、动手修复。2. 漏洞影响面分析与修复思路2.1 先评估影响范围别急着改配置修复之前我习惯先做一次影响面评估搞清楚这套EasyNVR对外暴露了哪些端口、哪些业务走了HTTPS。一般来说EasyNVR会有这几个入口管理后台Web界面走HTTPS 8443端口H5视频播放页面走HTTPS 8443端口API接口登录、获取设备列表、拉流地址生成等同样走HTTPS流媒体分发走RTSP/RTMP或HTTP-FLV这部分不涉及TLS但也有部分场景会走WebSocket over TLS。所以3DES漏洞影响的主要是管理后台和H5播放页面的HTTPS握手过程。攻击者如果处在中间人位置理论上可以降级握手、尝试破解加密流量。对于安防监控这种对安全要求高的场景整改是必须的不能拖。另外要确认一点EasyNVR内置的Nginx版本是多少。因为我实际遇到过老版本EasyNVR捆绑的是比较旧的Nginx和OpenSSL有些新配置语法和老版本不兼容。这个决定了后面配置怎么写、TLS版本能开到多高。2.2 修复方案的选型逻辑修复3DES漏洞核心就一句话在Nginx的SSL配置里把3DES套件从密码套件列表中排除同时配置更安全的套件列表和TLS版本。这里有个常见的误区以为把ssl_ciphers改成HIGH:!aNULL:!MD5就够了。实际上HIGH这个关键字在老版本OpenSSL里是包含3DES的必须显式加上!3DES或者用一套明确的现代套件列表。我这次采用的是配置明确套件列表的方式不依赖OpenSSL的关键字分组这样无论扫描器怎么变化返回的套件清单都是可控的。同时要把TLS版本限制在TLSv1.2和TLSv1.3关闭TLSv1.0和TLSv1.1。这两个旧版本本身就是扫描器常报的低版本协议问题顺手一并解决避免下次扫描又冒出新的弱协议告警。修复的整体步骤是这样的备份原始Nginx配置文件确认EasyNVR使用的Nginx配置路径修改ssl_protocols和ssl_ciphers配置校验配置语法并重新加载用openssl和nmap做修复验证回归测试管理后台和视频播放是否正常。3. 修复3DES漏洞的完整实操过程3.1 定位EasyNVR的Nginx配置EasyNVR的安装目录通常是/usr/local/easynvr或者/home/easynvr具体看你是用安装包部署还是Docker部署。我这次遇到的是一台CentOS 7上的传统安装包部署方式Nginx配置在安装目录下的conf/nginx.conf。先找到EasyNVR的进程确认Nginx的配置文件路径# 查看EasyNVR相关进程 ps aux | grep -E easynvr|nginx # 如果看到nginx进程用 -V 或 -T 参数查看配置路径 /usr/local/easynvr/nginx/sbin/nginx -V 21 | head -n 2输出的--conf-path参数会直接告诉你配置文件位置。如果没有这个信息也可以在EasyNVR的安装目录下用find命令搜find /usr/local/easynvr -name nginx.conf -type f拿到配置文件路径后先备份这是所有配置修改前的第一动作cp /usr/local/easynvr/nginx/conf/nginx.conf /usr/local/easynvr/nginx/conf/nginx.conf.bak-$(date %Y%m%d)3.2 修改SSL协议版本和加密套件找到nginx.conf中HTTPS server的配置块重点看ssl_protocols、ssl_ciphers和ssl_prefer_server_ciphers这三项。我这次遇到的原始配置是这样的server { listen 8443 ssl; server_name _; ssl_certificate /usr/local/easynvr/nginx/conf/cert/server.crt; ssl_certificate_key /usr/local/easynvr/nginx/conf/cert/server.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; ... }问题很明显ssl_protocols里带了TLSv1和TLSv1.1ssl_ciphers用的HIGH关键字在旧版OpenSSL里包含了3DES套件。修改后的配置如下server { listen 8443 ssl; server_name _; ssl_certificate /usr/local/easynvr/nginx/conf/cert/server.crt; ssl_certificate_key /usr/local/easynvr/nginx/conf/cert/server.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ... }这里每一个配置项都是有讲究的ssl_protocols TLSv1.2 TLSv1.3只保留现代协议版本。TLSv1.0和TLSv1.1在RFC 8996中已经被标记为废弃扫描器一般也会报ssl_ciphers列表里全都是带GCM或CHACHA20的AEAD套件支持前向保密3DES和CBC模式套件一个都没留ssl_prefer_server_ciphers on让服务端决定使用哪个套件避免客户端把套件降级到不安全的选项ssl_session_cache和ssl_session_timeout是性能优化项视频播放页面频繁建立HTTPS连接的情况下会话复用能明显减少握手开销。注意一个细节如果EasyNVR的Nginx编译时OpenSSL版本较低不支持TLSv1.3ssl_protocols里写了TLSv1.3会导致Nginx启动失败。遇到这个情况把TLSv1.3去掉只保留TLSv1.2就行。判断方法是在服务器上执行openssl version如果OpenSSL版本低于1.1.1那就不支持TLSv1.3。老版本EasyNVR捆绑的OpenSSL有可能就是这种配置前先确认一下。3.3 校验配置并重新加载改完配置不能直接重启先做语法校验/usr/local/easynvr/nginx/sbin/nginx -t -c /usr/local/easynvr/nginx/conf/nginx.conf出现Syntax OK和test is successful字样说明配置没有语法问题。然后平滑重载/usr/local/easynvr/nginx/sbin/nginx -s reload使用reload而不是restart是为了避免重启导致正在播放的视频流出现闪断。平滑重载会先完成旧连接的收尾再切换到新配置实测对在线视频播放的影响很小。如果你部署的是Docker版EasyNVR操作方式略有不同。需要进入容器或者通过挂载方式修改宿主机上的配置文件然后重启容器docker exec -it 容器名 bash # 修改容器内nginx.conf nginx -t nginx -s reload不管哪种部署方式改完配置之后都要做一次业务回归确认管理后台能正常登录、视频页面能正常播放。4. 修复验证与回滚预案4.1 用OpenSSL命令行验证3DES套件已禁用配置重载之后第一时间验证修复效果。先用openssl的s_client命令挨个检查# 验证3DES套件是否已禁用 openssl s_client -connect 127.0.0.1:8443 -cipher DES-CBC3-SHA 21 | grep -E Cipher|error|alert如果修复成功这条命令会返回Cipher is (NONE)或者直接握手失败。最直观的表现是连接被重置输出信息里出现No ciphers enabled相关提示。再验证库里没有3DES残留# 查看当前OpenSSL支持的3DES套件 openssl ciphers -v 3DES | wc -l这只是确认系统OpenSSL里还有3DES定义关键还是看Nginx有没有启用。更准确的方式是用openssl模拟完整握手# 模拟TLSv1.2握手检查协商到的实际套件 openssl s_client -connect 127.0.0.1:8443 -tls1_2 21 | grep Cipher is正常情况下应该返回类似ECDHE-RSA-AES128-GCM-SHA256这样的现代套件。4.2 用nmap做一次全面扫描命令行验证通过之后我用nmap的ssl-enum-ciphers脚本做了一次系统扫描这个结果跟安全扫描器的检测逻辑更接近nmap --script ssl-enum-ciphers -p 8443 127.0.0.1扫描结果会列出所有支持的TLS版本和对应的加密套件。重点看两个地方TLSv1.0和TLSv1.1是否已经彻底消失TLSv1.2下是否还有3DES套件。如果输出里没有任何3DES相关条目协议版本只剩TLSv1.2和TLSv1.3这次修复就算过关了。我在实际扫描中还发现过一个现象nmap的ssl-enum-ciphers输出显示TLSv1.2下有一个DES-CBC3-SHA套件但这时候Nginx配置里明明已经加了!3DES。后来排查下来发现是Nginx配置中存在多个server块扫描器命中的那个server块没有生效新配置。所以改配置的时候一定要检查所有监听8443端口的server块不要只盯着一处改。4.3 服务起不来和业务异常的回退方案配置修改后如果Nginx起不来或者业务出现异常第一时间恢复备份cp /usr/local/easynvr/nginx/conf/nginx.conf.bak-20250101 /usr/local/easynvr/nginx/conf/nginx.conf /usr/local/easynvr/nginx/sbin/nginx -t /usr/local/easynvr/nginx/sbin/nginx -s reload回滚操作很简单所以备份一定不能省。我处理过的项目里遇到最多的回滚场景是客户那边有老旧的摄像头或者老浏览器访问H5播放页时只支持TLSv1.0和3DES一关掉就直接打不开页面了。这种情况最稳妥的做法不是开回3DES而是跟客户沟通升级浏览器或者换用支持新协议的视频客户端。安防这种场景安全合规优先级高于兼容老设备这一点需要提前跟业务方对齐。5. 修复过程中容易踩的坑5.1 密码套件语法不兼容老版本OpenSSL这是我在实践中遇到过最典型的坑。EasyNVR老版本捆绑的OpenSSL可能还是1.0.2甚至更早这个版本不认识TLSv1.3关键字也不支持CHACHA20-POLY1305这类套件。配置里硬写进去Nginx直接起不来。排查方法很简单看Nginx错误日志tail -n 50 /usr/local/easynvr/nginx/logs/error.log如果出现invalid value TLSv1.3或者unknown cipher ECDHE-ECDSA-CHACHA20-POLY1305这类提示说明当前环境不支持这些新特性。解决办法是把TLSv1.3去掉套件列表里只保留OpenSSL支持的GCM套件。先保证服务能起来再考虑后面升级OpenSSL版本的事情。5.2 只改了密码套件没改协议版本有不少人在修复3DES时只把ssl_ciphers里的3DES排除了但ssl_protocols还留着TLSv1.0和TLSv1.1。这样做虽然3DES的告警可能消除了但扫描器很快会报出低版本TLS的告警。TLSv1.0和TLSv1.1同样存在已知漏洞比如BEAST攻击、POODLE攻击在等保和PCI合规里都是必须整改的项。所以修复的时候应该一并处理不要挤牙膏似的今天改一个明天改一个搞得每次扫描都有新告警。我在项目里的习惯是所有SSL配置一次性调整到位协议版本、密码套件、证书、会话缓存都检查一遍减少返工。5.3 多server块配置漏改EasyNVR的nginx.conf里有时候会有多个server块比如一个监听80端口的HTTP跳转配置一个监听8443的HTTPS管理后台还有一个监听其他端口的API服务。如果只在其中一个server块里改了SSL配置其他server块仍然保留旧的套件列表扫描器照样能扫出3DES。处理方法是全局搜索nginx.conf中所有listen ... ssl的server块逐块检查或统一修改。也可以在http块层面配置一份公共的ssl_protocols和ssl_ciphers这样所有server块都会继承http { ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...; ssl_prefer_server_ciphers on; ... }前提是确认所有server块都适合使用同一套策略。如果存在兼容老客户端的特殊场景再单独覆盖。整体上用继承机制管理SSL配置比在多个server块里各写一遍更不容易漏。6. 修复后的验证结果与后续维护6.1 本次修复的验证记录这次修复完成后我做了两轮验证。第一轮是命令行级别的验证用openssl和nmap确认3DES套件和TLSv1.0/1.1已经消失第二轮是业务回归登录EasyNVR管理后台、打开一路摄像头的H5播放页面、拉一次RTSP流转发确认功能正常。验证项修复前修复后TLSv1.0/1.1启用禁用3DES套件存在不存在TLSv1.2现代套件可用可用协商正常管理后台登录正常正常H5视频播放正常正常无闪断扫描器复检高危告警通过第二轮复检我用的是同一款扫描器重新扫了一遍8443端口3DES相关告警消失整体评分提升整个整改闭环完成。6.2 后续维护建议和证书策略修复完成不等于一劳永逸。SSL配置这个东西随着时间推移会有新的漏洞暴露、新的协议标准发布建议建立定期检查的习惯。我自己在维护这类安防流媒体平台时一般按季度做一次安全巡检重点关注几个方向确认没有出现新的弱加密套件配置变更检查TLS证书剩余有效期提前一个月更换避免过期导致播放页面打不开关注EasyNVR官方版本更新新版本通常会在流媒体分发、鉴权、TLS支持上做优化有条件就升级如果平台对外开放了RTSP或RTMP端口检查一下是否有弱口令或未授权访问问题各设备的固件版本保持更新老版本固件可能不支持新的TLS配置。另外如果项目后续要做等保测评TLS配置的整改只是其中一项还需要关注身份鉴别、访问控制、日志留存、数据完整性等要求。从这次3DES漏洞整改入手把整个平台的安全基线一起梳理一遍是最省力的做法。我个人的操作习惯是每次做完这类SSL修复都会把当时的配置改动、验证结果、扫描报告截图归档到一个项目目录里等保测评或客户问起来直接拿出整套材料省去很多解释的功夫。这套EasyNVR的3DES修复核心改动其实就这么几行配置但前前后后的确认、验证、回归流程不能少。照着这个流程走一遍扫描器再报类似弱加密套件问题时处理起来就很顺手了。