APP
什么是https？
https就是在http的基礎(chǔ)上加了一個(gè)TLS層 ，http把數(shù)據(jù)發(fā)給tls，tls經(jīng)過(guò)加密后再下發(fā)給tcp。
接收端tcp先把消息tls， tls解密后再返回給http
tls是怎么加密的？
在雙方建立連接的過(guò)程中， 客戶(hù)端與服務(wù)器先用非對(duì)稱(chēng)加密的方式協(xié)商出一套密鑰， 然后使用這個(gè)密鑰以對(duì)稱(chēng)加密的方式加密通信
什么是對(duì)稱(chēng)加密？?
對(duì)稱(chēng)加密就是通信雙方使用同一個(gè)密鑰，不同的算法進(jìn)行加密、解密
?
?經(jīng)典算法： DES（56 位密鑰，密鑰太短?逐漸被棄?）、AES（128 位、192 位、256 位密鑰， 現(xiàn)在最流?）
對(duì)稱(chēng)加密的致命缺點(diǎn)就是： 通信雙方必須事先知道這個(gè)密鑰，但現(xiàn)實(shí)網(wǎng)絡(luò)中危險(xiǎn)無(wú)處不在， 如何安全地傳輸密鑰呢
?
非對(duì)稱(chēng)加密
非對(duì)稱(chēng)加密就是通信雙方使用同一套算法， 用公鑰來(lái)加密得到密文， 用私鑰解密得到原數(shù)據(jù)
?
?在這種模型中， 客戶(hù)端和服務(wù)器都有一套自己的公鑰/私鑰， 通信開(kāi)始時(shí)， 雙方交換公鑰，?
客戶(hù)端給服務(wù)器發(fā)數(shù)據(jù)時(shí)用服務(wù)器的公鑰進(jìn)行加密， 服務(wù)器收到后用自己的私鑰解密
同理， 服務(wù)器給客戶(hù)端發(fā)數(shù)據(jù)時(shí)， 用客戶(hù)端的公鑰加密， 客戶(hù)端收到后再用自己的私鑰解密。
因?yàn)楣€加密后的數(shù)據(jù)，只有自己的那把私鑰才能解開(kāi)。 換言之， 客戶(hù)端用服務(wù)器公鑰加密后的數(shù)據(jù)， 客戶(hù)端自己都無(wú)法解開(kāi)，自然也就防止了數(shù)據(jù)泄露。
可是網(wǎng)絡(luò)中壞人無(wú)處不在， 我們知道通信開(kāi)始時(shí)，客戶(hù)端和服務(wù)器會(huì)交換公鑰， 如果這個(gè)時(shí)候公鑰被人竊取， 那么他雖然不能用公鑰解密通信雙方發(fā)出去的數(shù)據(jù)， 但是卻可以偽造數(shù)據(jù)，偽裝成客戶(hù)端、服務(wù)器
為了防止這種攻擊， 數(shù)字簽名誕生了?
?
?
現(xiàn)在，通信雙方發(fā)送數(shù)據(jù)時(shí)， 先對(duì)原數(shù)據(jù)進(jìn)行一次hash算法， 然后對(duì)hash值簽名（用自己的私鑰加密），將簽名附加到原數(shù)據(jù)后面一起發(fā)送給對(duì)方。? 對(duì)方收到數(shù)據(jù)后， 用公鑰解密得到hash值， 然后對(duì)收到的數(shù)據(jù)以相同的方式進(jìn)行hash算法， 如果得到的hash值相同，就說(shuō)明信息沒(méi)有被篡改。
這里涉及到幾個(gè)知識(shí)點(diǎn)：
1， 非對(duì)稱(chēng)加密中， 同一對(duì)密鑰， 公鑰加密的數(shù)據(jù)私鑰可以解密， 私鑰加密的數(shù)據(jù)公鑰也可以解密
2， 為什么不直接對(duì)原數(shù)據(jù)用私鑰加密后傳輸呢？ 因?yàn)橹苯舆@樣操作的話(huà)會(huì)讓簽名比原數(shù)據(jù)還要大， 浪費(fèi)系統(tǒng)資源
3， hash： 目前常用的hash算法有MD5, SHA1, SHA256等， hash不是加密， hash算法是不可逆的
?
現(xiàn)在再回到Https的問(wèn)題，?
既然非對(duì)稱(chēng)加密+數(shù)字簽名已經(jīng)解決了通信安全的問(wèn)題， 為什么Https還要用對(duì)稱(chēng)加密來(lái)進(jìn)行通信呢？
因?yàn)榉菍?duì)稱(chēng)加密算法復(fù)雜， 如果通信過(guò)程中全程使用非對(duì)稱(chēng)加密， 將會(huì)非常影響網(wǎng)絡(luò)性能
?
https建立通信的一般過(guò)程：
?
?
1， 客戶(hù)端 發(fā)送client hello,? ?header中會(huì)包含 可供服務(wù)端選擇的TLS版本， 可供服務(wù)端選擇的加密套件， 以及一個(gè)客戶(hù)端隨機(jī)數(shù)
2， 服務(wù)器端收到后， 發(fā)送server hello,? header中包含服務(wù)器端選擇的tls版本，加密套件，以及一個(gè)服務(wù)器隨機(jī)數(shù)
3， 服務(wù)器端發(fā)送服務(wù)器證書(shū)給客戶(hù)端， 一并發(fā)送的有： 服務(wù)器公鑰，服務(wù)器主機(jī)名， 證書(shū)的簽名，證書(shū)簽發(fā)機(jī)構(gòu)的公鑰/簽名等。
4， 客戶(hù)端收到公鑰后， 對(duì)公鑰進(jìn)行驗(yàn)證（一方面是合法性驗(yàn)證， 就是看你這個(gè)證書(shū)是不是合法機(jī)構(gòu)頒發(fā)的， 另一方面是看這個(gè)服務(wù)器主機(jī)名是不是自己想要通信的主機(jī)名）
驗(yàn)證通過(guò)后， 客戶(hù)端生成另一個(gè)隨機(jī)數(shù)Pre-master secret, 用服務(wù)器公鑰加密后發(fā)給服務(wù)器
?接下來(lái)客戶(hù)端和服務(wù)器就可以根據(jù) 客戶(hù)端隨機(jī)數(shù)+服務(wù)器隨機(jī)數(shù)+Pre-master secret 來(lái)生成master secret?
?(為什么需要這個(gè)Pre-master secret呢？ 因?yàn)橹暗目蛻?hù)端隨機(jī)數(shù)和服務(wù)器隨機(jī)數(shù)不是加密傳輸?shù)模?可能被竊取)
這個(gè)master secret包含客戶(hù)端加密密鑰， 服務(wù)端加密密鑰， 客戶(hù)端MAC secret， 服務(wù)器端MAC secret
(我們之前說(shuō)對(duì)稱(chēng)加密中， 雙方使用的是同一個(gè)密鑰， 那為什么這里要用兩個(gè)密鑰呢？? 是為了防止一種攻擊， 比如其他人拿到消息之后，把消息給你扔回來(lái)， 這時(shí)候如果用的是同一個(gè)密鑰， 你可能就會(huì)以為這是服務(wù)器發(fā)回來(lái)的消息)
MAC secret? ?帶密碼的hash算法， 用來(lái)驗(yàn)證身份， 而且它不能被公眾驗(yàn)證身份。
?
5， 客戶(hù)端通知服務(wù)器， 自己將使用加密通信
6， finish (把1-5的信息加在一起發(fā)出去， ，不包含密鑰)
?
?（4，5，6步在這里是一條請(qǐng)求）
7， 服務(wù)器端將使用加密通信
8， 服務(wù)器finish（1-7的信息加在一起發(fā)出去，不包含密鑰）
?
本文摘自 ：https://www.cnblogs.com/
