强制加密通信通道是防御中间人攻击最直接有效的手段，需禁用SSLv2/3及TLS 1.0/1.1，仅启用TLS 1.3并配置ECDHE-ECDSA-AES256-GCM-SHA384等强套件，配合HSTS、301跳转、可信CA证书及DNSSEC等多层加固。

强制加密通信通道是防御中间人攻击最直接有效的手段。它不依赖用户行为或网络环境，而是从协议层切断明文传输路径，让攻击者即使截获流量也无法解密内容。

全链路启用TLS 1.3加密

仅开启HTTPS远远不够，关键在于协议版本和配置质量：

• 禁用所有老旧协议（SSLv2/3、TLS 1.0/1.1），只允许TLS 1.3——它默认启用前向保密，且移除了易受攻击的加密套件
• 在Nginx或Apache中明确指定强加密套件，例如ECDHE-ECDSA-AES256-GCM-SHA384，避免使用RSA密钥交换或CBC模式
• 对Linux服务器，可通过OpenSSL命令验证实际协商结果：openssl s_client -connect example.com:443 -tls1_3

强制跳转与HSTS双保险

防止降级攻击，确保浏览器永远不走HTTP：

• Web服务器配置301重定向，将所有HTTP请求永久跳转至HTTPS
• 响应头中加入Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
• 提交域名至浏览器HSTS预加载列表，使首次访问即强制HTTPS（无需等待首条响应）

证书可信性与固定机制

加密本身不能解决“连对谁”的问题，必须绑定身份：

• 使用受信任CA签发的证书（如Let’s Encrypt、数安时代等），避免自签名或私有CA在生产环境使用
• 启用证书透明度（CT）日志监控，及时发现未授权签发的证书
• 对高敏感客户端（如银行App、IoT设备），实施证书固定（Certificate Pinning），硬编码服务器公钥指纹，绕过系统证书信任链

DNS层加密阻断劫持入口

中间人常从DNS解析环节切入，需同步加固：

• 服务端部署DNSSEC，为域名记录添加数字签名，使解析结果可验证完整性
• 客户端启用DNS over HTTPS（DoH）或DNS over TLS（DoT），例如配置systemd-resolved使用Cloudflare的1.1.1.1或Quad9的9.9.9.9
• 避免依赖本地ISP提供的明文DNS，尤其在公共Wi-Fi等不可信网络中