1,在理解 HTTPS SSL TLS 以前先對經常使用的加密方式進行一個簡述:算法
(1),對稱加密: 採用一個密鑰,對明文進行加密生成密文,相反採用此密鑰可對加密後的密文進行解密還原成明文.瀏覽器
表明算法有,DES,3DES,AES 等安全
(2),非對稱加密: 公鑰加密,私鑰解密. 網上有個比喻很形象(公鑰比如一把開着的鎖頭, 私鑰比如這把鎖頭的鑰匙全世界就只有一把鑰匙,由你保管,服務器
若要與人通訊,將鎖頭給別人好了.別人拿到這個鎖頭將重要信息鎖在起來.而後全世界就只有你一我的能打開這個鎖)網絡
表明算法有,RSA ,DSA 等.性能
(3),摘要算法: 即將明文數據經過摘要算法生成一小段(固定長度)密文數據. 但經過密文沒法還原程明文,算法不可逆.網站
一般用來驗證實文數據是否完整,是否正確.加密
表明算法:MD5 ,SHAspa
2,思考: 瞭解上述以後咱們要登陸咱們的支付寶,網銀等,要怎樣去實現.server
(1),採用對稱加密??? 訪問, 支付寶,網銀等,服務端和客戶端雙方約定一個密鑰. 服務端客戶端經過這個密鑰進行加密和解密.
問題來了: 服務端和客戶端怎麼去協商密鑰 ? 服務端生成密鑰而後告知給客戶端 ? 或者客戶端生成後發送給服務端?
固然這樣行不通:發送過程當中若是被其餘人抓到網絡包後很容易就看出密鑰了.
(2), 採用非對稱加密 ??? , 服務端生成公鑰,和私鑰.將公鑰經過網絡傳輸給客戶端,客戶端經過公鑰將
賬號密碼等信息加密 發送給服務端 ???
問題來了: (1),這個只能單方面客戶端發送重要信息給服務端. 若是服務端要發送重要信息給客戶端怎麼辦?
(2),答案有人可能想到了服務端和客戶端,都各生成一對公鑰和私鑰, 而後再交換公鑰,這不就妥了.
沒錯這樣是能夠進行保密傳送. 可是這樣也帶來了性能上的問題.若是是傳送大量的數據時.
可能會影響性能.
(3),採用摘要算法 : 這就更不可能了.摘要算法只能保證數據的正確性和完整性.
4,結論:
經過以上分析.有人可能已經有告終果 : 採用單種的加密方式不能達到目的,若是把他們配合使用不就ok了.
沒錯HTTPS ,SSL 就是這樣一個東西: 採用 對稱加密進行傳輸加密數據,用非對稱加密來交換對稱加密所使用的密鑰.
固然爲了保證你訪問的網站是正確的,即 防止將賬號密碼等信息交給釣魚網站. 數字證書應運而生了.
數字證書確保您是再與一個可信的人(可信的網站)在交流. 是在與一個值得託付終身的人在戀愛.
如下具體的步驟來源與互聯網, 展現HTTPS SSL 等交互流程
(1). 客戶端發起HTTPS請求
這個沒什麼好說的,就是用戶在瀏覽器裏輸入一個https網址,而後鏈接到server的443端口。
(2). 服務端的配置
採用HTTPS協議的服務器必需要有一套數字證書,能夠本身製做,也能夠向組織申請。區別就是本身頒發的證書須要客戶端驗證經過,才能夠繼續訪問,而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇,有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。若是對公鑰和私鑰不太理解,能夠想象成一把鑰匙和一個鎖頭,只是全世界只有你一我的有這把鑰匙,你能夠把鎖頭給別人,別人能夠用這個鎖把重要的東西鎖起來,而後發給你,由於只有你一我的有這把鑰匙,因此只有你才能看到被這把鎖鎖起來的東西。
(3). 傳送證書
這個證書其實就是公鑰,只是包含了不少信息,如證書的頒發機構,過時時間等等。
(4). 客戶端解析證書
這部分工做是有客戶端的TLS來完成的,首先會驗證公鑰是否有效,好比頒發機構,過時時間等等,若是發現異常,則會彈出一個警告框,提示證書存在問題。若是證書沒有問題,那麼就生成一個隨機值。而後用證書對該隨機值進行加密。就好像上面說的,把隨機值用鎖頭鎖起來,這樣除非有鑰匙,否則看不到被鎖住的內容。
(5). 傳送加密信息
這部分傳送的是用證書加密後的隨機值,目的就是讓服務端獲得這個隨機值,之後客戶端和服務端的通訊就能夠經過這個隨機值來進行加密解密了。
(6). 服務段解密信息
服務端用私鑰解密後,獲得了客戶端傳過來的隨機值(私鑰),而後把內容經過該值進行對稱加密。所謂對稱加密就是,將信息和私鑰經過某種算法混合在一塊兒,這樣除非知道私鑰,否則沒法獲取內容,而正好客戶端和服務端都知道這個私鑰,因此只要加密算法夠彪悍,私鑰夠複雜,數據就夠安全。
(7). 傳輸加密後的信息
這部分信息是服務段用私鑰加密後的信息,能夠在客戶端被還原。
(8). 客戶端解密信息
客戶端用以前生成的私鑰解密服務段傳過來的信息,因而獲取瞭解密後的內容。整個過程第三方即便監聽到了數據,也一籌莫展。