完全搞懂https原理

我終於完全理解了https原理！！！激動之下，寫一篇博客，搞一波分享！！！

本篇博客比較精彩的地方：

思惟方式：也是借鑑一位大佬的，寫得很棒。https://blog.csdn.net/guolin_blog/article/details/104546558
圖文並茂，簡單明瞭，化繁爲簡。

關於https原理，有很是很是多的博客，然而其中不少博主都不必定徹底理解，只是單純地爲了寫博客而寫博客。

基礎知識鋪墊

雖然咱們不必定是專門搞密碼學的，但多多少少仍是要知道一點的。否則的話，接下來的知識可能沒法理解。
一、對稱加密算法：加密和解密使用相同的密鑰。
二、非對稱加密算法：加密和解密使用不一樣的密鑰，一個成爲公鑰，另外一個則是私鑰，二者是成對的。公鑰用來加密，私鑰用來解密。
備註：https原理中，這兩種算法都用到了。至於其餘加密算法，咱就很少說了。

http傳輸原理

（其實呢，瀏覽器和服務器之間信息傳輸並非直接的，中間還會有個中間路由。）

解釋一下http到底不安全在哪裏

正如圖中所看到的，若是有人經過中間路由惡意篡改傳輸的信息，那會怎樣？瀏覽器接收到的信息都被篡改了，後果不堪設想。
https所以誕生。在http基礎上加上了SSL/TLS協議。就是爲了防止以上的這種狀況。

思惟風暴：

試想，若是是咱們，咱們會怎麼處理這種狀況呢？跟着這個思惟走下去，你便會提現到這種思惟的魅力
首先，咱們很天然地會想到，信息在傳輸期間進行加密，瀏覽器和服務器那邊再進行解密。這樣的話，即便監聽者獲得了這些信息，他也沒法進行解密。這樣便安全了。

那又有問題了，以上這種加密即是採用的對稱加密，那密鑰怎麼獲得呢？

咱們知道，瀏覽器一開始是向服務器發送請求的，那密鑰一定是瀏覽器發給服務器的。這樣的話，監聽者仍是能夠經過中間路由獲得這個密鑰，而後經過密鑰進行解密，治標不治本。或者直接隨便惡意篡改這個密鑰，後果可想而知。那怎麼辦呢？

咱們可能也很天然地想到，若是把瀏覽器發給服務器的密鑰進行加密，不就能夠了嗎？這樣的話，的確解決了問題。

把瀏覽器發給服務器的密鑰進行加密，咱們很天然地會想到，使用非對稱加密算法即可以實現。那怎麼作到這一點呢？

這也是個計算機屆的難題，卡在這兒，走不下去了。

某一天，某個天才忽然想到了，瀏覽器給服務器發送一個請求。打破常規，若是請求兩次呢？第一次只請求公鑰，獲得公鑰後，瀏覽器生成一個密鑰（這裏稱做瀏覽器密鑰），使用公鑰進行加密，第二次請求附帶上使用公鑰進行加密的瀏覽器密鑰，服務器接收後，使用私鑰進行解密不就獲得了瀏覽器密鑰嗎？接下來，傳輸信息，只需經過瀏覽器密鑰進行加密解密不就成了。這樣的話，問題不就解決了嗎？的確如此。

最後一個問題，服務器端的公鑰和私鑰怎麼來的呢？
這便誕生出了CA機構。
CA機構專門給網站服務器端添加公鑰和私鑰（就是所謂的數字簽名證書），固然還有一些其餘的信息，好比網站域名、證書有效期等。
還有一點要說明一下，瀏覽器是如何驗證公鑰的？
瀏覽器獲得服務器發送的公鑰後，會和系統內置的證書進行比對即可驗證真假了。

總結：

https原理：

一、瀏覽器給服務器發送一個http請求，獲得公鑰。
二、將公鑰和系統內置證書進行對比，並驗證有效期，而後生成一個隨機瀏覽器密鑰並使用公鑰加密，接着再發送一個http請求。
三、服務器接收到用公鑰加密的瀏覽器密鑰後，使用私鑰進行解密。
四、接下來傳輸便經過瀏覽器密鑰進行加密解密。即便監聽者經過中間路由接收到了信息，也沒法解密，惡意篡改的話，瀏覽器和服務器端會識別到，中斷鏈接。這樣的話，便安全了。

怎麼升級到https？

將http升級到https，比較簡單，購買SSL證書，而後將證書安裝到網站服務器端便可。通常而言，購買SSL證書的話，第一年是免費的，而後每一年差很少要4k左右。（還挺貴的。。。）固然了，http升級到https，網站訪問速度要稍微下降一些的，畢竟有個加密解密的過程嘛！

知識在於分享傳播，在分享傳播的過程當中，會逐步進行凝練和昇華！