問題描述：HTTP的請求和響應(yīng)都是明文傳輸，有安全隱患
HTTPS：HTTPS并不是一個(gè)單獨(dú)的協(xié)議，是在 TCP 和 HTTP 之間加入了 SSL/TLS 安全協(xié)議，使得報(bào)文能夠加密傳輸，SSL是TLS的前身，現(xiàn)在使用的大多都是TLS。
對(duì)稱加密與非對(duì)稱加密
對(duì)稱加密：發(fā)送方和接收方約定一個(gè)同樣的規(guī)則也就是同一個(gè)密鑰來對(duì)傳輸?shù)男畔⑦M(jìn)行加密和解密。
非對(duì)稱加密：用兩個(gè)密鑰來進(jìn)行加密和解密，公鑰是所有人都可以得到的密鑰，私鑰是只有持有方才知道的密鑰。一般情況下服務(wù)器擁有公鑰和私鑰，然后公布自己的公鑰在網(wǎng)絡(luò)上，客戶端用這個(gè)公鑰進(jìn)行數(shù)據(jù)加密，此時(shí)只有服務(wù)器上的私鑰才能進(jìn)行解密。
TLS握手過程
TLS是同時(shí)使用了對(duì)稱加密和非對(duì)稱加密。
首先服務(wù)器需要向CA（證書授權(quán)中心）申請TLS證書來表明自己是經(jīng)過驗(yàn)證的真實(shí)服務(wù)器，而不是偽造的。TCP三次握手的過程還是不變的，然后開始TLS握手。文章來源：http://www.zghlxwxcb.cn/news/detail-846730.html
- 客戶端向服務(wù)器發(fā)送自己支持的TLS版本，支持的加密算法和一個(gè)隨機(jī)數(shù)（第1個(gè)隨機(jī)數(shù)）。
- 服務(wù)器響應(yīng)自己確認(rèn)的TLS版本，加密的算法和自己生成的一個(gè)隨機(jī)數(shù)（第2個(gè)隨機(jī)數(shù)），然后服務(wù)器繼續(xù)發(fā)送自己的證書和公鑰。
- 客戶端驗(yàn)證了服務(wù)器的證書后，會(huì)生成一個(gè)預(yù)主密鑰（第3個(gè)隨機(jī)數(shù)），并且用收到的公鑰加密然后發(fā)送出去。
- 服務(wù)器收到后用私鑰進(jìn)行解密得到客戶端的預(yù)主密鑰，此時(shí)只有客戶端和服務(wù)器知道這個(gè)預(yù)主密鑰是什么，除非私鑰被泄漏了。
- 然后客戶端和服務(wù)器都使用預(yù)主密鑰+第1隨機(jī)數(shù)+第2隨機(jī)數(shù) 計(jì)算出一個(gè)會(huì)話密鑰。
- 也就是到了這一步，前面的加密都是非對(duì)稱加密，目的就是得到這個(gè)會(huì)話密鑰，之后的實(shí)際數(shù)據(jù)傳輸都使用這個(gè)會(huì)話密鑰進(jìn)行加密解密，所以正常的數(shù)據(jù)傳輸部分用的就是對(duì)稱加密了。
HTTPS連接過程一定可靠嗎
有這么一種情況，客戶端通過瀏覽器向服務(wù)端發(fā)起 HTTPS 請求時(shí)，被「假基站」轉(zhuǎn)發(fā)到了一個(gè)「中間服務(wù)器」，客戶端是和「中間服務(wù)器」完成了 TLS 握手，然后這個(gè)「中間服務(wù)器」再與真正的服務(wù)端完成 TLS 握手。
從客戶端的角度看，其實(shí)并不知道網(wǎng)絡(luò)中存在中間服務(wù)器這個(gè)角色。那么中間服務(wù)器就可以解開瀏覽器發(fā)起的 HTTPS 請求里的數(shù)據(jù)，也可以解開服務(wù)端響應(yīng)給瀏覽器的 HTTPS 響應(yīng)數(shù)據(jù)。
但這有個(gè)前提，就是用戶點(diǎn)擊接受了中間服務(wù)器的證書。
因?yàn)橹虚g服務(wù)器與客戶端的 TLS 握手過程中，會(huì)發(fā)送自己偽造的證書給瀏覽器，而這個(gè)偽造的證書是能被瀏覽器識(shí)別出是非法的，于是就會(huì)提醒用戶該證書存在問題。文章來源地址http://www.zghlxwxcb.cn/news/detail-846730.html
到了這里，關(guān)于HTTPS、對(duì)稱/非對(duì)稱加密、SSL/TLS的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
