https+ssl詳解

這是轉載別人的寫的很好，(轉:崔永秀)

把這幾天學習到的關於ssl和https協議的內容在這裏分享一下，適合一些像我同樣的網絡協議初學者。

ssl協議的起源和歷史我就再也不多說了，就是那個Netscape 網景公司開發的，它的做用主要是提供了一種安全傳輸方式，咱們知道網上有不少的時候須要咱們去輸入用戶名和密碼，那麼假設咱們本身的電腦防病毒還能夠，可是用戶名和密碼確定仍是要經過互聯網來傳到服務器那裏，這個步驟就要通過不少的路由等，若是明文傳輸，就能夠在你的局域網內或者經過的路由中監聽，竊取你的用戶名密碼。

SSL協議位於TCP/IP協議與各類應用層協議之間。當咱們打開一個https的網頁時，步驟以下：

1. 客戶端經過SSL協議把服務器須要的客戶端的SSL版本信息，加密算法設置，會話數據，發送給服務器。

2. 服務器經過SSL協議把本身的SSL的版本信息，加密算法設置，會話數據和其餘通訊須要的信息發給客戶端。服務器也把服務器的證書發給客戶端，另外若是客戶端請求服務器資源須要客戶端認證，服務器端就會請求客戶端的證書。

3. 客戶端使用這些服務器發來的信息認證服務器。若是服務器不能被認證，那麼客戶將被提示一個警告，而且通知客戶不能創建加密和認證鏈接。若是服務器被成功認證，客戶端將進入第四步。

4. 使用到目前爲止的全部數據生成握手過程。客戶端(和服務器合做之下)爲會話建立一個pre-master secret(一個用在對稱加密密鑰生成中的 46 字節的隨機數字)。使用服務器的公共密鑰加密（在第二步的服務器的證書中得到公共密鑰），而後把這個加了密的pre-master secret發送給服務器。

5. 若是服務器請求客戶端認證（在握手過程是可選項），客戶端也須要標記一個特殊的數據包，客戶端和服務器都知道的。在這個過程當中，客戶端發送一個經過pre-master secret加密過的標記的數據包和客戶端本身的證書給服務器。

6. 若是服務器請求了客戶端的認證，那麼服務器就要嘗試去認證客戶端。（具體的看客戶端認證細節）若是客戶端認證不經過，會話將被終止。若是客戶端被認證經過，服務器將使用私有密鑰解密pre-master secret，而後執行一系列步驟生成master secret

7. 客戶端和服務器端使用master secret去生成會話密鑰。會話密碼是在ssl 會話的時候對稱密鑰被用來加密，解密信息校驗信息完整性的密鑰。（檢查會話過程當中任何數據改變）

8. 客戶端發送一個信息給服務器端，通知服務器端將來的信息將被會話密碼加密，而後客戶端發送一個單獨（加密）信息指示客戶端部分的握手會話已經完成。

9. 服務器發送一個信息通知客戶端將來的會話信息將被會話密碼加密，而後服務器發送一個單獨（加密）信息指示服務器部分的握手部分已經完成

10. SSL握手結束，開始正式會話。客戶端和服務器端使用對稱會話密鑰加密解密數據而且互相傳送校驗完整性。

11. 這是一個正常的操做過程和加密隧道。在任什麼時候候，當內部或者外部觸發條件（不是自動就是用戶手動），任何一端就要重新協商會話，全部的流程將重新開始。

有幾個問題我在學過以後一直在考慮：

1. 若是中間的路由從雙方發送證書的時候就開始監聽的話呢，是否就能夠竊取內容了？

答：否，服務器那邊有一個非對稱密鑰加密系統，首先他將公開密鑰發送給客戶端，客戶端接收以後爲會話建立一個pre-master secret(一個用在對稱加密密鑰生成中的 46 字節的隨機數字)，而後用服務器發送過來的公開密鑰加密，而後將加密後的內容發送給服務器，這兩個階段，若是有人監聽，即便竊取到也沒辦法，首先公開密鑰對全部人其實都是公開的，用公開密鑰加密後的內容是很是很是難解密的，只有用服務器本身有的私有密鑰解密才能夠。服務器獲取到46字節的隨機數字以後，經過這個來對未來要發送的加密內容加密，而這個解密方法以後對應的那個客戶端才知道，鑰匙是經過公開密鑰加密的，其餘人都不知道，全部就保證了內容的安全性。

2. 咱們本身建設的網站有時會使用沒有正式證書的ssl加密，瀏覽器會提醒用戶，默認建議關閉，證書是必要的嗎？

答：通過認證的證書其實就是確保網站的真實性，還有一些專門的使地址欄顯示爲綠色的也都是確保網站的真實性，防止一些頁面如出一轍的釣魚網站。

3. 用ssl協議以後，咱們輸入用戶名密碼就絕對安全了嗎？

答：否，ssl協議只能保證server和client傳輸之間的安全，若是你的電腦有木馬病毒，例如監聽鍵盤，瀏覽器惡意插件等，ssl可管不了這些。。。還有若是server收到攻擊，它的信息流失丟掉，這也不能保證的。