昨天写的文章里了讨论了数据传输的安全性的问题，最后一部分提到了通过HTTPS解决数据传输安全性的方案。那么一个新问题又来了，实施全站HTTPS的过程中，我们可能会遇到哪些技术问题？所以我今天和大家一起来算一下这个账，将技术成本理清楚。

准备工作

1.购买证书，网站使用HTTPS需要申请安全证书，目前来说还是比较繁琐的，而且对小公司来说是有一些成本在。另外，一定要选正规的机构，否则你的网站以后使用主流浏览器，如chrome访问，会被提示大大的警告，告诉用户该证书有问题。

2.页面里所有资源都要改成走https,包括：图片、js、form表单等等，否则浏览器就会报警。

3. 确保用到的CDN节点都支持HTTPS，如果是自建IDC, 必须要保证全国甚至世界范围的 idc 和 cdn 节点，都得覆盖到。

CDN 使用 https 常见的方案有：

1 网站主提供私钥给 cdn，回源使用 http。

2 cdn 使用公共域名，公共的证书，这样资源的域名就不能自定义了。回源使用 http。

3 仅提供动态加速，cdn 进行 tcp 代理，不缓存内容。

4. 所有的开发、测试环境都要做https的升级，确保各级环境保持同一套网络协议。

性能方面的挑战

做好以上的技术准备后，我们还必须意识到实施HTTPS后带来的性能问题：

1.网络耗时增加，简单来说需要多几次握手，网络耗时变长，用户从http跳转到https还要一点时间。

对于这一块的优化，有Session ticket或者Session Cache等优化方案，不过也是各有优缺点。

2.计算耗时增加，需要更好机器性能，https要多做一次RSA校验。

对于这一块的优化，主要的方式是采用最新的openssl协议，使用硬件加速，优先使用ECC密钥等等。

安全方面的挑战

关于这一块，常见的安全隐患包含：降级攻击和重新协商攻击。

对于前者，攻击者伪造或者修改”client hello “消息，使得客户端和服务器之间使用比较弱的加密套件或者协议完成通信。对于重新协商攻击，是攻击者利用协商后安全算法偏弱，试图窃取传输内容，并且可以不断发起完全握手请求，触发服务端进行高强度计算并引发服务拒绝。

当然，这一块，在基础厂商或者云产商的努力下，对于我们一般的业务用户，几乎不用关心协议层上面安全的问题。我在这里提出的目的，还是想说明一点，安全问题一直都不能放松。

最后一点总结

切换成HTTPS是必然趋势，相信会有越来越多的站点加入进来，而且完成后，它能给我们带来的收益是巨大的。对于我们技术团队而言，在实行之前，一定要考虑清楚它背后的技术成本，并做好对应的技术储备，做好HTTP切换为HTTPS的上线流程，确保万无一失。

扫描二维码或手动搜索微信公众号【架构栈】： ForestNotes

欢迎转载，带上以下二维码即可