https是當(dāng)前網(wǎng)絡(luò)通信中保證傳輸消息安全的一種最為常用的協(xié)議，本文將闡述https的通信機(jī)制屈糊，道出其到底安全在哪的榛。
https是在http上添加TLS/SSL層來(lái)保證信息在傳輸過(guò)程中的安全；這其中呢逻锐，主要包含三個(gè)關(guān)鍵技術(shù)：對(duì)稱加密夫晌、非對(duì)稱加密以及數(shù)字證書(shū)晓淀；
http協(xié)議中信息的傳輸是明文的，所以在傳輸過(guò)程中凶掰，攻擊者可以捕獲并竊取數(shù)據(jù)的內(nèi)容懦窘；
為了防止攻擊者在途中截取有效的數(shù)據(jù)稚配，我們首先想到的就是對(duì)傳輸數(shù)據(jù)進(jìn)行加密；一種常用的高級(jí)加密算法AES（Advanced Encryption Standard）應(yīng)用于此午衰；這是一種在計(jì)算機(jī)網(wǎng)絡(luò)中很常用的對(duì)稱加密算法冒萄，對(duì)稱加密算法需要通信雙方使用相同的密鑰對(duì)傳輸信息進(jìn)行加密和解密；
但是扇单，接下來(lái)又有另一個(gè)問(wèn)題奠旺，這個(gè)用于數(shù)據(jù)加解密的密鑰如何讓通信雙方同時(shí)持有呢施流？如果將key（密鑰）也通過(guò)明文傳輸過(guò)去鄙信，那么攻擊者也將拿到這個(gè)密鑰，之后對(duì)信息進(jìn)行加密傳輸也就沒(méi)什么意義了银受。
于是鸦采，https里面的另一個(gè)關(guān)鍵技術(shù)要登場(chǎng)了，那就是非對(duì)稱加密顶霞。知道了對(duì)稱加密是什么意思锣吼，那非對(duì)稱這個(gè)就一目了然了。非對(duì)稱加密算法會(huì)有兩個(gè)密鑰（key1/公鑰玄叠、key2/私鑰），用key1加密的數(shù)據(jù)隧膘，只有通過(guò)key2才能解密寺惫；同樣，通過(guò)key2加密的數(shù)據(jù)只能通過(guò)key1進(jìn)行解密。RSA就是一種常用的非對(duì)稱加密算法必尼。
繼續(xù)回到AB兩端通信這個(gè)場(chǎng)景，我們現(xiàn)在使用RSA生成的兩個(gè)密鑰key1豆挽、key2來(lái)解決之前明文傳輸AES密鑰key的問(wèn)題；步驟如下：
- 通過(guò)RSA算法生成一對(duì)密鑰key1帮哈、key2锰镀；B要和A進(jìn)行通信咖刃，A將key1傳遞給
- B將AES的密鑰key用key1進(jìn)行加密憾筏，發(fā)給A；攻擊雖然可以截獲key1和加密的數(shù)據(jù)枫浙，但是key1加密的數(shù)據(jù)只能通過(guò)key2解密古拴，所以數(shù)據(jù)還是安全的
-
A用手中的key2解密用key1加密的數(shù)據(jù)，得到key黄痪；接下來(lái)A和B便可以通過(guò)這個(gè)對(duì)稱加密密鑰來(lái)進(jìn)行加密通信了
AES搭配RSA實(shí)現(xiàn)加密通信過(guò)程
到這邊满力，有些可能會(huì)有些疑惑，為何要先用非對(duì)稱加密去傳遞AES的key油额，然后再用這個(gè)key進(jìn)行加密傳輸？為何不直接使用RSA進(jìn)行加密傳輸呢涩嚣？
這是因?yàn)镽SA加解密的耗時(shí)較長(zhǎng)掂僵，如果傳輸消息使用非對(duì)稱加密，那么信息傳輸?shù)臅r(shí)間消耗將會(huì)較大幔睬；但是AES的耗時(shí)較小，所以我們通過(guò)RSA來(lái)保證AES密鑰的安全傳遞芹扭，這樣既保證了數(shù)據(jù)傳輸過(guò)程的安全，又避免不會(huì)在數(shù)據(jù)加解密上消耗太多時(shí)間辅肾。有興趣的同學(xué)可以再去深究下RSA算法原理轮锥。
到這邊可以圓滿大結(jié)局了么？還不行新娜。這樣還是擋不住中間人攻擊。現(xiàn)在來(lái)看下這樣一個(gè)場(chǎng)景：
- B向A發(fā)起https請(qǐng)求匆帚，通過(guò)RSA算法生成一對(duì)密鑰key1、key2
- A將key1發(fā)送給B吸重，中間人出現(xiàn)歪今，將key1截?cái)?/li>
- 中間人自己通過(guò)RSA算法生成另一對(duì)密鑰fakeKey1、fakeKey2嫉晶，將fakeKey1發(fā)送給B
- B誤以為fakeKey1這是A發(fā)來(lái)的密鑰key1田篇，用fakeKey1對(duì)key進(jìn)行加密傳遞出去
- 中間人攔截加密數(shù)據(jù)，用fakeKey2解密出fakeKey1加密的key椎镣；至此，中間人已經(jīng)獲取AB之間通信使用的對(duì)稱密鑰key
- 中間人將獲得的key状答，再通過(guò)key1進(jìn)行加密發(fā)送給A刀崖；A誤以為和B完成了密鑰key的交換
-
AB使用對(duì)稱密鑰key進(jìn)行加密通信，中間人也知道這個(gè)key亮钦，所以~~
中間人攻擊
到這蜂莉，仿佛陷入了死局，怎么搞？
https最后一個(gè)關(guān)鍵技術(shù)數(shù)字證書(shū)淮菠，這時(shí)候就要登場(chǎng)了。
我們?cè)谏厦嬗龅降膯?wèn)題：無(wú)法確認(rèn)傳過(guò)來(lái)的公鑰是否為A的傳的公鑰，可能在傳輸途中被換包或者篡改澄阳；數(shù)字證書(shū)就是要用來(lái)解決這個(gè)問(wèn)題的踏拜。
站點(diǎn)首先將自己的通信公鑰以及站點(diǎn)身份等信息合成一份申請(qǐng)，遞交給權(quán)威的證書(shū)頒發(fā)機(jī)構(gòu)CA（certificate authority）肮塞；這份申請(qǐng)姻锁，叫做CSR（Certificate signing request）
)。這個(gè)CSR主要包含就是站點(diǎn)的公鑰以及申請(qǐng)方的各類信息拷窜。
CA拿到這份信息后涧黄，跟根據(jù)約定的規(guī)范格式通過(guò)hash算法，生成內(nèi)容的散列值懊昨；然后通過(guò)CA的私鑰對(duì)這段散列值進(jìn)行加密挽鞠，生成數(shù)字簽名DA（Digital Signature）；最后將站點(diǎn)的CSR和這段CSR的數(shù)字簽名合在一起信认，成為頒發(fā)給站點(diǎn)的數(shù)字證書(shū)DC(Digital Certificate)。
現(xiàn)在站點(diǎn)擁有了CA認(rèn)證的公鑰證書(shū)其掂，有瀏覽器想跟站點(diǎn)進(jìn)行https通信時(shí)潦蝇，站點(diǎn)會(huì)將自己的公鑰證書(shū)發(fā)給瀏覽器；瀏覽器會(huì)使用已植入在內(nèi)的CA公鑰解密證書(shū)的簽名贤牛，得到站點(diǎn)CSR的hash值则酝，然后瀏覽器用CRS部分算一個(gè)hash值， 將解密后的hash值進(jìn)行比較；相等則認(rèn)證通過(guò)武鲁，證書(shū)中的公鑰為站點(diǎn)的公鑰蝠检；不相等，則認(rèn)證失敗饲梭，提示用戶站點(diǎn)存在風(fēng)險(xiǎn)。
至此排拷，我們已經(jīng)安全的獲得了站點(diǎn)的公鑰监氢，之后就可以按照文章上半部分所寫(xiě)的那樣，進(jìn)行https協(xié)議通信了
