本文將分兩個專題去理解HTTPS。
專題一：HTTPS爲什麼安全
1、http爲什麼不安全？
http協議屬於明文傳輸協議，交互過程以及數據傳輸都沒有進行加密，通信雙方也沒有進行任何認證，通信過程非常容易遭遇劫持、監聽、篡改，嚴重情況下，會造成惡意的流量劫持等問題，甚至造成個人隱私泄露（比如銀行卡卡號和密碼泄露）等嚴重的安全問題。
可以把http通信比喻成寄送信件一樣，A給B寄信，信件在寄送過程中，會經過很多的郵遞員之手，他們可以拆開信讀取裏面的內容（因爲http是明文傳輸的）。A的信件裏面的任何內容（包括各類賬號和密碼）都會被輕易竊取。除此之外，郵遞員們還可以僞造或者修改信件的內容，導致B接收到的信件內容是假的。
比如常見的，在http通信過程中，“中間人”將廣告鏈接嵌入到服務器發給用戶的http報文裏，導致用戶界面出現很多不良鏈接； 或者是修改用戶的請求頭URL，導致用戶的請求被劫持到另外一個網站，用戶的請求永遠到不了真正的服務器。這些都會導致用戶得不到正確的服務，甚至是損失慘重。
2、https如何保證安全？
要解決http帶來的問題，就要引入加密以及身份驗證機制。
如果Server（以後簡稱服務器）給Client（以後簡稱 客戶端）的消息是密文的，只有服務器和客戶端才能讀懂，就可以保證數據的保密性。同時，在交換數據之前，驗證一下對方的合法身份，就可以保證通信雙方的安全。那麼，問題來了，服務器把數據加密後，客戶端如何讀懂這些數據呢？這時服務器必須要把加密的密鑰（對稱密鑰，後面會詳細說明）告訴客戶端，客戶端才能利用對稱密鑰解開密文的內容。但是，服務器如果將這個對稱密鑰以明文的方式給客戶端，還是會被中間人截獲，中間人也會知道對稱密鑰，依然無法保證通信的保密性。但是，如果服務器以密文的方式將對稱密鑰發給客戶端，客戶端又如何解開這個密文，得到其中的對稱密鑰呢？
說到這裏，大家是不是有點兒糊塗了？一會兒密鑰，一會兒對稱密鑰，都有點兒被搞暈的節奏。在這裏，提前給大家普及一下，這裏的密鑰，指的是非對稱加解密的密鑰，是用於TLS握手階段的； 對稱密鑰，指的是對稱加解密的密鑰，是用於後續傳輸數據加解密的。下面將詳細說明。
這時，我們引入了非對稱加解密的概念。在非對稱加解密算法裏，公鑰加密的數據，有且只有唯一的私鑰才能夠解密，所以服務器只要把公鑰發給客戶端，客戶端就可以用這個公鑰來加密進行數據傳輸的對稱密鑰。客戶端利用公鑰將對稱密鑰發給服務器時，即使中間人截取了信息，也無法解密，因爲私鑰只部署在服務器，其他任何人都沒有私鑰，因此，只有服務器才能夠解密。服務器拿到客戶端的信息並用私鑰解密之後，就可以拿到加解密數據用的對稱密鑰，通過這個對稱密鑰來進行後續通信的數據加解密。除此之外，非對稱加密可以很好的管理對稱密鑰，保證每次數據加密的對稱密鑰都是不相同的，這樣子的話，即使客戶端病毒拉取到通信緩存信息，也無法竊取正常通信內容。
上述通信過程，可以畫成以下交互圖：
但是這樣似乎還不夠，如果通信過程中，在三次握手或者客戶端發起HTTP請求過程中，客戶端的請求被中間人劫持，那麼中間人就可以僞裝成“假冒客戶端”和服務器通信；中間人又可以僞裝成“假冒服務器”和客戶端通信。接下來，我們詳細闡述中間人獲取對稱密鑰的過程：
中間人在收到服務器發送給客戶端的公鑰（這裏是“正確的公鑰”）後，並沒有發給客戶端，而是中間人將自己的公鑰（這裏中間人也會有一對公鑰和私鑰，這裏稱呼爲“僞造公鑰”）發給客戶端。之後，客戶端把對稱密鑰用這個“僞造公鑰”加密後，發送過程中經過了中間人，中間人就可以用自己的私鑰解密數據並拿到對稱密鑰，此時中間人再把對稱密鑰用“正確的公鑰”加密發回給服務器。此時，客戶端、中間人、服務器都擁有了一樣的對稱密鑰，後續客戶端和服務器的所有加密數據，中間人都可以通過對稱密鑰解密出來。
中間人獲取對稱密鑰的過程如下：
爲了解決此問題，我們引入了數字證書的概念。服務器首先生成公私鑰，將公鑰提供給相關機構（CA），CA將公鑰放入數字證書並將數字證書頒佈給服務器，此時服務器就不是簡單的把公鑰給客戶端，而是給客戶端一個數字證書，數字證書中加入了一些數字簽名的機制，保證了數字證書一定是服務器給客戶端的。中間人發送的僞造證書，不能夠獲得CA的認證，此時，客戶端和服務器就知道通信被劫持了。加入了CA數字簽名認證的SSL會話過程如下所示：
所以綜合以上三點：非對稱加密算法（公鑰和私鑰）交換對稱密鑰+數字證書驗證身份（驗證公鑰是否是僞造的）+利用對稱密鑰加解密後續傳輸的數據=安全
3、https協議簡介
爲什麼是簡單地介紹https協議呢？因爲https涉及的東西實在太多了，尤其是其中的加解密算法，十分複雜，作者本身對這些算法也研究不完，只是懂其中的一些皮毛而已。這部分僅僅是簡單介紹一些關於https的最基本原理，爲後面分析https的建立過程以及https優化等內容打下理論基礎。
3.1 對稱加密算法
對稱加密是指：加密和解密使用相同密鑰的算法。它要求發送方和接收方在安全通信之前，商定一個對稱密鑰。對稱算法的安全性完全依賴於密鑰，密鑰泄漏就意味着任何人都可以對他們發送或接收的消息解密，所以密鑰的保密性對通信至關重要。
3.1.1 對稱加密又分爲兩種模式：流加密和分組加密
流加密是將消息作爲字節流對待，並且使用數學函數分別作用在每一個字節位上。使用流加密時，每加密一次，相同的明文位會轉換成不同的密文位。流加密使用了密鑰流生成器，它生成的字節流與明文字節流進行異或，從而生成密文。
分組加密是將消息劃分爲若干個分組，這些分組隨後會通過數學函數進行處理，每次一個分組。假設使用64位的分組密碼，此時如果消息長度爲640位，就會被劃分成10個64位的分組（如果最後一個分組長度不到64，則用0補齊之後加到64位），每個分組都用一系列數學公式進行處理，最後得到10個加密文本分組。然後，將這條密文消息發送給對端。對端必須擁有相同的分組密碼，以相反的順序對10個密文分組使用前面的算法解密，最終得到明文消息。比較常用的分組加密算法有DES、3DES、AES。其中DES是比較老的加密算法，現在已經被證明不安全。而3DES是一個過渡的加密算法，相當於在DES基礎上進行三重運算來提高安全性，但其本質上還是和DES算法一致。而AES是DES算法的替代算法，是現在最安全的對稱加密算法之一。
3.1.2 對稱加密算法的優缺點：
優點：計算量小、加密速度快、加密效率高。
缺點：
（1）交易雙方都使用同樣密鑰，安全性得不到保證；
（2）每次使用對稱加密算法時，都需要使用其他人不知道的惟一密鑰，這會使得發收信息雙方所擁有的鑰匙數量呈幾何級數增長，密鑰管理成爲負擔。
3.2 非對稱加密算法
在非對稱密鑰交換算法出現以前，對稱加密的最主要缺陷就是不知道如何在通信雙方之間傳輸對稱密鑰，而又不讓中間人竊取。非對稱密鑰交換算法誕生之後，專門針對對稱密鑰傳輸做加解密，使得對稱密鑰的交互傳輸變得非常安全了。
非對稱密鑰交換算法本身非常複雜，密鑰交換過程涉及到隨機數生成，模指數運算，空白補齊，加密，簽名等等一系列極其複雜的過程，作者本人也沒有研究完全透徹。常見的密鑰交換算法有RSA，ECDHE，DH，DHE等算法。涉及到比較複雜的數學問題。其中，最經典也是最常用的是RSA算法。
RSA：誕生於1977年，經過了長時間的破解測試，算法安全性很高，最重要的是，算法實現非常簡單。缺點就是需要比較大的質數（目前常用的是2048位）來保證安全強度，極其消耗CPU運算資源。RSA是目前唯一一個既能用於密鑰交換又能用於證書籤名的算法，RSA 是最經典，同時也是最常用的是非對稱加解密算法。
3.2.1 非對稱加密相比對稱加密更加安全，但也存在兩個致命的缺點：
（1）CPU計算資源消耗非常大。一次完全TLS握手，密鑰交換時的非對稱解密計算量佔整個握手過程的90%以上。而對稱加密的計算量只相當於非對稱加密的0.1%。如果後續的應用層數據傳輸過程也使用非對稱加解密，那麼CPU性能開銷太龐大，服務器是根本無法承受的。賽門特克給出的實驗數據顯示，加解密同等數量的文件，非對稱算法消耗的CPU資源是對稱算法的1000倍以上。
（2）非對稱加密算法對加密內容的長度有限制，不能超過公鑰長度。比如現在常用的公鑰長度是2048位，意味着待加密內容不能超過256個字節。
所以非對稱加解密（極端消耗CPU資源）目前只能用來作對稱密鑰交換或者CA簽名，不適合用來做應用層內容傳輸的加解密。
3.3 身份認證
https協議中身份認證的部分是由CA數字證書完成的，證書由公鑰、證書主體、數字簽名等內容組成。在客戶端發起SSL請求後，服務端會將數字證書發給客戶端，客戶端會對證書進行驗證（驗證這張證書是否是僞造的？也就是公鑰是否是僞造的），如果證書不是僞造的，客戶端就獲取用於對稱密鑰交換的非對稱密鑰（獲取公鑰）。
3.3.1 數字證書有三個作用：
1、身份授權。確保瀏覽器訪問的網站是經過CA驗證的可信任的網站。
2、分發公鑰。每個數字證書都包含了註冊者生成的公鑰（驗證確保是合法的，非僞造的公鑰）。在SSL握手時會通過certificate消息傳輸給客戶端。
3、驗證證書合法性。客戶端接收到數字證書後，會對證書合法性進行驗證。只有驗證通過後的證書，才能夠進行後續通信過程。
3.3.2 申請一個受信任的CA數字證書通常有如下流程：
（1）公司（實體）的服務器生成公鑰和私鑰，以及CA數字證書請求。
（2）RA（證書註冊及審覈機構）檢查實體的合法性（在註冊系統裏面是否註冊過的正規公司）。
（3）CA（證書籤發機構）簽發證書，發送給申請者實體。
（4）證書更新到repository（負責數字證書及CRL內容存儲和分發），實體終端後續從repository更新證書，查詢證書狀態等。
3.4 數字證書驗證
申請者拿到CA的證書並部署在網站服務器端，那瀏覽器發起握手並接收到證書後，如何確認這個證書就是CA簽發的呢？怎樣避免第三方僞造這個證書？答案就是數字簽名（digital signature）。數字簽名是證書的防僞標籤，目前使用最廣泛的SHA-RSA（SHA用於哈希算法，RSA用於非對稱加密算法）。數字簽名的製作和驗證過程如下：
1、數字簽名的簽發。首先是使用哈希函數對待簽名內容進行安全哈希，生成消息摘要，然後使用CA自己的私鑰對消息摘要進行加密。
2、數字簽名的校驗。使用CA的公鑰解密簽名，然後使用相同的簽名函數對簽名證書內容進行簽名，並和服務端數字簽名裏的簽名內容進行比較，如果相同就認爲校驗成功。
需要注意的是：
（1）數字簽名簽發和校驗使用的非對稱密鑰是CA自己的公鑰和私鑰，跟證書申請者（提交證書申請的公司實體）提交的公鑰沒有任何關係。
（2）數字簽名的簽發過程跟公鑰加密的過程剛好相反，即是用私鑰加密，公鑰解密。（一對公鑰和私鑰，公鑰加密的內容只有私鑰能夠解密；反過來，私鑰加密的內容，也就有公鑰才能夠解密）
（3）現在大的CA都會有證書鏈，證書鏈的好處：首先是安全，保持CA的私鑰離線使用。第二個好處是方便部署和撤銷。這裏爲啥要撤銷呢？因爲，如果CA數字證書出現問題（被篡改或者污染），只需要撤銷相應級別的證書，根證書依然是安全的。
（4）根CA證書都是自簽名，即用自己的公鑰和私鑰完成了簽名的製作和驗證。而證書鏈上的證書籤名都是使用上一級證書的非對稱密鑰進行簽名和驗證的。
（5）怎樣獲取根CA和多級CA的密鑰對？還有，既然是自簽名和自認證，那麼它們是否安全可信？這裏的答案是：當然可信，因爲這些廠商跟瀏覽器和操作系統都有合作，它們的根公鑰都默認裝到了瀏覽器或者操作系統環境裏。
3.5 數據完整性驗證
數據傳輸過程中的完整性使用MAC算法來保證。爲了避免網絡中傳輸的數據被非法篡改，或者數據比特被污染，SSL利用基於MD5或SHA的MAC算法來保證消息的完整性（由於MD5在實際應用中存在衝突的可能性比較大，所以儘量別採用MD5來驗證內容一致性）。 MAC算法是在密鑰參與下的數據摘要算法，能將密鑰和任意長度的數據轉換爲固定長度的數據。發送者在密鑰的作用下，利用MAC算法計算出消息的MAC值，並將其添加在需要發送的消息之後，併發送給接收者。接收者利用同樣的密鑰和MAC算法計算出消息的MAC值，並與接收到的MAC值比較。如果二者相同，則報文沒有改變；否則，報文在傳輸過程中被修改或者污染，接收者將丟棄該報文。 SHA也不能使用SHA0和SHA1，山東大學的王小云教授（很牛的一個女教授，大家有興趣可以上網搜索一下她的事蹟）在2005年就宣佈破解了 SHA-1完整版算法，並獲得了業內專家的認可。微軟和google都已經宣佈16年及17年之後不再支持sha1簽名證書。
