架构栈程序猿阵线联盟-汇总各类技术干货技术干货

聊聊全站HTTPS带来的技术挑战

2017-10-18  本文已影响35人  ForestXie

昨天写的文章里了讨论了数据传输的安全性的问题,最后一部分提到了通过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

上一篇下一篇

猜你喜欢

热点阅读