前言
在HTTP協議中有可能存在資訊竊聽或身份偽裝等安全問題。使用HTTPS通訊機制可以有效地防止這些問題。本文我們就瞭解一下HTTPS。文章首發地址為我的GitHub部落格，敬請關注！
一、什麼是 HTTPS
HTTPS，是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。 現在它被廣泛用於全球資訊網上安全敏感的通訊，例如交易支付方面。
經常會在Web的登入頁面和購物結算介面等使用HTTPS通訊。使用HTTPS通訊時，不再用http://，而是改用https://。另外，當瀏覽器訪問HTTPS通訊有效的Web網站時，瀏覽器的位址列內會出現一個帶鎖的標記。對HTTPS的顯示方式會因瀏覽器的不同而有所改變。
二、HTTP 與 HTTPS 的區別
- HTTP 是明文傳輸，HTTPS 通過 SSLTLS 進行了加密
- HTTP 的埠號是 80，HTTPS 是 443
- HTTPS 需要到 CA 申請證書，一般免費證書很少，需要交費
- HTTPS 的連線很簡單，是無狀態的；HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網路協議，比 HTTP 協議安全。
為什麼說HTTPS比較安全了，接下我們介紹下HTTP存在哪些問題？
三、HTTP通訊有什麼問題?
1.通訊使用明文（不加密），內容可能被竊聽
由於HTTP本身不具備加密的功能，所以也無法做到對通訊整體（使用HTTP協議通訊的請求和響應的內容）進行加密。即，HTTP報文使用明文（指未經過加密的報文）方式傳送。
此外網際網路是由聯通世界各個地方的網路設施組成,所有傳送和接收經過某些裝置的資料都可能被截獲或窺視。例如大家都熟悉的抓包工具:Wireshark,它可以獲取HTTP協議的請求和響應的內容，並對其進行解析。即使經過加密處理，就有可能讓人無法破解報文資訊的含義，但加密處理後的報文資訊本身還是會被看到的。
2.不驗證通訊方的身份，因此有可能遭遇偽裝
HTTP協議中的請求和響應不會對通訊方進行確認。在HTTP協議通訊時，由於不存在確認通訊方的處理步驟，任何人都可以發起請求。另外，伺服器只要接收到請求，不管對方是誰都會返回一個響應（但也僅限於傳送端的IP地址和埠號沒有被Web伺服器設定限制訪問的前提下）
HTTP協議的實現本身非常簡單，不論是誰傳送過來的請求都會返回響應，因此不確認通訊方，會存在以下各種隱患。比如目標的Web伺服器有可能是已偽裝的Web伺服器。
3.無法證明報文的完整性，所以可能遭篡改
所謂完整性是指資訊的準確度。若無法證明其完整性，通常也就意味著無法判斷資訊是否準確。由於HTTP協議無法證明通訊的報文完整性，因此，在請求或響應送出之後直到對方接收之前的這段時間內，即使請求或響應的內容遭到篡改，也沒有辦法獲悉。
換句話說，沒有任何辦法確認，發出的請求/響應和接收到的請求/響應是前後相同的。
四、HTTPS如何解決上述三個問題?
HTTPS並非是應用層的一種新協議。只是HTTP通訊介面部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）協議代替而已。
通常，HTTP直接和TCP通訊。當使用SSL時，則演變成先和SSL通訊，再由SSL和TCP通訊了。簡言之，所謂HTTPS，其實就是身披SSL協議這層外殼的HTTP。
在採用SSL後，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。也就是說HTTP加上加密處理和認證以及完整性保護後即是HTTPS。
HTTPS 協議的主要功能基本都依賴於 TLS/SSL 協議，TLS/SSL 的功能實現主要依賴於三類基本演算法：雜湊函式 、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和金鑰協商，對稱加密演算法採用協商的金鑰對資料加密，基於雜湊函式驗證資訊的完整性。
（一）解決內容可能被竊聽的問題——加密
1.對稱加密
這種方式加密和解密同用一個金鑰。加密和解密都會用到金鑰。沒有金鑰就無法對密碼解密，反過來說，任何人只要持有金鑰就能解密了。
以對稱加密方式加密時必須將金鑰也發給對方。可究竟怎樣才能安全地轉交？在網際網路上轉發金鑰時，如果通訊被監聽那麼金鑰就可會落人攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的金鑰。
2.非對稱加密
公開金鑰加密使用一對非對稱的金鑰。一把叫做私有金鑰，另一把叫做公開金鑰。顧名思義，私有金鑰不能讓其他任何人知道，而公開金鑰則可以隨意釋出，任何人都可以獲得。
使用公開金鑰加密方式，傳送密文的一方使用對方的公開金鑰進行加密處理，對方收到被加密的資訊後，再使用自己的私有金鑰進行解密。利用這種方式，不需要傳送用來解密的私有金鑰，也不必擔心金鑰被攻擊者竊聽而盜走。
非對稱加密的特點是資訊傳輸一對多，伺服器只需要維持一個私鑰就能夠和多個客戶端進行加密通訊，但伺服器發出的資訊能夠被所有的客戶端解密，且該演算法的計算複雜，加密速度慢。
3.對稱加密+非對稱加密
儘管非對稱加密設計奇妙,但它加解密的效率比對稱加密要慢多了。那我們就將對稱加密與非對稱加密結合起來,充分利用兩者各自的優勢，將多種方法組合起來用於通訊。在交換金鑰環節使用非對稱加密方式，之後的建立通訊交換報文階段則使用對稱加密方式。具體做法是：傳送密文的一方使用對方的公鑰進行加密處理“對稱的金鑰”，然後對方用自己的私鑰解密拿到“對稱的金鑰”，這樣可以確保交換的金鑰是安全的前提下，使用對稱加密方式進行通訊。所以，HTTPS採用對稱加密和非對稱加密兩者並用的混合加密機制。
（二）解決報文可能遭篡改問題——數字簽名
網路傳輸過程中需要經過很多中間節點，雖然資料無法被解密，但可能被篡改，那如何校驗資料的完整性呢？—-校驗數字簽名。
數字簽名有兩種功效：
- 能確定訊息確實是由傳送方簽名併發出來的，因為別人假冒不了傳送方的簽名。
- 數字簽名能確定訊息的完整性,證明資料是否未被篡改過。
校驗數字簽名流程見下圖：
數字簽名技術就是對“非對稱金鑰加解密”和“數字摘要“兩項技術的應用，它將摘要資訊用傳送者的私鑰加密，與原文一起傳送給接收者。接收者只有用傳送者的公鑰才能解密被加密的摘要資訊，然後用HASH函式對收到的原文產生一個摘要資訊，與解密的摘要資訊對比。如果相同，則說明收到的資訊是完整的，在傳輸過程中沒有被修改，否則說明資訊被修改過，因此數字簽名能夠驗證資訊的完整性。
（三）解決通訊方身份可能被偽裝的問題——認證
非對稱加密方式還是存在一些問題的。那就是無法證明公開金鑰本身就是貨真價實的公開金鑰。比如，正準備和某臺伺服器建立公開金鑰加密方式下的通訊時，如何證明收到的公開金鑰就是原本預想的那臺伺服器發行的公開金鑰。
為了解決上述問題，可以使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開金鑰證書。
數字證書認證機構處於客戶端與伺服器雙方都可信賴的第三方機構的立場上。我們來介紹一下數字證書認證機構的業務流程。首先，伺服器的運營人員向數字證書認證機構提出公開金鑰的申請。數字證書認證機構在判明提出申請者的身份之後，會對已申請的公開金鑰做數字簽名，然後分配這個已簽名的公開金鑰，並將該公開金鑰放入公鑰證書後繫結在一起。
伺服器會將這份由數字證書認證機構頒發的公鑰證書傳送給客戶端，以進行非對稱加密方式通訊。公鑰證書也可叫做數字證書或直接稱為證書。
接到證書的客戶端可使用數字證書認證機構的公開金鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事：一，認證伺服器的公開金鑰的是真實有效的數字證書認證機構。二，伺服器的公開金鑰是值得信賴的。
五、為什麼不一直使用HTTPS？
既然HTTPS那麼安全可靠，那為何所有的Web網站不一直使用HTTPS？
其中一個原因是，因為與純文字通訊相比，加密通訊會消耗更多的CPU及記憶體資源。如果每次通訊都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數量必定也會隨之減少。
因此，如果是非敏感資訊則使用HTTP通訊，只有在包含個人資訊等敏感資料時，才利用HTTPS加密通訊。
特別是每當那些訪問量較多的Web網站在進行加密處理時，它們所承擔著的負載不容小覷。
除此之外，想要節約購買證書的開銷也是原因之一。要進行HTTPS通訊，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。