ssl原理--https://www.cnblogs.com/softidea/p/6958394.html
隨筆- 3423 文章- 0 評論- 236
圖解HTTPS建立過程
閱讀目錄
關於網路安全加密的介紹可以看之前文章：
1. 網路安全——資料的加密與簽名,RSA介紹
2. Base64編碼、MD5、SHA1-SHA512、HMAC(SHA1-SHA512)
3. When I see you again(DES、AES、RSA、Base64、MD5加密原理介紹，程式碼實現)
HTTPS建立過程相當複雜，下圖為示意圖，可以有整體認識，一般我們程式設計知道這些已足夠。
如果你想仿照HTTPS實現類似加密，可以閱讀下具體過程，作為參照
準備工作（對應圖中prepare1234）
可以看到，在客戶端向伺服器發起請求前，還有一些準備工作要做，或者說是有一些工作已經做好了。
- 從CA證書頒發機構，獲取數字證書。
- 伺服器：生成一對公私鑰S.pub，S.pri，私鑰自己保留，用於解密和簽名，不能外洩。將公鑰S.pub，身份資訊，傳給CA(Certificate Authority)機構；
- CA機構：也有公私鑰C.pub,C.pri；由S.pub，身份資訊另外附加CA簽名生成數字證書（簽名使用C.pri進行簽名）
- 將數字證書頒發給申請者（伺服器）
- 客戶端（比如我們經常使用的瀏覽器），為了安全性，會內建一份CA根證書，它包含C.pri，用於對數字證書驗證
發起連結
https使用的是443埠，而http使用的是80埠
TCP埠號是一個2位元組的整型，處於TCP報文段的前四個位元組（2位元組源埠號，2位元組目的埠號）。
很明顯範圍是0~65535。其中0~1023具有特殊意義，已經被繫結，比如上面說的443，80，還有ftp的21埠。從1024~49151也具有特殊含義，但是還沒有被用完，比如8080埠重定向。剩下的我們就可以隨便使用，自定義了。
其實之前在嵌入式開發中，沒有連線外網，也沒有使用瀏覽器等等這些。所以埠完全自定義隨便用，不用擔心衝突：）。
下面的過程為具體詳細一點的過程，如果不想看，可以完全只看示意圖即可，對我們平時開發用處並不大。或者你在用wireshark類似的抓包工具時看的抓狂不認識，可以看看（反正我用Charles抓包）：
1 客戶端發起請求（對應圖中1）
同樣需要三次握手，建立TCP連線(毫無疑問HTTPS也是基於TCP的)
2 客戶端傳送Client Hello包（對應圖中2）
- 隨機數
裡面有1970年1月1日到現在的秒數，後面還有一個客戶端發來的隨機數Client.random
- Session ID
如果客戶端與伺服器費盡周折建立了一個HTTPS連結，剛建完就斷了，也太可惜，所以用Session ID將其儲存，如果下次再來可以直接使用之前的連結進行對話(對稱金鑰)。
- 密文族
告訴伺服器，自己支援的加密演算法種類
- Server_name
3 Server Hello（對應圖中2）
- 隨機數：對應伺服器時間，伺服器sever.random
- Seesion ID，如果客戶端發給伺服器的session ID在服務端有快取，服務端會嘗試使用這個session；否則伺服器會啟用新的並返回給客戶端；
- 伺服器挑選一個密文族
4 Certificate（對應圖中2）
伺服器終於發來我們想要的數字證書，包含了：簽發機構、過期時間、主題名稱、公共金鑰資訊、指紋資訊等等
5 Server Hello Done（對應圖中2）
伺服器傳送結束
6 客戶端驗證（對應圖中3）
客戶端從內建的CA根證書獲取C.pub，對伺服器傳送來的數字證書進行驗籤，如果一致，說明證書是CA頒發的（前提是C.pub是真實的，確實是CA機構的公鑰）。然後看看證書是否過期，域名是否匹配
7 生成對稱金鑰（對應圖中4、5、6）
客戶端根據之前的：Client.random + sever.random + pre-master生成對稱金鑰
經過S.pub加密傳送給伺服器，之後即可通過對稱金鑰進行通訊。（就是之前我們熟悉的http）
最後
在整個過程中，一共涉及2對公私金鑰對，一對由伺服器產生，主要用於加密，一對由CA產生，主要用於簽名。
為什麼要多一個CA呢？
假設沒有CA，那麼如果伺服器返回的包含公鑰的包被hack擷取，然後hack也生成一對公私鑰，他將自己的公鑰發給客戶端。hack得到客戶端資料後，解密，然後再通過伺服器的公鑰加密發給伺服器，這樣資料就被hack獲取。
有了CA後，客戶端根據內建的CA根證書，很容易識別出hack的公鑰不合法，或者說hack的證書不合法。
http://www.cnblogs.com/mddblog/p/6948980.html
標題中的新版指：版本 56.0.2924.87 (64-bit)
原來的版本可以點選綠色的小鎖進入檢視頁面，新版的已經改了
新版的進入方式為F12-->Security選項卡（找不到的點右箭頭>>）,然後點選View certificate
SSL協議的握手過程
SSL 協議既用到了公鑰加密技術又用到了對稱加密技術，對稱加密技術雖然比公鑰加密技術的速度快，可是公鑰加密技術提供了更好的身份認證技術。SSL 的握手協議非常有效的讓客戶和伺服器之間完成相互之間的身份認證，其主要過程如下：
①客戶端的瀏覽器向伺服器傳送客戶端SSL協議的版本號，加密演算法的種類，產生的隨機數，以及其他伺服器和客戶端之間通訊所需要的各種資訊。
②伺服器向客戶端傳送SSL協議的版本號，加密演算法的種類，隨機數以及其他相關資訊，同時伺服器還將向客戶端傳送自己的證書。
③客戶利用伺服器傳過來的資訊驗證伺服器的合法性，伺服器的合法性包括：證書是否過期，發行伺服器證書的CA 是否可靠，發行者證書的公鑰能否正確解開伺服器證書的“發行者的數字簽名”，伺服器證書上的域名是否和伺服器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開；如果合法性驗證通過，將繼續進行第四步。
④使用者端隨機產生一個用於後面通訊的“對稱密碼”，然後用伺服器的公鑰（伺服器的公鑰從步驟②中的伺服器的證書中獲得）對其加密，然後傳給伺服器。
⑤伺服器用私鑰解密“對稱密碼”(此處的公鑰和私鑰是相互關聯的，公鑰加密的資料只能用私鑰解密，私鑰只在伺服器端保留。詳細請參看： http://zh.wikipedia.org/wiki/RSA%E7%AE%97%E6%B3%95)，然後用其作為伺服器和客戶端的“通話密碼”加解密通訊。同時在SSL 通訊過程中還要完成資料通訊的完整性，防止資料通訊中的任何變化。
⑥客戶端向伺服器端發出資訊，指明後面的資料通訊將使用的步驟⑤中的主密碼為對稱金鑰，同時通知伺服器客戶端的握手過程結束。
⑦伺服器向客戶端發出資訊，指明後面的資料通訊將使用的步驟⑤中的主密碼為對稱金鑰，同時通知客戶端伺服器端的握手過程結束。
⑧SSL 的握手部分結束，SSL 安全通道的資料通訊開始，客戶和伺服器開始使用相同的對稱金鑰進行資料通訊，同時進行通訊完整性的檢驗。
