寫在前面
最近在看了解HTTP相關的一些知識，主要在看《圖解HTTP》這本書，感覺還不錯。所以結合自己的理解，做一下筆記。話說之前還大概過了下《HTTP權威指南》，感覺這本書內容過多了，不太適合新手看。新手還是建議看《圖解HTTP》。
什麼是HTTPS
HTTPS(全稱：Hyper Text Transfer Protocol over Secure Socket Layer)，是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。
HTTPS在應用層(HTTP)和傳輸層(TCP)之間加入了一個安全層(SSL或TLS)。目的是爲了解決HTTP協議的幾個缺點：
- 通信使用明文(不加密)，內容可能會被竊聽。
- 無法證明報文的完整性，所以有可能早已篡改。
- 不驗證通信方的身份，因此有可能遭遇僞裝。
HTTPS是位於安全層之上的HTTP，這個安全層位於TCP之上
HTTP的幾個缺點
通信使用明文(不加密)，內容可能會被竊聽。
HTTP協議並沒有對通信以及數據進行加密，是明文發送的。而我們使用HTTP請求的時候，數據會經過許多個路由器，代理之類的設備，在這個過程中，只要有人在某一個環節抓取了數據包(這個操作並不難)，那這個請求的數據就會被看到。如果請求裏面有一些重要的數據，比如銀行卡賬號、手機號、密碼等信息，就會有泄露的風險。
無法證明報文的完整性，所以有可能早已篡改。
由於HTTP協議無法證明通信的報文完整性，因此，在請求或響應送出之後直到對方接收之前的這段時間內，即使請求或響應遭到篡改，也沒有辦法獲悉。
換句話說，沒有任何辦法確認，發出的請求/響應和接收到的請求/響應是相同的。
數據在傳輸過程中可能會遭到篡改
不驗證通信方的身份，因此有可能遭遇僞裝。
HTTP協議的實現本身非常簡單，不論是誰發過來的請求都會返回響應，因此不確認通信方，會存在以下隱患：
- 無法確認請求發送至目標的Web服務器是否是按真實意圖返回響應的那臺服務器。有可能是僞裝的Web服務器。
- 無法確認響應返回到的客戶端是否是按真實意圖接收響應的那個客戶端，有可能是僞裝的客戶端。
- 無法確定正在通信的對方是否具備訪問權限，因爲某些Web服務器上保存着重要的信息，只想發給特定用戶通信的權限。
- 無法判斷請求是來自何方，出自何手。
即使是無意義的請求也會照單全收。無法阻止海量請求下的DoS攻擊。
HTTP+加密+完整性保護+認證=HTTPS
我們來看下HTTPS是如何解決上面的問題的。
使用通信加密解決HTTP的明文發送問題
不同於HTTP的明文通信，HTTPS的通信是經過加密的。所以，就算有人在通信的過程中抓取到了數據包，因爲沒有密鑰，所以無法知道數據包的具體內容，這樣可以對傳輸的數據進行保護。
HTTPS中，網絡傳輸的數據(請求和響應)都是經過加密的
HTTPS通信中，客戶端和服務器都會有兩個相同的通信密鑰(設爲密鑰A)，客戶端發送請求時，會使用密鑰A對請求進行加密成密文，服務器接收到請求之後，會使用密鑰A對請求內容進行解密，得到客戶端發送的明文，進行處理。響應過程也相似。
因此，在網絡傳輸的過程中，因爲數據被加密了，所以就算有人獲取到了數據包，因爲沒有密鑰A，所以就無法解密出數據包的內容，看到的是一堆亂碼。
像這種加密和解密都是使用同一個密鑰的加密方式叫做對稱加密(也叫共享加密，共同擁有一個密鑰)。使用密鑰A加密的內容，只能用密鑰A來解密，其他的密鑰都無法解密。常用的對稱加密算法有DES,3DES,AES。
還有一種加密方式叫非對稱加密(也叫公開密鑰加密)。非對稱加密需要使用兩個密鑰，公開密鑰(public key)和私有密鑰(private key)。公開密鑰是公開的，所有人都知道。私有密鑰是保密的，除了自己，不讓任何人知道。
- 使用公開密鑰加密的數據，只有使用私有密鑰才能解密。
- 使用私有密鑰加密的數據，只有使用公開密鑰才能解密。
- 使用摘要驗證保證數據完整性
HTTPS不僅僅使用了對稱加密的方式，還使用了非對稱加密的方式。事實上，HTTPS通信過程中，客戶端會持有一個公鑰，服務器會持有一個私鑰。使用非對稱加密可以完成好幾個關鍵的操作。比如驗證身份，比如協商通信的對稱密鑰，比如數據傳輸過程中加密摘要。
HTTPS中使用摘要算法來驗證數據完整性，使用非對稱密鑰加解密摘要，使用對稱密鑰對數據進行加解密
如上圖所示，在請求和響應過程中，除了加密後的數據，還會發送一個報文摘要，通過這個摘要，可以驗證數據是否被篡改。
拿響應爲例，
- 服務器會將明文的響應用摘要算法計算摘要，跟數據一起發送給客戶端。
- 客戶端將接收到的響應數據解密出來後，計算摘要。
然後客戶端會將自己計算出來的摘要跟服務器發送過來的摘要進行對比，如果兩個是相同的，那麼證明服務器發出的響應數據跟客戶端收到的響應數據是相同的。也就是數據是完整的，沒有丟失，也沒有遭到篡改。
但是這裏的前提是，服務器發過來的摘要沒有被篡改，如果有人在篡改了數據之後，連摘要也改了，那就有點坑了。所以HTTTPS會使用非對稱加密對摘要進行加密，防止摘要被篡改。
- 服務器會將明文的響應用摘要算法計算摘要。
- 將摘要使用私鑰進行加密，跟數據一起發送給客戶端。
- 客戶端將接收到的響應數據解密出來後，計算摘要。
- 客戶端將接收到的摘要使用公鑰進行解密。
然後客戶端會將自己計算出來的摘要跟解密出來的服務器發送過來的摘要進行對比，如果兩個是相同的，那麼證明服務器發出的響應數據跟客戶端收到的響應數據是相同的。也就是數據是完整的，沒有丟失，也沒有遭到篡改。
爲什麼非對稱加密可以保證服務器發送的摘要不被修改呢?
因爲私鑰只有服務器有，也就是說，只有服務器能夠使用私鑰進行加密。而使用私鑰加密的數據，只有公鑰可以解密。換句話說，用公鑰能夠解密出來的數據，就是使用私鑰加密過的。所以，只要客戶端使用公鑰能夠解密出來加密過的摘要，那麼這個摘要就是服務器使用私鑰加密的。而且私鑰只有服務器知道，別人無法篡改加密後的摘要。
這裏其實我有個疑問，反過來，在請求過程中，客戶端使用公鑰加密摘要，然後服務器私有私鑰解密摘要。貌似只有證明這個摘要是使用公鑰加密的，但是，公鑰是公開的，別人也能知道，那別人不就可以篡改這個摘要?
使用數字證書驗證服務器的身份
HTTPS是如何確認服務器的真實性的呢?也就說，怎樣確認跟客戶端通信的服務器就是我們的域名指向的服務器，而不是其他服務器冒充的?
HTTPS採用非對稱加密方式解決問題。
服務器擁有私鑰，這個私鑰只有服務器有，所以，只要客戶端擁有服務器的公鑰，那麼，當服務器使用私鑰加密數據發送給客戶端，而客戶端能夠解密出數據，說明公鑰和私鑰是配對的，而公鑰是對應着我們想要的那個服務器的，所以就代表服務器是真的。
那麼問題又來了，我們怎麼拿到該服務器的公鑰呢?在客戶端內置?怎麼多網站，怎麼看都不現實。
那我們就在建立連接的時候發送給客戶端。
嗯，HTTPS就是這麼做的。
不對，那發送公鑰的時候，公鑰也可能被篡改啊，要是被篡改成其他服務器的公鑰，以後就是跟其他冒充的服務器通信了，那怎麼玩?
嗯，HTTPS引入了權威的第三方機構來確保這個公鑰確實是該服務器的。
如果要使用HTTPS，服務器管理人員需要向CA(權威的證書頒發機構)購買證書。CA會將該服務器的域名、公鑰、公司信息等內容封裝到證書中。並且使用CA自己的私鑰對證書進行簽名。那麼，服務器將證書發給客戶端，客戶端如果驗證出證書是有效的，並且證書的域名跟目前通信的域名一致，那麼這個證書裏面的公鑰就是有效的。而且當前是域名指向的服務器的公鑰。所以，我們就能確保拿到的公鑰是真的了。
嗯，這個CA機構頒發的證書就叫做數字證書。
問題又來了，客戶端如何驗證服務器發過來證書是有效的呢?
證書上有CA用其私鑰做的簽名，而一般客戶端都會內置這些權威機構(CA)的公鑰的，所以能夠直接拿到CA的公鑰對證書上的簽名進行解密，然後自己根據證書上的說明計算摘要，兩個摘要一致的話，代表證書是有效。因爲只有CA自己纔有私鑰，別人是不可能冒充這個簽名的。
說了那麼多，HTTPS在連接建立時會發給客戶端一個數字證書，客戶端驗證了數字證書之後，就能確認服務器的身份。同時還可以用數字證書上的公鑰加密隨機生成的共享密鑰A，與服務器協商接下來通信過程中加密數據所用的共享密鑰A。
HTTPS握手過程
HTTPS握手過程
SSL 協議既用到了公鑰加密技術又用到了對稱加密技術，對稱加密技術雖然比公鑰加密技術的速度快，可是公鑰加密技術提供了更好的身份認證技術。SSL 的握手協議非常有效的讓客戶和服務器之間完成相互之間的身份認證，其主要過程如下：
①客戶端向服務器請求HTTPS連接。
客戶端向服務器傳送客戶端SSL 協議的版本號，加密算法的種類，產生的隨機數，以及其他服務器和客戶端之間通訊所需要的各種信息。
②服務器確認並返回證書。
服務器向客戶端傳送SSL 協議的版本號，加密算法的種類，隨機數以及其他相關信息，同時服務器還將向客戶端傳送自己的證書。
③客戶端驗證服務器發來的證書。
客戶端利用服務器傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過期，發行服務器證書的CA 是否可靠，發行者證書的公鑰能否正確解開服務器證書的“發行者的數字簽名”，服務器證書上的域名是否和服務器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開;如果合法性驗證通過，將繼續進行第四步。
④信息驗證通過，客戶端生成隨機密鑰A，用公鑰加密後發給服務器。
從第③步驗證過的證書裏面可以拿到服務器的公鑰，客戶端生成的隨機密鑰就使用這個公鑰來加密，加密之後，只有擁有該服務器(持有私鑰)才能解密出來，保證安全。
⑤服務器用私鑰解密出隨機密鑰A，以後通信就用這個隨機密鑰A來對通信進行加密。
我們這個握手過程並沒有將驗證客戶端身份的邏輯加進去。因爲在大多數的情況下，HTTPS只是驗證服務器的身份而已。如果要驗證客戶端的身份，需要客戶端擁有證書，在握手時發送證書，而這個證書是需要成本的。