差一個字差很多,HTTP 不等於 HTTPS

差一個字差很多,HTTP 不等於 HTTPS

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

作者: Vincent Ke 更新日期: 2020/10/03

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: 如何修正含有混合內容的網站)

發佈回覆

你的電郵地址並不會被公開。