參考HTTPS的加密流程|一篇文章讀懂HTTPS及其背后的加密原理|HTTPS協(xié)議詳解|Https加密過程|Https握手過程
HTTPS（全稱： Hypertext Transfer Protocol Secure，超文本傳輸安全協(xié)議）尚猿，是以安全為目標的HTTP通道洪橘，簡單講是HTTP的安全版筐赔。
- HTTP： 直接通過明文在瀏覽器和服務(wù)器之間傳遞信息。
- HTTPS： 采用 對稱加密 和 非對稱加密 結(jié)合的方式來保護瀏覽器和服務(wù)端之間的通信安全迫吐。
對稱加密算法加密數(shù)據(jù)+非對稱加密算法交換密鑰+數(shù)字證書驗證身份=安全
HTTPS其實是有兩部分組成：HTTP + SSL / TLS闲延，也就是在HTTP上又加了一層處理加密信息的模塊。服務(wù)端和客戶端的信息傳輸都會通過TLS進行加密呈队，所以傳輸?shù)臄?shù)據(jù)都是加密后的數(shù)據(jù)。
- 傳統(tǒng)的HTTP協(xié)議通信：傳統(tǒng)的HTTP報文是直接將報文信息傳輸?shù)絋CP然后TCP再通過TCP套接字發(fā)送給目的主機上唱歧。
- HTTPS協(xié)議通信：HTTPS是HTTP報文直接將報文信息傳輸給SSL套接字進行加密宪摧，SSL加密后將加密后的報文發(fā)送給TCP套接字，然后TCP套接字再將加密后的報文發(fā)送給目的主機颅崩，目的主機將通過TCP套接字獲取加密后的報文給SSL套接字几于，SSL解密后交給對應(yīng)進程。
具體是如何進行加密沿后，解密沿彭，驗證的，且看下圖尖滚。
HTTPS加密請求（一次握手）過程
- 首先喉刘，客戶端發(fā)起握手請求，以明文傳輸請求信息漆弄，包含版本信息饱搏，加密-套件候選列表，壓縮算法候選列表置逻，隨機數(shù)，擴展字段等信息(
這個沒什么好說的备绽，就是用戶在瀏覽器里輸入一個HTTPS網(wǎng)址券坞，然后連接到服務(wù)端的443端口鬓催。) - 服務(wù)端的配置，采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書恨锚，可以自己制作宇驾，也可以向組織申請。區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過猴伶，才可以繼續(xù)訪問课舍，而使用受信任的公司申請的證書則不會彈出提示頁面。
這套證書其實就是一對公鑰和私鑰他挎。如果對公鑰不太理解筝尾，可以想象成一把鑰匙和一個鎖頭，只是世界上只有你一個人有這把鑰匙办桨，你可以把鎖頭給別人筹淫，別人可以用這個鎖把重要的東西鎖起來，然后發(fā)給你呢撞，因為只有你一個人有這把鑰匙损姜，所以只有你才能看到被這把鎖鎖起來的東西。 - 服務(wù)端返回協(xié)商的信息結(jié)果殊霞，包括選擇使用的協(xié)議版本 version摧阅，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method绷蹲、隨機數(shù) random_S 以及證書棒卷。(
這個證書其實就是公鑰，只是包含了很多信息瘸右，如證書的頒發(fā)機構(gòu)娇跟，過期時間等等。) - 客戶端驗證證書的合法性太颤，包括可信性苞俘，是否吊銷，過期時間和域名龄章。(
這部分工作是由客戶端的SSL/TLS來完成的吃谣，首先會驗證公鑰是否有效，比如頒發(fā)機構(gòu)做裙，過期時間等等岗憋，如果發(fā)現(xiàn)異常，則會彈出一個警示框锚贱，提示證書存在的問題仔戈。如果證書沒有問題，那么就生成一個隨機值。然后用證書（也就是公鑰）對這個隨機值進行加密监徘。就好像上面說的晋修，把隨機值用鎖頭鎖起來，這樣除非有鑰匙凰盔，不然看不到被鎖住的內(nèi)容墓卦。) - 客戶端使用公匙對對稱密匙加密，發(fā)送給服務(wù)端户敬。(
這部分傳送的是用證書加密后的隨機值落剪，目的是讓服務(wù)端得到這個隨機值，以后客戶端和服務(wù)端的通信就可以通過這個隨機值來進行加密解密了尿庐。) - 服務(wù)器用私鑰解密忠怖，拿到對稱加密的密匙。(
服務(wù)端用私鑰解密后屁倔，得到了客戶端傳過來的隨機值脑又，然后把內(nèi)容通過該隨機值進行對稱加密，將信息和私鑰通過某種算法混合在一起锐借，這樣除非知道私鑰问麸，不然無法獲取內(nèi)容，而正好客戶端和服務(wù)端都知道這個私鑰钞翔，所以只要加密算法夠彪悍严卖，私鑰夠復(fù)雜，數(shù)據(jù)就夠安全布轿。) - 傳輸加密后的信息哮笆，這部分信息就是服務(wù)端用私鑰加密后的信息，可以在客戶端用隨機值解密還原汰扭。
- 客戶端解密信息稠肘，客戶端用之前生產(chǎn)的私鑰解密服務(wù)端傳過來的信息，于是獲取了解密后的內(nèi)容萝毛。整個過程第三方即使監(jiān)聽到了數(shù)據(jù)项阴，也束手無策。
加密
客戶端和服務(wù)端之間的加密機制：
TLS協(xié)議是基于TCP協(xié)議之上的笆包，圖中第一個藍色往返是TCP的握手過程环揽，之后兩次橙色的往返，我們可以叫做TLS的握手庵佣。握手過程如下：
client1：TLS版本號+所支持加密套件列表+希望使用的TLS選項
Server1:選擇一個客戶端的加密套件+自己的公鑰+自己的證書+希望使用的TLS選項+（要求客戶端證書）歉胶；
Client2:(自己的證書)+使用服務(wù)器公鑰和協(xié)商的加密套件加密一個對稱秘鑰（自己生成的一個隨機值）；
Server2:使用私鑰解密出對稱秘鑰（隨機值）后巴粪，發(fā)送加密的Finish消息通今，表明完成握手
這里可能要提一下什么是對稱加密和非對稱加密：
一般的對稱加密像這樣：
encrypt(明文粥谬，秘鑰) = 密文
decrypt(密文，秘鑰) = 明文
共享密鑰加密也稱對稱密鑰加密衡创。采用的是使用相同密鑰對報文進行加密解密
我們可以將共享密鑰加密這樣理解：我們把我們要給別人的東西放到一個箱子里面帝嗡，然后給箱子上了一把鎖。當箱子到了我們想給的那個人
身上時璃氢，他也需要這把鑰匙才能開鎖。
這樣就產(chǎn)生了一個問題了狮辽，我們怎么將這把鑰匙安全的交給對方呢一也，如果鑰匙在半路被人截取了，那么對箱子有沒有加鎖有什么區(qū)別呢喉脖。因此
共享密鑰加密需要解決的一個大問題就是如何安全的將密鑰交給解密方椰苟。
也就是說加密和解密用的是同一個秘鑰。而非對稱加密是這樣的：
encrypt(明文树叽，公鑰) = 密文
decrypt(密文舆蝴，私鑰) = 明文
假設(shè)客戶發(fā)送報文，服務(wù)器接收報文题诵〗嗾蹋客戶在發(fā)送報文的時候需要對報文加密，服務(wù)器有兩把密鑰性锭，一把私鑰赠潦，一把公鑰〔莞裕客戶在發(fā)送報文前需要先向服務(wù)器獲取公鑰進行報文的加密她奥。這把公鑰只能加密，不能解密怎棱，因此被任何人截獲到都沒什么用處哩俭。服務(wù)器收到加密后的報文，使用私鑰解密拳恋。整個過程中只涉及到公鑰的獲取凡资，加密，密文傳輸诅岩，解密讳苦。并不涉及到解密用的私鑰傳輸。因此這種方式是安全的吩谦。但是涉及到太多細節(jié)鸳谜，整個流程
下來耗時耗費資源。
再拿上面那個例子式廷，這時候我們還想把一些東西鎖到箱子里給某人咐扭，我們稱他為大傻。我們先跟大傻聯(lián)系，大傻身上有兩把鑰匙蝗肪，我們稱為鑰匙A和鑰匙B袜爪。鑰匙A可以用來造鎖，但是造好的鎖自己卻不能開薛闪，只能通過鑰匙B來開辛馆。跟大傻取得聯(lián)系后大傻把鑰匙A給我們。我們拿著鑰匙A找造鎖師傅造了一把鎖豁延，并且給箱子上鎖昙篙。然后將帶鎖的箱子通過物流發(fā)給大傻，就算鑰匙A被強盜截取了诱咏，強盜也開不了箱子苔可。大傻收到箱子后使用那把鑰匙B進行開鎖，拿到東西袋狞。由于鑰匙B一直再大傻身上焚辅，所以不用擔心被人拿走。
加密和解密是需要不同的秘鑰的苟鸯。
經(jīng)過這幾次握手成功后同蜻，客服端和服務(wù)端之間通信的加密算法和所需要的密鑰也就確定下來了，之后雙方的交互都可以使用對稱加密算法加密了倔毙。
HTTPS為了追求性能埃仪，又要保證安全，采用了共享密鑰加密和公開密鑰加密混合的方式進行報文傳輸陕赃。
還是拿上面的鎖和箱子的例子來說明⊥嗨ⅲ現(xiàn)在我們嫌棄每次加鎖都要造個新的鎖效率太慢了麸拄。我們現(xiàn)在有兩個箱子狗准，一個箱子用于方我們要給大傻的東西久橙，并且
這個箱子加上了鎖。另一個箱子用于存放那把鎖的鑰匙诉儒。我們這時候找大傻拿到鑰匙A造了一把鎖后將那個存放鑰匙的箱子鎖起來葡缰，然后將這個箱子給大傻，
大傻拿到箱子使用鑰匙B開鎖拿到鑰匙忱反。這時候我們將那個存放了東西的箱子給大傻泛释，大傻就可以通過這把鑰匙開鎖拿到東西了。這樣以后我們就可以一直通過
這把鎖和箱子互相給東西了温算，而不用發(fā)一次數(shù)據(jù)造一次鎖了怜校。
就是說采用共有密鑰加密方式傳輸共享密鑰，當共享密鑰安全到達服務(wù)端后往后的數(shù)據(jù)就都采用該密鑰進行加密解密注竿。
