差一個字差很多，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： 如何修正含有混合內容的網站)