全站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 問題。

評論列表(網友評論僅供網友表達個人看法,并不表明本站同意其觀點或證實其描述)

站點導航

您可能在找這些
黑龙江快乐十分走势图