全站HTTPS没你想象的那么简单,电商网站兼顾安全与性能的踩坑小结!

更新:2017-10-25    编辑:语海    来源:geguai    人气:加载中...    字号:|

标签:简单  安全  电商  想象  性能  网站  百度搜索

注:众所周知,数据 HTTP 明文传输历程中,会遇到如劫持、修改、监听、窃取等一系列问题解决这一问题的法子就是做 HTTPS 改造。

全站HTTPS没你想象的那么简单,电商网站兼顾安全与性能的踩坑小结!

HTTPS 的作用是在会话层、表示层引入 TLS/SSL 握手协议,通过数据加密、解密方式,来应对数据明文传输历程中遇到的问题,保障数据的完整性、一致性,为用户带来更安全的网络体验、更好的隐私保护。

然而,HTTPS 增加了 TLS/SSL 握手环节,再加上使用数据传输需要经过对称加密,对性能提出了更大的挑战。

作为一个好的架构,,一定要均衡安全性能两方面,如果让天秤向任何一方倾斜过多,都会影响最终的用户体验。

因此,为了兼顾安全与性能,苏宁全站 HTTPS 改造从 2015 年底开始进行,历时一年多光阴,主要做了系统 HTTPS 改造、HTTPS 性能优化和 HTTPS 灰度上线这三方面工作,让用户在 HTTPS 下造访能够获得极致体验成为了可能。

全站 HTTPS 方案概述

苏宁易购从 2015 年开始规划做 HTTPS 相关的事情,当时可借鉴的资料非常少,电商网站相关的 HTTPS 改造的详尽案例更是难求。

如下图,是苏宁易购全站的 HTTPS 方案:

全站HTTPS没你想象的那么简单,电商网站兼顾安全与性能的踩坑小结!

如图中所示,全部方案分三步构建,分辨是系统改造、性能优化和灰度上线:

HTTPS 方案之系统改造篇

01、HTTPS 接入层定义

系统改造的头等大事是开通 443 端口,成熟的网络系统会包孕 CDN、硬件负载均衡、使用防火墙、Web 服务器、使用服务器,最后到数据层。难道全部链路都要做 HTTPS?在每层都增加 SSL 握手消费吗?答案是否定的。

所以,应该尽早完成 SSL 握手,做 SSL 历程中重要考虑的是 HTTPS 接入层的定位。

如下图,是苏宁易购架构中 HTTPS 接入层的位置:

全站HTTPS没你想象的那么简单,电商网站兼顾安全与性能的踩坑小结!

如图中所示,我们把 HTTPS 接入层放在 CDN 和使用系统之间,采纳四层+七层负载均衡的架构。

四层负载并不处理 HTTPS 卸载,它的主要职责是做 TCP 的分发。在七层负载完成全部 SSL 握手,而后面使用系统走 80 端口,这样就相当于完成了 HTTPS 全部卸载的历程。

这样做的好处,一方面,系统使用层面不需要为 HTTPS 做任何调剂;另一方面,将来所有 HTTPS 的调度、优化和配置都可以在接入层完成。

02、页面资源调换

第一步,理解 Mixed Content

对于一个页面而言,请求页面的请求是用 HTTPS 加载,一旦内部页面元素有 HTTP 的性质,这时 RFC 标准里就会出现一个差错,叫 Mixed Content(混淆差错)。

所以,如果要加载一个安全的 HTTPS 页面,就不应该在其中混淆 HTTP 请求。

第二步,// 调换

用 // 调换 ,这样就可以让页面所有的元素做一个适配,去遵守原来的请求。

第三步,x-request-url 的定义和应用

当然,我们在//调换历程中也遇到了一些坑。举个例子,下图是苏宁易购单点登录系统交互的历程:

全站HTTPS没你想象的那么简单,电商网站兼顾安全与性能的踩坑小结!

如图中所示,当用户 authID 失效,发起请求 https://xxx.suning.com/authStatus 鉴权,接入层会对所有请求做卸载,地址就会变成 HTTP。

进入业务系统做鉴权的话,Reponse 302 就会跳转到单点登录系统。这时会将第二步的页面记载为原始页面,返回到用户端,用户去请求单点登录系统,单点登录系统完成鉴权以后,再回跳时,是 HTTP 地址,最终导致用户端 MixContent。

因此,我们引入 x-request-url 解决问题,如下图:

全站HTTPS没你想象的那么简单,电商网站兼顾安全与性能的踩坑小结!

所有原始请求协议都记载在 x-request-url 中,如果业务系统鉴权,一定要遵守 x-request-url 记载的协议,就可应对回跳导致的用户端 Mix Content 问题。

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)

站点导航

您可能在找这些