伺服器如何把證書發送給客戶

A. https交互過程

在這里整理一下最近這兩天整理的https的相關知識。

大家都知道要使用https，需要在網站的伺服器上配置https證書（一般是nginx，或者tomcat），證書可以使用自己生成，也可以向專門的https證書提供商進行購買。這兩種的區別是自己生成的證書是不被瀏覽器信任的,所以當訪問的時候回提示不安全的網站，需要點擊信任之後才能繼續訪問

自己生成的

而購買的https證書會提示安全

DV,OV

EV

這是因為瀏覽器中預置了一些https證書提供商的證書，在瀏覽器獲取到伺服器的https證書進行驗證的時候就知道這個https證書是可信的；而自己生成的證書，瀏覽器獲取到之後無法進行驗證是否可信，所以就給出不安全的提示。

下面對具體的一些知識點進行介紹

1. 什麼是https

https簡單的說就是安全版的http，因為http協議的數據都是明文進行傳輸的，所以對於一些敏感信息的傳輸就很不安全，為了安全傳輸敏感數據，網景公司設計了SSL（Secure Socket Layer），在http的基礎上添加了一個安全傳輸層，對所有的數據都加密後再進行傳輸，客戶端和伺服器端收到加密數據後按照之前約定好的秘鑰解密。

2. 加密和解密

Https的發展和密碼學的發展是分不開的。大家應該知道加密方式可以大體分為對稱加密和非對稱加密（反正我就知道這兩種）

對稱加密，就是加密和解密都是用同一個秘鑰，這種方式優點就是速度快，缺點就是在管理和分配秘鑰的時候不安全。

非對稱加密演算法，非對稱加密有一個秘鑰對，叫做公鑰和私鑰，私鑰自己持有，公鑰可以公開的發送給使用的人。使用公鑰進行加密的信息，只有和其配對的私鑰可以解開。目前常見的非對稱加密演算法是RSA，非對稱的加密演算法的優點是安全，因為他不需要把私鑰暴露出去。

在正式的使用場景中一般都是對稱加密和非對稱加密結合使用，使用非對稱加密完成秘鑰的傳遞，然後使用對稱秘鑰進行數據加密和解密

3. https證書的申請流程

1 在伺服器上生成CSR文件（證書申請文件，內容包括證書公鑰、使用的Hash演算法、申請的域名、公司名稱、職位等信息）

可以使用命令在伺服器上生成；也可以使用線上的工具進行生成，線上的工具會把公鑰加入到CSR文件中，並同時生成私鑰。

CSR文件內容

2 把CSR文件和其他可能的證件上傳到CA認證機構，CA機構收到證書申請之後，使用申請中的Hash演算法，對部分內容進行摘要，然後使用CA機構自己的私鑰對這段摘要信息進行簽名，

CA機構進行簽名

3 然後CA機構把簽名過的證書通過郵件形式發送到申請者手中。

4 申請者收到證書之後部署到自己的web伺服器中。下面會在寫一篇關於部署的文章

當然這是不通過CA代理機構進行申請的流程，現在網上有好多CA的代理機構，像騰訊雲，阿里雲都可以申請https證書，流程都差不多。

阿里雲申請證書流程

4. 客戶端（瀏覽器）和伺服器端交互流程

客戶端服務端交互

client Hello,客戶端（通常是瀏覽器）先向伺服器發出加密通信的請求

（1） 支持的協議版本，比如TLS 1.0版。

（2） 一個客戶端生成的隨機數 random1，稍後用於生成"對話密鑰"。

（3） 支持的加密方法，比如RSA公鑰加密。

（4） 支持的壓縮方法。

伺服器收到請求,然後響應 (server Hello)

（1） 確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與伺服器支持的版本不一致，伺服器關閉加密通信。

（2） 一個伺服器生成的隨機數random2，稍後用於生成"對話密鑰"。

（3） 確認使用的加密方法，比如RSA公鑰加密。

（4） 伺服器證書。

證書內容

證書內容

客戶端收到證書之後會首先會進行驗證

驗證流程

我們知道CA機構在簽發證書的時候，都會使用自己的私鑰對證書進行簽名

證書里的簽名演算法欄位 sha256RSA 表示，CA機構使用sha256對證書進行摘要，然後使用RSA演算法對摘要進行私鑰簽名，而我們也知道RSA演算法中，使用私鑰簽名之後，只有公鑰才能進行驗簽。

如果我們使用的是購買的證書，那麼很有可能，頒發這個證書的CA機構的公鑰已經預置在操作系統中。這樣瀏覽器就可以使用CA機構的公鑰對伺服器的證書進行驗簽。確定這個證書是不是由正規的CA機構頒發的。驗簽之後得到CA機構使用sha256得到的證書摘要，然後客戶端再使用sha256對證書內容進行一次摘要，如果得到的值和驗簽之後得到的摘要值相同，則表示證書沒有被修改過。

如果驗證通過，就會顯示上面的安全字樣，如果伺服器購買的證書是更高級的EV類型，就會顯示出購買證書的時候提供的企業名稱。如果沒有驗證通過，就會顯示不安全的提示。

生成隨機數

驗證通過之後，客戶端會生成一個隨機數pre-master secret，然後使用證書中的公鑰進行加密，然後傳遞給伺服器端

PreMaster secret

PreMaster Secret是在客戶端使用RSA或者Diffie-Hellman等加密演算法生成的。它將用來跟服務端和客戶端在Hello階段產生的隨機數結合在一起生成 Master Secret。在客戶端使用服務端的公鑰對PreMaster Secret進行加密之後傳送給服務端，服務端將使用私鑰進行解密得到PreMaster secret。也就是說服務端和客戶端都有一份相同的PreMaster secret和隨機數。

PreMaster secret前兩個位元組是TLS的版本號，這是一個比較重要的用來核對握手數據的版本號，因為在Client Hello階段，客戶端會發送一份加密套件列表和當前支持的SSL/TLS的版本號給服務端，而且是使用明文傳送的，如果握手的數據包被破解之後，攻擊者很有可能串改數據包，選擇一個安全性較低的加密套件和版本給服務端，從而對數據進行破解。所以，服務端需要對密文中解密出來對的PreMaster版本號跟之前Client Hello階段的版本號進行對比，如果版本號變低，則說明被串改，則立即停止發送任何消息。

pre-master secret

伺服器收到使用公鑰加密的內容，在伺服器端使用私鑰解密之後獲得隨機數pre-master secret，然後根據radom1、radom2、pre-master secret通過一定的演算法得出session Key和MAC演算法秘鑰，作為後面交互過程中使用對稱秘鑰。同時客戶端也會使用radom1、radom2、pre-master secret，和同樣的演算法生成session Key和MAC演算法的秘鑰。

生成session Key的過程中會用到PRF(Pseudorandom Function偽隨機方法)來生成一個key_block,然後再使用key_block,生成後面使用的秘鑰。

key_block = PRF(SecurityParameters.master_secret,"key expansion",SecurityParameters.server_random +SecurityParameters.client_random);

PRF是在規范中約定的偽隨機函數

在信息交互過程中用到的秘鑰有6個分別是。客戶端和伺服器端分別使用相同的演算法生成。

秘鑰名稱秘鑰作用

client_write_MAC_key[SecurityParameters.mac_key_length]客戶端發送數據使用的摘要MAC演算法

server_write_MAC_key[SecurityParameters.mac_key_length]服務端發送數據使用摘要MAC演算法

client_write_key[SecurityParameters.enc_key_length]客戶端數據加密，服務端解密

server_write_key[SecurityParameters.enc_key_length]服務端加密，客戶端解密

client_write_IV[SecurityParameters.fixed_iv_length]初始化向量，運用於分組對稱加密

server_write_IV[SecurityParameters.fixed_iv_length]初始化向量，運用於分組對稱加密

然後再後續的交互中就使用session Key和MAC演算法的秘鑰對傳輸的內容進行加密和解密。

具體的步驟是先使用MAC秘鑰對內容進行摘要，然後把摘要放在內容的後面使用sessionKey再進行加密。對於客戶端發送的數據，伺服器端收到之後，需要先使用client_write_key進行解密，然後使用client_write_MAC_key對數據完整性進行驗證。伺服器端發送的數據，客戶端會使用server_write_key和server_write_MAC_key進行相同的操作。

鏈接：https://www.jianshu.com/p/b0b6b88fe9fe

B. SSL安全證書的實現機制

TLS/SSL的功能實現主要依賴於三類基本演算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密演算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。

C. 用WireShark簡單看看SSL/TLS協議

HTTPS目前是網站標配，否則瀏覽器會提示鏈接不安全，同HTTP相比比，HTTPS提供安全通信，具體原因是多了個「S」層，或者說SSL層[Secure Sockets Layer]，現在一般都是TLS[Transport Layer Security]，它是HTTP 明文 通信變成安全 加密通信 的基礎，SSL/TLS介於應用層和TCP層之間，從應用層數據進行加密再傳輸。安全的核心就在加密上：

如上圖所示，HTTP明文通信經中間路由最終發送給對方，如果中間某個路由節點抓取了數據，就可以直接看到通信內容，甚至可以篡改後，路由給目標對象，如下：

可見HTTP傳輸是不安全的，但，如果傳輸的是只有雙方可校驗的密文，就可以避免被偷竊、篡改，保證傳輸的安全性，這就是SSL/TLS層做的事情。

SSL/TLS協議主要從三方面來保證數據傳輸的安全性：保密、鑒別、完整：

對用戶端而言：怎麼保證訪問的網站就是目標網站？答案就是 證書 。每個HTTPS網站都需要TLS證書，在數據傳輸開始前，服務端先將證書下發到用戶端，由用戶根據證書判斷是否是目標網站。這其中的原理是什麼，證書又是如何標識網站的有效性呢？證書也叫 digital certificate 或者public key certificate，是密碼學中的概念，在TLS中就是指CA證書【 由證書的簽發機構（Certificate Authority，簡稱為 CA）頒布的證書 】，好比是權威部門的公章，WIKI網路解釋如下：

大意就是證書包含了目標站點的身份信息，並可以通過某種方式校驗其合法性，對於任何一個HTTPS網站，你都可以拿到其CA證書公鑰信息，在Chrome瀏覽器中點擊HTTPS網站的鎖標志，就可以查看公鑰信息，並可以導出CA二進制文件：

瀏覽器就是通過這個文件來校驗網站是否安全合法，可以看到，證書其實內置了一個頒發鏈條關系，根證書機構->次級證書機構->次次級->網站自身，只要驗證這個鏈條是安全的，就證明網站合法，背後的技術其實是 信任鏈+RSA的非對稱加密+系統內置根證書 。CA在頒發證書的時候，會用自己的私鑰計算出要頒發證書的簽名，其公鑰是公開的，只要簽名可被公鑰驗證就說明該證書是由該CA頒發的，核心校驗邏輯如下

那麼上級的CA又是如何保證安全呢？重復上述操作即可，最終都是靠根證書來驗證的，根證書的安全性不需要驗證，由系統保證，如此就形成了一個證書的信任鏈，也就能驗證當前網站證書的有效性，證書的信任鏈校驗如下：

TLS協議最大的提升點就是數據的安全，通HTTP通信相比，HTTPS的通信是加密的，在協商階段，通過非對稱加密確定對稱加密使用的秘鑰，之後利用對稱秘鑰進行加密通信，這樣傳輸的數據就是密文，就算中間節點泄漏，也可以保證數據不被竊取，從而保證通信數據的安全性。

第三個問題，雖然中間節點無法竊取數據，但是還是可以隨意更改數據的，那麼怎麼保證數據的完整性呢，這個其實任何數據傳輸中都會有這個問題，通過MAC[Message Authentication Codes]信息摘要演算法就可以解決這個問題，同普通MD5、SHA等對比，MAC消息的散列加入了秘鑰的概念，更加安全，是MD5和SHA演算法的升級版，可以認為TLS完整性是數據保密性延伸，接下來就藉助WireShark看看TLS握手的過程，並看看是如何實現身份鑒別、保密性、完整性的。

HTTPS安全通信簡化來說： 在協商階段用非對稱加密協商好通信的對稱秘鑰 ，然後 用對稱秘鑰加密進行數據通信 ，簡易的WireShark TLS/SSL協商過程示意如下：

細化分離後示意如下：

握手分多個階段，不過一次握手可以完成多個動作，而且也並不是所有類型的握手都是上述模型，因為協商對稱秘鑰的演算法不止一種，所以握手的具體操作也並非一成不變，比如RSA就比ECDHE要簡單的多，目前主流使用的都是ECDHE，具體流程拆分如下：

Client Hello是TLS/SSL握手發起的第一個動作，類似TCP的SYN，Client Hello 階段客戶端會指定版本，隨機數、支持的密碼套件供服務端選擇，具體的包數據如下

啟動TLS握手過程， 提供自己所能支持各種演算法，同時提供一個將來所能用到的隨機數 。

ContentType指示TLS通信處於哪個階段階段，值22代表Handshake，握手階段，Version是TLS的版本1.2，在握手階段，後面鏈接的就是握手協議，這里是Client Hello，值是1，同時還會創建一個隨機數random給Server，它會在生成session key【對稱密鑰】時使用。之後就是支持的供服務端選擇的密碼套件，接下來等服務端返回。

Handshake Type: Server Hello (2)，作為對Client Hello的響應 ， 確定使用的加密套件 : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)，密鑰協商使用 ECDHE，簽名使用 RSA，
數據通信通信使用 AES 對稱加密，並且密鑰長度是128位，GCM分組，同時生成一個服務端的random及會話ID回傳。

這一步伺服器將配置的證書【鏈】發送給客戶端，客戶端基於上文所述的證書鏈校驗證書的有效性，這里發送的證書是二進制格，可以利用wireshark右鍵「Export Packet Bytes」功能，導出.CER格式的證書。如下可以看到傳輸的證書鏈。

導出的CER格式的證書如下，最關鍵的就其公鑰跟數字簽名。

Server Key Exchange是針對選定的ECDHE協商所必須的步驟，Diffie-Hellman模型解釋如下：

大意就是ephemeral Diffie-Hellman不會使用證書中的靜態公鑰參與對稱秘鑰的生成，而是需要服務端與客戶端通過彼此協商確定對稱秘鑰，而D-H演算法模型需要兩對非對稱秘鑰對，各端保留自己的私鑰，同時握有雙方的公鑰，然後基於D-H演算法雙端可以算出一樣的對稱加密秘鑰，而這就需要C/S互傳自己的公鑰

服務端做完這一步，其實ECDHE演算法中服務端需要提供的信息已經結束，發送 Server Hello Done告訴客戶端，然後等待客戶端回傳它的D-H公鑰。

演算法：

其中p和g是公開的DH參數，只要P是一個足夠大的數，在不知道私鑰的情況下，即使截獲了雙方的公鑰，也是很難破解的。

客戶端收到服務端的證書後，利用信任鏈檢測證書有效性，同時也會同Server Key Exchange 類似，將自己的Diffie-Hellman公鑰發送給Server端，

至此，ECDHE協商所需要的信息都傳輸完畢， 雙方都可以基於ECDHE演算法算出的共享密鑰，同時結合之前的隨機數生成最終的對稱加密秘鑰：

之後客戶端發送Change Cipher Spec與 Encrypted Handshake Message標識握手完成，同時傳輸一個加密的數據給Server，驗證雙方確立的秘鑰是否正確，這就需要服務端也要重復這個操作給客戶端，這樣才能驗證彼此的加解密一致，即服務端也要來一次Encrypted Handshake Message回傳給客戶端校驗，

走完如上流程，雙方就確認了正確的對稱加密通道，後面就是TLS的數據通信，其Record Layer的ContentType 也會變成 Content Type: Application Data (23)：

最終對稱會話密鑰包含三部分因子：

Client Hello與Server Hello階段交換的隨機數，是為了提高秘鑰的「隨機」程度而進行的，這樣有助於提高會話密鑰破解難度。

HTTPS通過加密與完整性校驗可以防止數據包破解與篡改，但對於主動授信的抓包操作是沒法防護，比如Charles抓包，在這個場景用戶已經風險，並且將Charles提供的證書信任為根證書，這從源頭上構建了一條虛擬的信任鏈：在握手階段，Charles利用自己的公鑰，生成客戶端可以信任的篡改證書，從而可以充作中間人進而抓包，所謂中間人攻擊，感覺跟Https抓包原理一樣，都是要強制添加一個自己的信任根證書。

D. ssl會話建立的過程（原理）是什麼

ssl會話建立過程主要就是加密和解密的過程。主要是利用了非對稱加密來保證密碼的安全，利用簽名來保證證書和信息沒有被修改。
首先是客戶端和伺服器端加密技術的溝通，統一後面通信適用的加密技術。
第二步是伺服器將自己的身份以證書的方式發送給客戶端。同時非對稱加密的公鑰則是附帶在證書的信息中。證書本身也附帶一個證書電子簽名，這個簽名用來驗證證書的完整性和真實性，可以防止證書被串改。另外，證書還有個有效期。
第三部客戶端發送自己的證書給伺服器端。
到這里雙方完成了非對稱加密的key交換。
第四部是證書的驗證工作，雙方對對方的證書完成驗證的工作。同時客戶端會使用之前協商好的加密套件和session secret加密一段Finish的數據傳送給服務端，此數據是為了在正式傳輸應用數據之前對剛剛握手建立起來的加解密通道進行驗證。
第五部是最後一步，服務端在接收到客戶端傳過來的PreMaster加密數據之後，使用私鑰對這段加密數據進行解密，並對數據進行驗證，也會使用跟客戶端同樣的方式生成session secret，一切准備好之後，會給客戶端發送一個ChangeCipherSpec，告知客戶端已經切換到協商過的加密套件狀態，准備使用加密套件和session secret加密數據了。之後，服務端也會使用session secret加密後一段Finish消息發送給客戶端，以驗證之前通過握手建立起來的加解密通道是否成功。