轉載請標明出處：http://blog.csdn.net/shensky711/article/details/52214842
本文出自: 【HansChen的博客】
Https通信基本過程
在通信過程中，https是如何保證通信的安全的？如何加密信息，如何防止中間人攻擊？
以下是客戶端發起https請求的時候的流程：
流程解析如下：
- 客戶端發送隨機數client_random和支持的加密方式列表
- 服務器返回隨機數server_random，選擇的加密方式和證書（經過ca頒發，或者自簽名的證書，該證書包含公鑰）
- 客戶端驗證證書，使用證書中的公鑰加密premaster secret發送給服務端
- 服務端使用私鑰解密得到premaster secret
- 兩端分別通過client_random，server_random和premaster secret生成master secret，用於對稱加密後續通信內容
整個過程主要的作用是讓雙方安全地協商出一個key，這個key會用於對稱加密中。第三方即使截取了所有的通信數據，也是無法獲取到這個key的。既然第三方無法獲取這個key，自然也對加密過的數據無可奈何了。大家看到這裏可能一臉懵逼，可能會有以下疑問：
- 這個過程是如何保證key不會被中間人竊取呢？
- 客戶端/服務端如何確認對方就是“正確的人”，而不是其他中間人呢？
什麼是RSA非對稱加密
在解答上面的問題之前，首先我們得先了解一些基本的知識：
RSA非對稱加密：RSA分爲公鑰和私鑰，從私鑰可以生成公鑰，但是不能通過公鑰生成私鑰。公鑰加密過的信息，只有私鑰能解開，私鑰加密的信息，只有公鑰能解開
https如何保證key不會被中間人竊取
在步驟（1）中，客戶端的隨機數client_random是完全可以被中間人竊取的，然後在步驟（2）中服務端返回的server_random也是完全可被中間人竊取的。關鍵是在步驟（3），客戶端會把生成的premaster secret通過公鑰進行加密，然後再發送給服務器，中間人當然也可以竊取加密後的premaster secret數據，但是中間人卻不能解密出原始的premaster secret，這是爲什麼呢？因爲公鑰加密的數據，只有私鑰能解開，而私鑰是保存在服務端，不會外泄的！通過步驟1-4，服務器和客戶端相互持有了client_random，server_random和premaster secret，而且只有客戶端和服務端纔有premaster secret，中間人是沒有的。這時候通過前面三個key，生成master secret用於對稱加密，確保通信安全。
爲何最終使用對稱加密，而不是全部通信都使用非對稱加密呢？猜測是因爲非對稱加密效率和速度不如對稱加密。而且對稱加密的安全性並不是不高，對稱加密的難點在於如何安全地交換key。
我一開始理解https的時候，遇到一個困惑：如果中間人從建立連接一開始就冒充服務器，轉發客戶端和服務端的所有數據，那麼所有數據在中間人眼裏應該都是透明的啊，中間人應該也能解密通信數據啊？是的，中間人確實是可以拿到所有數據，但是，中間人沒有服務器的私鑰！所以即使拿到了數據，也不能得到對稱加密的key。其實說白了，一個https請求，不知會經過多少箇中間人呢，所有路由轉發都有可能是中間人，都有可能攻擊你，但恰恰就是因爲沒有私鑰而不能竊取數據，他們只能轉發數據，但卻不能解密數據。
如何確認對方就是“正確的人”，而不是其他中間人呢
但是問題又來了，雖然通信內容不會被第三個人竊取了，但是我如何保證對方就是我想要找的人呢？
比如我要訪問www.baidu.com，確實有一個服務器給了我回復，但我怎麼確定這個是真的“百度”給我的回覆呢？萬一我的請求被劫持了呢？
這個就得依靠驗證步驟（2）裏的證書了。
什麼是證書呢？數字證書就是一個人或者組織在網絡世界中的身份證，其發證機關是證書管理機構(certificate authority,CA)，在這裏CA是一個權威的機構，我們可以信任他，他信任的站點，我們也會認爲是可信任的。個人電腦上無法對每一個網站都進行驗證，因爲這樣幾乎不可能，也不方便。在日常生活中，如果我們要驗證一個人的身份，通常的做法是查看他的身份證。我們信任身份證頒發機構即政府機構的公信力，因此只要驗證一個人的身份證不是僞造的，我們就相信這個人的身份和身份證上所描述的是一致的。
說到這裏，又有同學可能要懵逼了，通俗點講，就是所有網站都要去CA機構那裏去登記，然後CA會發給那麼網站一個“身份證”。但是我們如何驗證一個人身份證的真僞呢？CA機構也會提供一個工具給我們，我們用那個工具就可以驗證身份證的真僞。
- 網站身份證：網站證書，需要CA機構簽發
- 真僞辨認工具：CA證書
那麼，什麼是CA頒發的“身份證”呢？
- 服務端生成自己的證書請求文件（尚未被CA簽名），裏面包含了姓名、服務器私鑰對應的公鑰等信息
- CA機構對該證書進行簽名，也就是生成數字簽名，注意，這個簽名是用CA的私鑰加密過的
- 把原始的證書和生成的數字簽名合併在一起，形成證書
在https的步驟（2）的時候，服務器發給用戶的證書就是這個簽名過之後的證書，客戶端收到證書後，會使用CA的公鑰（這個是內置在瀏覽器的）對數字簽名進行解密得出一個信息摘要，然後用哈希算法自己算出信息摘要，對比摘要，一致的話，證明該證書是CA機構頒發的。因爲公鑰只能解開私鑰加密的數據，如果信息摘要是匹配的，那麼證明該加密數據是由CA機構用私鑰加密的，證書是可靠的。
到現在，我們終於可以愉快地確定對方的身份，愉快地通信了。主要是依賴一個CA公鑰來判別對方證書的真僞。
但是會有同學問了，萬一冒牌網站把正牌網站copy下來，轉發給我了怎麼辦，轉發的證書是由正牌網站copy的，肯定是真的，所以客戶端可以驗證通過的，那怎麼辦？確實是的，如果冒牌網站用正版網站的證書來忽悠客戶端，那麼客戶端確實是會被“忽悠”過去的，但是不用擔心，客戶端是依靠證書上的公鑰來生成premaster secret的，而公鑰對應的私鑰，冒牌網站是不可能拿得到的，也就不可能解密出正確的premaster secret，自然也無法正常和客戶端正常溝通了。
現在很多android應用的服務端雖然採用的是https，但是卻是沒有經過ca機構認證的（因爲要花錢），所以一般會自己給自己頒發數字證書（自己充當CA）。但國內很多開發者在android應用裏面採用的做法是信任所有證書，這樣是很不安全的，正確的做法應該是導入CA的證書，這樣才能在拿到證書後，判斷證書的真僞。
