一.為什麼出現https

說到https,我們自然就會想到http.因為就光從字面意義上來講，https就僅僅比http多了一個s。http是一種超文字傳輸協議，是無狀態的、基於TCP的可靠傳輸協議。但http有一個最大的問題，它是以明文的形式進行傳輸，由於資料在網路中傳輸的時候，並不是直接的點對點傳輸，而是要經歷好多的節點進行轉發，所以資料包就很容易被劫持，那麼資料就完全暴露在陽光下，沒有什麼祕密可言，所以安全性極低。那怎麼解決這個問題呢？我們自然很容易想到了，把資料加密傳輸，這樣即使被劫持，也無法知道我的真實資料是什麼。所以，這就產生了https。
說到這裡，那麼http主要會產生哪些安全問題呢？

1. 竊聽風險（eavesdropping）：第三方可以獲知通訊內容；
2. 篡改風險（tampering）：第三方可以修改通訊內容；
3. 冒充風險（pretending）：第三方可以冒充他人身份參與通訊。

二.https是什麼

如果給https加個定義的話，那麼https是一種通過計算機網路進行安全通訊的傳輸協議，經由http進行通訊，利用SSL/TLS建立全通道，加密資料包。https使用的主要目的是提供對網站伺服器的身份認證，同時保護交換資料的隱私與完整性。說白了，https就是http+SSL，（所以https並不是http的複數，呵呵）。那麼什麼是SSL呢？SSL(Secure Sockets Layer 安全套接層),及其繼任者傳輸層安全（Transport Layer Security，TLS）是為網路通訊提供安全及資料完整性的一種安全協議，負責在傳輸層對網路連線進行加密。SSL主要作用：

1. 認證使用者和伺服器，確保資料傳送到正確的客戶機和伺服器；
2. 加密資料以防止資料中途被竊取；
3. 維護資料的完整性，確保資料在傳輸過程中不被改變。
   正是有了SSL的加持，就解決了上面所說的http的三種安全問題。

三.https解決了什麼問題

1.解決的三大問題

1. 傳輸過程中所有資料都是加密的，防止了第三方竊聽；
2. https的校驗機制，一旦資料被篡改，通訊雙方就會立即發現；
3. 具有身份證書，防止了身份被冒充。
   下面我們就分別看看是怎麼解決這些問題的。

2.解決問題的推演過程

1.資料是如何加密的

在使用http請求時，資料是以明文的方式進行傳輸的，那麼在整個傳輸過程中，會經過很多節點（作業系統、閘道器、路由、ISP網際網路那供應商），那麼每個節點都有可能竊聽到傳輸的資料，因為資料是以明文形式傳輸的。

既然這樣，那麼將明文資料加密成密文進行傳輸，就能解決這個問題。那麼怎麼加密呢？首先，利用MD5這樣的摘要演算法肯定是不行的，因為這樣密文是不可逆的，所以要採用加密演算法，例如移位或者混淆等。

但這種演算法只能在一定程度上解決這個問題。為什麼呢？原因有以下幾點：
1.client端不是一個，而是很多，這樣所有的client都必須支援我自己所定義的這種演算法，顯示不合適，不可能讓每個瀏覽器為每個應用都嵌入一個演算法；
2.即使客戶端瀏覽器嵌入了這個演算法，由於這個演算法是在前端，顯然無法保證演算法不被外界所知，那麼這時候一旦演算法洩露，那麼這樣的密文就沒有安全性可言了。
那麼怎麼進一步解決這個問題呢?想想我們在儲存密碼的時候，很多使用MD5+鹽的方式，才增加密碼的強度，那麼這裡，如果給我們的演算法傳入一個隨機鹽，只要保證這個隨機鹽只有客戶端和服務端知道，其他任何人都不知道就行了。

這就可以利用對稱加密演算法，如DES 、3DES、AES等。
所謂對稱加密演算法，就是加密和解密都是一個金鑰，加密解密過程：明文->金鑰加密->密文，密文->金鑰解密->明文，其中的金鑰就可以理解為我們上面所說的隨機鹽，只要保證鹽不丟失或者鹽不被竊取，就基本能夠保證密文安全性。
那麼問題來了，由於這個隨機鹽是應該放在哪裡或者應該怎麼保護這個隨機鹽呢？有兩種方式：放在服務端或者內建在瀏覽器中；下面我們看下這兩種方式：
1.隨機鹽放在服務端：那麼客戶端就要向服務端請求這個隨機鹽或者服務端向客戶端直接下發這個隨機鹽，但是無論採用哪種方式，它在經過網路中的各個節點時，都能很容易的被別人竊取，顯示這樣不合適；
2.內建在客戶端：那麼所有的瀏覽器都要為每個應用放置一個內建的鹽，並且這個鹽還是固定的，那就相當於向所有人公佈了這個鹽，只要知道這個鹽，就可以利用對稱加密演算法解密了。
既然上面兩種存放方式都不行，那應該怎麼辦呢？既然放到哪裡都不合適，我們是不是可以採用另外一種演算法，再對這個隨機鹽進行加密的，來保證只能客戶端和服務端能解開這個密文，獲取到隨機鹽呢？這時候我們自然會想到非對稱加密演算法。
所謂非對稱演算法，就是需要兩個金鑰：公鑰(publickey) 和私鑰(privatekey) ，公鑰和私鑰是一對，私鑰是由公鑰生成的。非對稱加密演算法的加密和解密有以下幾個原則（這個特性非常重要）：
1.公鑰加密，私鑰能解；
2.私鑰加密，公鑰能解；
3.公鑰加密，公鑰不能解。

由於非對稱加密演算法（如RSA）的加密解密速度要比對稱演算法速度慢很多，所以在實際應用中，通常採取資料本身的加密和解密使用對稱加密演算法(如AES)， 用非對稱加密演算法（如RSA）加密並傳輸對稱演算法所需的金鑰（鹽），這也是現在這裡採用的方式。好了，那我們再考慮下，這個對稱加密的公鑰和私鑰又應該放在哪裡？
1.私鑰：很顯然私鑰要放在服務端，這個沒有什麼好說的；
2.公鑰: 如果公鑰是放在客戶端，那麼每個瀏覽器都要單獨為每個應用內建一個公鑰，這顯然是不現實的，所以公鑰應該放到服務端，由私鑰生成公鑰，再由客戶端來請求服務端獲取公鑰，然後儲存在客戶端。那就是下面的邏輯：

然後再進行資料的傳輸：

這樣就解決資料被竊取或者偷窺的問題。既然資料在網路節點中連看都無法看（偷窺），那麼顯然，資料也就無法被篡改，因為你不知道資料是什麼樣的。這時候我們可能會有這樣的考慮，上面客戶端從服務端獲取公鑰的時候，顯然網路節點是能夠竊取到公鑰的，那麼這時候是不是可以篡改資料呢？那麼我們看下：

從上圖中的過程（主要是虛線部分）中看到，由於在傳輸過程中，客戶端初始的隨機鹽被修改了，所以導致客戶端是無法解密利用偽造的鹽而響應的密文，客戶端也就沒辦法看到偽造的資料，所以這種方式沒有什麼意義。
但是到目前為止，身份冒充的問題。下面我們繼續分析。

2.如何保證身份不被冒充

我們還是接著上面的圖來說，如果我把圖稍微改一下：

看上圖中實線部分，此時網路節點直接冒充服務端，自身偽造出假私鑰和假公鑰，由服務節點來代替真正的服務端來給客戶端提供響應，那麼這樣客戶端接到的資料就是被其他身份（網路節點）冒充的， 而不是由真正的server端響應的。所以，只靠非對稱加密，也無法解決http產生的問題，客戶端無法判斷公鑰是否是那個server端下發的。那麼應該如何核實身份呢？
其實說白了，就是如何保證公鑰不會被網路節點給偽造。那最好有一個專門的可信任的機構，來保證或者驗證公鑰的可信任度，也就是說不是什麼人生成的公鑰都是可信任的，只有我這個第三方機構說你的公鑰是正確的，那才是正確的，否則，就是偽造的公鑰，所以這裡就引出了第三方機構。那麼，這個第三方機構又是如何保證服務端的公鑰沒有被偽造呢？想一下，在平時開發中，我們是如何驗證資料一致的？比如說登入時是如何驗證密碼是否一致呢？很顯然，我們採用的hash摘要演算法，如MD5。這裡我們一樣可以借鑑這樣的做法，對公鑰進行hash，然後客戶端比對兩次hash的摘要是否一致。
所謂摘要演算法，就是相同的資料，hash演算法結果一致。
那麼第三方機構是如何保證服務端的公鑰是可信任和一致的呢？
1.要保證網站的在第三方機構的信任列表裡，只有網站在第三方機構的信任列表裡，他才會用機構自己的私鑰給網站服務端的公鑰（server.公鑰）進行非對稱加密（如RSA）,加密方法為：RSA(第三方機構的私鑰，網站服務端的公鑰)進行非對稱加密，假設加密的結果為a；
2.客戶端要內建第三方機構的公鑰，用於解密出網站服務端的公鑰(server.公鑰)，即server.公鑰；
3.第三方機構使用hash摘要演算法，對網站服務端公鑰（server.公鑰）進行hash摘要演算法，即hash(server.公鑰)，稱為簽名；
除了第三方機構外，上面我們提到的hash摘要演算法到底是具體哪種演算法，也要告訴客戶端，這樣客戶端來驗證server.公鑰是否被偽造了。
所以，當客戶端向服務端請求公鑰（server.公鑰）時，就不再是簡單的返回公鑰（server.公鑰）了，還要返回RSA(第三方機構的私鑰，server.公鑰)、hash摘要演算法（即簽名演算法）、簽名、第三方機構的名稱等，我們把這些資訊統一包裝起來，就稱為證書，這裡的第三方機構，就稱為CA證書的頒發機構，簡稱CA。這樣客戶端向服務端請求公鑰的過程就變成下面的樣子了：

並且這個過程中，網路節點是不可能偽造服務端的公鑰的，如下圖所示：

3.https的請求過程

https和http請求的過程基本是一樣的，只是多了一個客戶端和服務端協商，獲取數字證書的過程，也可以理解為建立一個安全的隧道，來保證資料傳輸的安全性。

四.小結

到這裡，整個原理就分析完了，中間的推演過程比較繞一些。中間有錯誤的地方，希望多多指教。