日前写的文章里了讨论了数据传输的安全性的问题，最后一部分提到了通过HTTPS解决数据传输安全性的方案。那么一个新问题又来了，实施全站HTTPS的过程中，我们可能会遇到哪些技术问题?所以我今天和大家一起来算一下这个账，将技术成本理清楚。
准备工作
- 购买证书 ，网站使用HTTPS需要申请安全证书，目前来说还是比较繁琐的，而且对小公司来说是有一些成本在。另外，一定要选正规的机构，否则你的网站以后使用主流浏览器，如chrome访问，会被提示大大的警告，告诉用户该证书有问题。
- 页面里所有资源都要改成走https ,包括：图片、js、form表单等等，否则浏览器就会报警。
- 确保用到的CDN节点都支持HTTPS ，如果是自建IDC, 必须要保证全国甚至世界范围的 idc 和 cdn 节点，都得覆盖到。
CDN 使用 https 常见的方案有：
- 网站主提供私钥给 cdn，回源使用 http。
- cdn 使用公共域名，公共的证书，这样资源的域名就不能自定义了。回源使用 http。
- 仅提供动态加速，cdn 进行 tcp 代理，不缓存内容。
- 所有的开发、测试环境都要做https的升级 ，确保各级环境保持同一套网络协议。
性能方面的挑战
做好以上的技术准备后，我们还必须意识到实施HTTPS后带来的性能问题：
1.网络耗时增加，简单来说需要多几次握手，网络耗时变长，用户从http跳转到https还要一点时间。
对于这一块的优化，有Session ticket或者Session Cache等优化方案，不过也是各有优缺点。
2.计算耗时增加，需要更好机器性能，https要多做一次RSA校验。
对于这一块的优化，主要的方式是采用最新的openssl协议，使用硬件加速，优先使用ECC密钥等等。
安全方面的挑战
关于这一块，常见的安全隐患包含：降级攻击和重新协商攻击。
对于前者，攻击者伪造或者修改"client hello "消息，使得客户端和服务器之间使用比较弱的加密套件或者协议完成通信。对于重新协商攻击，是攻击者利用协商后安全算法偏弱，试图窃取传输内容，并且可以 不断发起完全握手请求，触发服务端进行高强度计算并引发服务拒绝。
当然，这一块，在基础厂商或者云产商的努力下，对于我们一般的业务用户，几乎不用关心协议层上面安全的问题。我在这里提出的目的，还是想说明一点，安全问题一直都不能放松。
最后一点总结
切换成HTTPS是必然趋势，相信会有越来越多的站点加入进来，而且完成后，它能给我们带来的收益是巨大的。对于我们技术团队而言，在实行之前，一定要考虑清楚它背后的技术成本，并做好对应的技术储备，做好HTTP切换为HTTPS的上线流程，确保万无一失。
原文发布时间为：2017-10-09
本文作者：佚名