https是當(dāng)前網(wǎng)絡(luò)通信中保證傳輸消息安全的一種最為常用的協(xié)議，本文將闡述https的通信機(jī)制，道出其到底安全在哪。
https是在http上添加TLS/SSL層來保證信息在傳輸過程中的安全；這其中呢，主要包含三個關(guān)鍵技術(shù)：對稱加密、非對稱加密以及數(shù)字證書；
http協(xié)議中信息的傳輸是明文的，所以在傳輸過程中，攻擊者可以捕獲并竊取數(shù)據(jù)的內(nèi)容；
為了防止攻擊者在途中截取有效的數(shù)據(jù)，我們首先想到的就是對傳輸數(shù)據(jù)進(jìn)行加密；一種常用的高級加密算法AES（Advanced Encryption Standard）應(yīng)用于此；這是一種在計(jì)算機(jī)網(wǎng)絡(luò)中很常用的對稱加密算法，對稱加密算法需要通信雙方使用相同的密鑰對傳輸信息進(jìn)行加密和解密；
但是，接下來又有另一個問題，這個用于數(shù)據(jù)加解密的密鑰如何讓通信雙方同時持有呢？如果將key（密鑰）也通過明文傳輸過去，那么攻擊者也將拿到這個密鑰，之后對信息進(jìn)行加密傳輸也就沒什么意義了。
于是，https里面的另一個關(guān)鍵技術(shù)要登場了，那就是非對稱加密。知道了對稱加密是什么意思，那非對稱這個就一目了然了。非對稱加密算法會有兩個密鑰（key1/公鑰、key2/私鑰），用key1加密的數(shù)據(jù)，只有通過key2才能解密；同樣，通過key2加密的數(shù)據(jù)只能通過key1進(jìn)行解密。RSA就是一種常用的非對稱加密算法。
繼續(xù)回到AB兩端通信這個場景，我們現(xiàn)在使用RSA生成的兩個密鑰key1、key2來解決之前明文傳輸AES密鑰key的問題；步驟如下：
- 通過RSA算法生成一對密鑰key1、key2；B要和A進(jìn)行通信，A將key1傳遞給
- B將AES的密鑰key用key1進(jìn)行加密，發(fā)給A；攻擊雖然可以截獲key1和加密的數(shù)據(jù)，但是key1加密的數(shù)據(jù)只能通過key2解密，所以數(shù)據(jù)還是安全的
-
A用手中的key2解密用key1加密的數(shù)據(jù)，得到key；接下來A和B便可以通過這個對稱加密密鑰來進(jìn)行加密通信了
AES搭配RSA實(shí)現(xiàn)加密通信過程
到這邊，有些可能會有些疑惑，為何要先用非對稱加密去傳遞AES的key，然后再用這個key進(jìn)行加密傳輸？為何不直接使用RSA進(jìn)行加密傳輸呢？
這是因?yàn)镽SA加解密的耗時較長，如果傳輸消息使用非對稱加密，那么信息傳輸?shù)臅r間消耗將會較大；但是AES的耗時較小，所以我們通過RSA來保證AES密鑰的安全傳遞，這樣既保證了數(shù)據(jù)傳輸過程的安全，又避免不會在數(shù)據(jù)加解密上消耗太多時間。有興趣的同學(xué)可以再去深究下RSA算法原理。
到這邊可以圓滿大結(jié)局了么？還不行。這樣還是擋不住中間人攻擊?，F(xiàn)在來看下這樣一個場景：
- B向A發(fā)起https請求，通過RSA算法生成一對密鑰key1、key2
- A將key1發(fā)送給B，中間人出現(xiàn)，將key1截?cái)?/li>
- 中間人自己通過RSA算法生成另一對密鑰fakeKey1、fakeKey2，將fakeKey1發(fā)送給B
- B誤以為fakeKey1這是A發(fā)來的密鑰key1，用fakeKey1對key進(jìn)行加密傳遞出去
- 中間人攔截加密數(shù)據(jù)，用fakeKey2解密出fakeKey1加密的key；至此，中間人已經(jīng)獲取AB之間通信使用的對稱密鑰key
- 中間人將獲得的key，再通過key1進(jìn)行加密發(fā)送給A；A誤以為和B完成了密鑰key的交換
-
AB使用對稱密鑰key進(jìn)行加密通信，中間人也知道這個key，所以~~
中間人攻擊
到這，仿佛陷入了死局，怎么搞？
https最后一個關(guān)鍵技術(shù)數(shù)字證書，這時候就要登場了。
我們在上面遇到的問題：無法確認(rèn)傳過來的公鑰是否為A的傳的公鑰，可能在傳輸途中被換包或者篡改；數(shù)字證書就是要用來解決這個問題的。
站點(diǎn)首先將自己的通信公鑰以及站點(diǎn)身份等信息合成一份申請，遞交給權(quán)威的證書頒發(fā)機(jī)構(gòu)CA（certificate authority）；這份申請，叫做CSR（Certificate signing request）
)。這個CSR主要包含就是站點(diǎn)的公鑰以及申請方的各類信息。
CA拿到這份信息后，跟根據(jù)約定的規(guī)范格式通過hash算法，生成內(nèi)容的散列值；然后通過CA的私鑰對這段散列值進(jìn)行加密，生成數(shù)字簽名DA（Digital Signature）；最后將站點(diǎn)的CSR和這段CSR的數(shù)字簽名合在一起，成為頒發(fā)給站點(diǎn)的數(shù)字證書DC(Digital Certificate)。
現(xiàn)在站點(diǎn)擁有了CA認(rèn)證的公鑰證書，有瀏覽器想跟站點(diǎn)進(jìn)行https通信時，站點(diǎn)會將自己的公鑰證書發(fā)給瀏覽器；瀏覽器會使用已植入在內(nèi)的CA公鑰解密證書的簽名，得到站點(diǎn)CSR的hash值，然后瀏覽器用CRS部分算一個hash值， 將解密后的hash值進(jìn)行比較；相等則認(rèn)證通過，證書中的公鑰為站點(diǎn)的公鑰；不相等，則認(rèn)證失敗，提示用戶站點(diǎn)存在風(fēng)險。
至此，我們已經(jīng)安全的獲得了站點(diǎn)的公鑰，之后就可以按照文章上半部分所寫的那樣，進(jìn)行https協(xié)議通信了
