HTTPS是否还会被监听

Posted 2021-04-30 郑海山dump

在一个完美部署的HTTPS情况下，监听和篡改是不存在的

这个问题本来是不需要回答的，HTTPS的出现就是为了解决身份的真实性、数据的完整性和保密性，但是在我最近跟有些人聊天中，发现很多人其实对于HTTPS流量是否会被解密还存在一些疑问。包括我刚看到一篇关于隐私的文章，提到银行的科普是不建议使用公共WIFI而使用4G网络，这个不建议的建议是正确的，但是银行系统本身就应该是即使客户处在不安全的通信环境下都可以保障安全，比如加HTTPS，加双因素认证，加行为分析，你不能甩锅给用户要求用户要有很高的安全素养。如果用户被人用枪指着头转账这种情况那才不是你的错。

多说一句，关于银行，我希望银行能通过倒闭或者什么途径尽快升级到无卡交易的模式，双因素认证的磁条卡本身就是异常Bug的存在。还包括数据保存在银行跟“离柜概不负责”霸王条款一样，如果银行服务器维护或者数据库被勒索，你的所有历史交易记录都没法查询到，你的数据以银行记录的为准。

说回HTTPS，我估计为什么还存在这些疑惑，大部分是由于对细节不了解，或者偶尔看到HTTPS解密的某些文章的标题但是没看内容导致的问题。HTTPS是否会被监听？这是可能的，但是会有很多的限制条件，随便举例：

• 上网时有人站在你背后看你屏幕

• 客户端被攻陷，界面被截屏

• 安全工具收集URL判断是否恶意

• 安装了其他的浏览器根CA证书

• 点击了信任Self-signed CA

• 服务器配置错误

• 服务器私钥泄露

• 手握能获得菲尔兹奖的大数分解的算法但是秘而不宣

• HTTPS算法实现上的0day漏洞

• 利用协议的问题实施中间人攻击

• 。。。

效果都是你使用HTTPS但是别人可以知道你和服务器的通信信息。这些都不是HTTPS的错，在一个完美部署的HTTPS情况下，监听和篡改是不存在的。

由于SSL、TLS、HTTPS这几个词语很多情况混用，SSL是早期的版本，TLS是新版，HTTPS是HTTP流量跑在SSL、TLS协议内，我接下来都说成HTTPS好了。

传递2个结论

HTTPS技术细节太多了，说细了没人看，在这里我就传递2个结论：

• 不要被虚假安全迷惑，迷信有了HTTPS就是安全的，这比没有HTTPS更不安全。

• 完美部署的HTTPS，在现在是非常安全的。

HTTPS流量能看到什么

只能看到客户端访问服务器IP和域名，URL都看不到。如果没有SNI的，域名都看不到。当然，通过DPI分析，是可能可以知道一些比如文件大小等信息。

主动调试

有时候我们需要调试HTTPS流量，这时候必须使用代理，这时候实际上是代理和远程服务器通信，代理和远程服务器走的是HTTPS，是不会被监听的，但是代理到你的浏览器或者其他客户端为了信任，需要在客户端安装一个代理的根CA证书或者信任一个不安全的证书，这时候代理就可以把所有流量Log出来。

或者抓包后通过客户端已经保存的各种密钥代入去计算，这篇文章说得比较清楚了。

三种解密 HTTPS 流量的方法介绍

https://imququ.com/post/how-to-decrypt-https.html

协议的选择

协议的选择是客户端和服务端之间共同协商出来的。SSLv2、SSLv3、TLS 1.0、TLS 1.1、TLS 1.2、TLS 1.3，关于HTTPS握手之间的协议选择很多，理论上安全点你应当选择TLS 1.2以上，然而为了兼容性，你可能还需要支持部分较老的协议，较老的协议可能存在被监听的可能。比如SSLv3协议存在POODLE（Padding Oracle On Downgraded Legacy Encryption）攻击。

https://en.wikipedia.org/wiki/POODLE

https://www.infoq.cn/article/2014%2F10%2Fgoogle-ssl3

作为客户端，你应当尽量选择最新版的浏览器，并确保服务器正确配置了协议规则，防止协议降级攻击。

加密套件的选择

在配置服务器的时候类似 ssl_ciphers 的选项，会看到很多类似 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 的字符，这个密码套件的名称包括了协议、密钥交换算法、加密算法、消息认证算法、伪随机函数的结合，需要谨慎选择并随着时间调整的。

完美前向安全

完美前向安全 Perfect Forward Secrecy 的定义是，如果有人保存了你的HTTPS流量，暂时无法解，但是过了很久后拿到服务器密钥，或者后面突然发现了某个密码算法的缺陷，他就可以解开以前的数据。

使用了完美前向安全后，可以保证服务器密钥泄露后，只能通过中间人MITM或者其他方式解开从泄露开始后的流量，但是以前的流量是无法解的。当然完美也只能是现在认为的完美。

SSL协议的缺陷导致了没有完美前向安全，服务器密钥用于身份的认证和数据的加解密，而TLS和正确的加密套件采用了一次一密，密钥只用来身份认证，想了解细节可以看2个协议交互的图就可以很清晰的辨认出来。

TLS & Perfect Forward Secrecy

https://vincent.bernat.ch/en/blog/2011-ssl-perfect-forward-secrecy

会话复用

会话复用的引入加快了HTTPS协商的速度，但是也会引入不安全隐患。会话复用的实现跟Cookie，OAuth2的access token，fresh token类似，使用一个短期保存的状态来代替长期和成本高的协商过程，所以会话复用需要平衡速度和状态保存的时间长度。

自签名证书的使用

HTTPS证书只能基于域名来签发，这导致一些问题是，类似企业或者学校里面，有很多设备都是只有IP或者内部域名，甚至是家用路由器 https://192.168.1.1，如何去要求HTTPS证书？“您的连接不是私密连接”一般都选择直接信任，这会导致非常不好的使用习惯，我不知道这个的最佳解决方案是什么。

Subresource Integrity

再刷新我以前的一个错误，原先我提到为了防止第三方资源被篡改导致网站被攻击，建议通过在本地固化第三方资源来避免，但是实际上有更好的解决方案，就是使用Subresource Integrity，Subresource Integrity对资源进行签名，在HTML标签内嵌入诸如integrity="sha256-cd6357efdd966de8c0cb2f876cc89ec74ce35f0968e11743987084bd42fb8944"使得现代的浏览器会对第三方资源或者托管到CDN的站内资源进行完整性检测，可以放入发布自动化流程内。

如何完美部署HTTPS

很简单，看这个

SSL and TLS Deployment Best Practices

https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices