部署全站HTTPS有哪些值得分享的经验和教训? – 龙剑

部署全站HTTPS有哪些值得分享的经验和教训?

干货 admin 来源:知乎 119浏览

部署全站HTTPS有哪些值得分享的经验和教训?

1、前端的最大工作量是为了适配和兼容多协议(HTTPS/HTTP)而进行的资源地址改造。

因为主页为HTTPS时,加载页面所需要的资源都应该支持HTTPS(否则会出现安全风险),这就要求以前只支持HTTP协议的资源同时支持HTTPS,资源越多,改造的工作量越大,越复杂。假如资源只涉及到一两个域名,改起来还比较方便,但考虑到有些资源可能是合作站点,甚至是政府部门时,这个改造可能就比较艰难。当然也会有一些比较奇葩的情况,比如有一些资源地址是写死到HTML里的,有一些是写死在数据库里的,改起来会稍微麻烦点。这就提醒广大前端,尽量考虑到协议兼容和适配,毕竟HTTPS是大势所趋。

2、前端遇到的最大问题是域名收敛和连接复用。

基本上大型网站在HTTP1.1/1.0协议时为了优化访问速度都会做大量的的域名分片和资源合并(比如图片和CSS),但域名分片技术在HTTPS时反而会降低速度,因为HTTPS的握手非常耗费时间。多一个域名意味着多几个HTTPS握手。另外HTTP2和SPDY都有连接复用的特性,资源合并也显得有些多余,把简单的工作复杂化。因此前端进行收敛域名既能减少HTTPS握手又能提升连接复用率,提升页面加载速度。
可以参考但不要完全相信证书检测机构的数据。比如qualys ssl lab。它对证书的检测非常严格非常安全非常理想,导致它的数据有点不切实际。为什么?因为客户端和浏览器的更新赶不上安全技术的发展。比如IE6只支持SSLv3,比如一些客户端只支持aes cbc和rc4。但这些协议和加密算法事实上都不安全了,那网站应该怎么办?特别是在中国市场,你是升级使用最新的协议和加密算法从而导致这些用户不能访问HTTPS呢?(相当于放弃这些客户端和用户 ,比如IE6,7),还是采取折中妥协的办法,使用稍微弱一点的有安全风险的算法,但能够保证用户访问呢?比如SSL3用户只能使用RC4算法。有一些网站就会选择后者,比如google,比如百度,他们在qualys ssl lab的评级都不高。
解决SNI的问题只能依靠多域名证书,也就是把所有需要支持到的域名绑定到一张证书上。由于所有系统都支持多域名和泛域名证书,所以里不存在系统兼容性问题,但这样会存在证书申请和维护的问题,因为一旦域名有新增,就需要重新申请一张全新的多域名证书,并且进行全量部署,成本比较大。但要想从SNI的角度解决这个问题,没有完美的解决方案。因为这依赖于客户端的SSL库是否支持SNI,作为网站或者内容提供方,即使是自有APP都控制不了是否使用SNI,更别提传统浏览器了。不管怎么样,网站服务商肯定需要支持SNI。
查看浏览器是否支持某些特性可以使用这个网站:Can I use… Support tables for HTML5, CSS3, etc。比如SNI,SPDY等。

声明:除非标注“龙剑博客”,文章来源于网络,转载仅用于分享,版权归原作者所有。若涉及侵权,请联系QQ:616338334 。提供贵方版权证明后即刻删除。转载请注明:龙剑 » 部署全站HTTPS有哪些值得分享的经验和教训?