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

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

作者: Vincent Ke 更新日期: 2022/09/16

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

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粉絲團按讚喔!!