進度條

[不是工程師] 差一個字差很多,HTTP 不等於 HTTPS

多一個"S"真的這麼強?了解HTTP的潛在性危險性

作者: Vincent Ke 更新日期:
「不是工程師」系列是以生活化 / 口語化的方式,
提供科技用詞或是功能另外一種理解的方式,
所以很多用詞與邏輯可能不是那麼的嚴謹,還請見諒。

 

HTTPS是一系列的文章,但是因為發表後才發現有些以為大家都知道的事情其實沒那麼普及(工程師同溫層)
所以發表的順序上面沒有很順暢,比較順暢的順序會是下面所列:

HTTPS 三部曲

1. [不是工程師] 差一個字差很多,HTTP 不等於 HTTPS
2. [不是工程師] 你的網站被顯示為不安全嗎?安裝SSL憑證前你可能會想知道的事!
3. [不是工程師] 為何HTTPS憑證有貴有便宜還更可以免費?讓我們從CA原理開始講起。
 

 

僅管Google已經大力推行HTTPS數餘年了,國內仍有許多網站仍在使用HTTP這個存活20多年的老產物,雖說老車堪開直需開,但除非你保了鉅額保險,誰都不希望開老車的過程中發生意外吧,更何況是一台被黑客們玩壞的老車。

 

 


所以本文的目的,是要先針對HTTP目前現行的風險做一個概觀的介紹,才知道原來HTTP"S"所代表的實質意涵和不可取代性。

 

 

在這裡前情提要一下,HTTP的全名為超文本傳輸協定(HyperText Transfer Protocol,縮寫:HTTP)是一種用於分佈式、協作式和超媒體資訊系統的應用層協議,也是是全球資訊網Internet的資料通訊的基礎。

 

設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。通過HTTP或者HTTPS協定請求的源由統一資源識別元(Uniform Resource Identifiers,URI)來標識,簡單來說,Htttp就是往返“瀏器”與“WEB Server”的通訊協議,在最早的Http 0.9 及 Http1.0裡,僅具備最基本的GET功能,每一Request都會獨立的進行處理,並且在處理結束後就釋放連接,而現在僅管已經多了其他的功能,但安全性的問題一直都是HTTP最大的缺陷,以下條列簡要說明。

 

 

1. 在HTTP協議裏,Web端與Server端進行通訊是使用"明文"的方式,因為HTTP協議本身並不具備加密的功能,所以無法對請求端以及響應端的內容進行加密。


2. 就算今天Web端可以對內容加密,再傳送到Server端解密,但這樣的機制因為並沒有CA以及公鑰基礎建設的基礎,也沒有透過SSL/TLS來做加密的動作,仍然會有被解密的風險。


3. HTTP協議不管是web端還是server端都不會對雙方的身份來進行驗證(例如server端收到請求時,只會要求訊息正確,卻不會去驗證這是不是真的是對應到的web端發出來的,而且server只會對請求做出一次響應),也無法驗證內文的完整性,所以內容很有可能被竊聽或是竄改(也就是你可能不是跟你所想的對象交談)

 

 

關於第三點這裡必須要特別說明一下,由於HTTP協議中,並沒有雙方身分驗證的步驟,所以任何人都可以發送請求,而Server端在接受到每個請求時,也都會做出相對應的回應(當然取決在發送端的ip沒有被server限制),所以如果搭配傳紙條的例子來做搭配,今天在補習班小明想要傳紙條給喜歡的小美時,會有下列幾種狀況:

 

1、無法確認請求發送是否真的發送到Server,因為中間可能被偽裝的Server響應回去:小明傳紙條給小美,結果被途中的小華攔截亂回。


2、無法確認Server的回應是否真的給目標的Client端,因為中間一樣會被偽裝的Client收到:小美傳紙條回去,結果被途中的小華看光,變成小華跟小美聊天,但小美跟小明都不知道。

 

 

也就是說HTTP並沒辦法確認到底是誰傳出的紙條,而又是誰回的紙條,就算今天對談的人是小美跟小明好了,如果小美說那我們交往吧,結果被小華偷塞了一句,但是要先給我五萬元,就代表這原始的對話內容已經被竄改,也就是網頁數據已經經過其他人的有心加工注入數據,這也是著名的「流量劫持」不僅如此,Server端因為對request幾乎是有求必應,所以也無法阻止海量Request的DDoS攻擊。

 

 

更恐怖的還在後面

 

HTTP 傳輸的 Web 網頁中,對於系統設備的授權是「統一的」。這中間也運用到了流量劫持的原理,如果你今天使用一個視訊聊天網站,中間網頁需要訪問你的視訊鏡頭,等到你勾選同意授權時,這頁面在通過某個結點時被有心人士偷塞了一段CODE,但對瀏覽器來看,這仍是你原本網頁的一部分,而這個有心人也自然拿到了你的訪問權了。

 

英劇黑鏡針對這部分也有上演過相關戲碼,但沒看過黑鏡也應該看過冠希吧,嘿嘿!

 

 


而HTTPS(超文本傳輸"安全協定"),就是透過了SSL/TSL去做了一道安全鎖,透過前述提到的andshake(交握)、公鑰基礎設施(也就是公私鑰加密)、CA(第三方身分認證機構)等,來解決前面我們HTTP無法解決的問題。

 

但HTTPS真的就萬無一失,還記得先前提到的貴賓狗事件吧

 

 

而在貴賓狗事件後,在支付產業裡最具盛名的「支付卡產業標準PCI DSS 3.1」,現在開始也下了重要通告,如果你的電子商務網站還在使用SSL/TSL 1.0,也必須全面性進行升級,才能確保在信用卡等敏感資料傳輸上,是否可以符合資安標準,以避免相關資料被竄改或洩漏的可能性。而除了資安外,TTP"S"的差異還有就如同前面所說的,必須要考量SSL/TSL 證書費用以及其他如CA認證費用等等。如果你還在夢想費用低廉的HTTP,我想只能預告你記得多燒香拜佛,以免得不償失。

 

校正小編補充:

補充一下一個SEO的觀點

HTTPS 與HTTP它們之間的不等於是完全不等於
就跟中和的中山路不是板橋的中山路,儘管他們相距沒有幾條街。
在Google的權重裡面,如果沒有特別設定,並不會把http//domain.xxx/1 與 https//domain.xxx/1 當成同一個頁面。


順道一提,http//domain.xxx/1 與 http//www.domain.xxx/1
也不是同一個頁面。
還有如果加上query,例如 http//domain.xxx/1?from=facebook 也會跟上面當成不同的頁面


也就是說如果沒有特別注意的話,在SEO的處理上面會很糟糕。可能單月到一定程度的瀏覽量,本來可以到Google搜尋的首頁,卻因為url完全不同,而導致瀏覽量分散。


當然HTML Meta canonical url有設的話,可以避免掉這件事(Google連結,中文使用還先請自己尋找)


另外,如果有在使用Cache做效能調整,不同的URL一樣會被當成不同的檔案 / 圖片。
所以如果CSS 檔 JavaScript檔 圖片之類的,明明已經換上新的版本,但是網站顯示還是錯誤的。
除了可以要求使用者清除Cache外,一樣可以換上不同的檔名在避免使用者看到舊的資源。


再來HTTPS的網頁如果混合了HTTP的資訊(JS / CSS 檔),瀏覽器會顯示錯誤,要特別小心。
(MDN web doc 混合內容)

 


最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧