HTTPS的由來
普通網站通常都是使用Http協議進行交互,其包在網絡中都是明文傳輸的,若是關鍵的信息如支付密碼等,在網絡中被攔截獲取的話,那就很危險了,這時候黑客就能僞造用戶的請求,從而盜走資金。經常使用的抓包工具備不少如fiddler、wireshark,有興趣的話能夠本身百度瞭解一下。爲了包信息的安全.保證在端到端的過程當中,任何節點攔截到的都是一段進行加密處理過的亂碼.HTTPS就爲此應運而生了。它能保證包的具體信息只能在兩端可見html
HTTPS的加密方式
首先.用最簡單的對稱加密,使用同一個密文,在兩端進行加解密交互。這方案顯然不行,密文在客戶端很容易被黑客揪出(再退一步講,兩端剛創建起鏈接時,確定要統一密文是多少,服務端在發送密文給客戶端的時候萬一黑客攔截到,那就呵呵了)。安全
那就再換一個方案,使用公匙私匙,服務端統一爲客戶端分發公匙,而後客戶端統一使用該公匙加密信息發送到服務端,該信息只有私匙能解開,這樣就能確保客戶端-服務端的信息不會被攔截並解密出來,由於服務端的私匙並無在網絡中傳輸過,黑客根本沒法獲取。網絡
按理來說這方案沒問題,但高級的黑客能夠攔截掉公匙而替換成本身的公匙給客戶端,客戶端將收到的黑客公匙進行加密傳輸,再發送給服務端,這時黑客再次攔截獲信息並用本身的私匙解密,再用服務端給的公網加密發給服務端。這個過程很是隱祕,服務端和客戶端徹底感知不到,而後黑客就呵呵咯工具
真是套路滿滿阿,那如何保證客戶端收到的公匙,就必定是服務端給的那個呢,這時候CA強勢殺出:讓我來網站
CA權威認證中心
CA全稱Certificate Authority(權威頒發機構),它是負責發放和管理數字證書的權威機構,並做爲電子商務交易中受信任的第三方,承擔公鑰體系中公鑰的合法性檢驗的責任。咱們能夠本身生成一套公私匙而後提交給CA審覈,或者直接跟CA申請由其頒發(每一個證書對應一個域名地址)。當客戶端獲取到服務端發來的公匙時, CA權威機構會統一進行認證辨別此公匙是否有效(肯定是由CA機構頒發的而且與域名匹配得上)。一切順利那就能夠進行交互了加密
參考文獻: HTTPS科普掃盲帖 講解很是透徹spa