大家都知道，在客戶(hù)端與服務(wù)器數(shù)據(jù)傳輸?shù)倪^(guò)程中，HTTP協(xié)議的傳輸是不安全的，也就是一般情況下HTTP是明文傳輸?shù)摹５獺TTPS協(xié)議的數(shù)據(jù)傳輸是安全的，也就是說(shuō)HTTPS數(shù)據(jù)的傳輸是經(jīng)過(guò)加密的。

在客戶(hù)端與服務(wù)器這兩個(gè)完全沒(méi)有見(jiàn)過(guò)面的陌生人交流中，HTTPS是如何保證數(shù)據(jù)傳輸?shù)陌踩缘哪兀肯旅嫖覍Т蠹乙徊讲搅私釮TTPS是如何加密才得以保證數(shù)據(jù)傳輸?shù)陌踩缘摹?

我們先把客戶(hù)端稱(chēng)為小客，服務(wù)器稱(chēng)為小服。然后一步步探索在小客與小服的交流中（就是一方請(qǐng)求一方響應(yīng)），HTTPS是如何保證他們的交流不會(huì)被中間人竊聽(tīng)的。

對(duì)稱(chēng)加密

假如現(xiàn)在小客與小服要進(jìn)行一次私密的對(duì)話(huà)，他們不希望這次對(duì)話(huà)內(nèi)容被其他外人知道。可是，我們平時(shí)的數(shù)據(jù)傳輸過(guò)程中又是明文傳輸?shù)模f(wàn)一被某個(gè)黑客把他們的對(duì)話(huà)內(nèi)容給竊取了，那就難受了。

為了解決這個(gè)問(wèn)題，小服這家伙想到了一個(gè)方法來(lái)加密數(shù)據(jù)，讓黑客看不到具體的內(nèi)容。該方法是這樣子的：

在每次數(shù)據(jù)傳輸之前，小服會(huì)先傳輸給小客一把密鑰，然后小服在之后給小客發(fā)消息的過(guò)程中，會(huì)用這把密鑰對(duì)這些消息進(jìn)行加密。小客在收到這些消息后，會(huì)用之前小服給的那把密鑰對(duì)這些消息進(jìn)行解密，這樣，小客就能得到密文里面真正的數(shù)據(jù)了。如果小客要給小服發(fā)消息，也同樣用這把密鑰來(lái)對(duì)消息進(jìn)行加密，小服收到后也用這把密鑰進(jìn)行解密。 

這樣，就保證了數(shù)據(jù)傳輸?shù)陌踩浴Ｈ鐖D所示：

這種方法稱(chēng)之為對(duì)稱(chēng)加密，加密和解密都用同一把密鑰。

這時(shí)，小服想著自己的策咯，還是挺得意的。但這個(gè)策略安全的前提是，小客擁有小服的那把密鑰。可問(wèn)題是，小服是以明文的方式把這把密鑰傳輸給小客的，如果黑客截取了這把密鑰，小服與小客就算是加密了內(nèi)容，在截取了密鑰的黑客老哥眼里，這和明文沒(méi)啥區(qū)別。

非對(duì)稱(chēng)加密

小服還是挺聰明的，意識(shí)到了密鑰會(huì)被截取這個(gè)問(wèn)題，他又想到了另外一種方法：用非對(duì)稱(chēng)加密的方法來(lái)加密數(shù)據(jù)。方法如下：

小服和小客都擁有兩把鑰匙，一把鑰匙是公開(kāi)的（全世界都知道也沒(méi)關(guān)系），稱(chēng)之為公鑰；而另一把鑰匙是保密（也就是只有自己才知道），稱(chēng)之為私鑰。并且，用公鑰加密的數(shù)據(jù)，只有對(duì)應(yīng)的私鑰才能解密；用私鑰加密的數(shù)據(jù)，只有對(duì)應(yīng)的公鑰才能解密。

所以在傳輸數(shù)據(jù)的過(guò)程中，小服在給小客傳輸數(shù)據(jù)的過(guò)程中，會(huì)用小客給他的公鑰進(jìn)行加密，然后小客收到后，再用自己的私鑰進(jìn)行解密。小客給小服發(fā)消息的時(shí)候，也一樣會(huì)用小服給他的公鑰進(jìn)行加密，然后小服再用自己的私鑰進(jìn)行解密。

這樣，數(shù)據(jù)就能安全到達(dá)雙方。如圖：

想著這么復(fù)雜的策略都能想出來(lái)，小服可是得意的不能再得意了…..還沒(méi)等小服得意多久，小客就給它潑了一波冷水。

小客嚴(yán)肅著說(shuō)：其實(shí)，你的這種方法也不是那么安全啊，還是存在被黑客截取的危險(xiǎn)啊。例如：

你在給我傳輸公鑰的過(guò)程中，如果黑客截取了你的公鑰，并且拿著自己的公鑰來(lái)冒充你的公鑰來(lái)發(fā)給我。我收到公鑰之后，會(huì)用公鑰進(jìn)行加密傳輸（這時(shí)用的公鑰實(shí)際上是黑客的公鑰）。黑客截取了加密的消息之后，可以用他自己的私鑰來(lái)進(jìn)行解密來(lái)獲取消息內(nèi)容。然后再用你（小服）的公鑰來(lái)對(duì)消息進(jìn)行加密，之后再發(fā)給你（小服）。 這樣子，我們的對(duì)話(huà)內(nèi)容還是被黑客給截取了（倒過(guò)來(lái)小客給小服傳輸公鑰的時(shí)候也一樣）。

......這么精妙的想法居然也不行，小服這波，滿(mǎn)臉無(wú)神。

這里插講下，其實(shí)在傳輸數(shù)據(jù)的過(guò)程中，在速度上用對(duì)稱(chēng)加密的方法會(huì)比非對(duì)稱(chēng)加密的方法快很多。所以在傳輸數(shù)據(jù)的時(shí)候，一般不單單只用非對(duì)稱(chēng)加密這種方法（我們先假設(shè)非對(duì)稱(chēng)密碼這種方法很安全），而是會(huì)用非對(duì)稱(chēng)加密 + 對(duì)稱(chēng)加密這兩種結(jié)合的方法。基于這個(gè)，我們可以用非對(duì)稱(chēng)加密方法來(lái)安全著傳輸密鑰，之后再用對(duì)稱(chēng)加密的方法來(lái)傳輸消息內(nèi)容（當(dāng)然，我這里假定了非對(duì)稱(chēng)加密傳輸是安全的，下面會(huì)講如何使之安全）。

數(shù)字證書(shū)

我們回頭想一下，是什么原因?qū)е路菍?duì)稱(chēng)加密這種方法的不安全性呢？它和對(duì)稱(chēng)加密方法的不安全性不同。非對(duì)稱(chēng)加密之所以不安全，是因?yàn)樾】褪盏搅斯€之后，無(wú)法確定這把公鑰是否真的屬于小服。

也就是說(shuō)，我們需要找到一種策略來(lái)證明這把公鑰就是小服的，而不是別人冒充的。

為了解決這個(gè)問(wèn)題，小服和小客絞盡腦汁想出了一種終極策略：數(shù)字證書(shū)——我們需要找到一個(gè)擁有公信力、大家都認(rèn)可的認(rèn)證中心（CA）。小服在給小客發(fā)公鑰的過(guò)程中，會(huì)把公鑰以及小服的個(gè)人信息通過(guò)Hash算法生成消息摘要。如圖：

為了防止摘要被人調(diào)換，小服還會(huì)用CA提供的私鑰對(duì)消息摘要進(jìn)行加密來(lái)形成數(shù)字簽名。如圖：

并且，最后還會(huì)把原來(lái)沒(méi)Hash算法之前的信息和數(shù)字簽名合并在一起，形成數(shù)字證書(shū)。如圖：

當(dāng)小客拿到這份數(shù)字證書(shū)之后，就會(huì)用CA提供的公鑰來(lái)對(duì)數(shù)字證書(shū)里面的數(shù)字簽名進(jìn)行解密得到消息摘要，然后對(duì)數(shù)字證書(shū)里面小服的公鑰和個(gè)人信息進(jìn)行Hash得到另一份消息摘要，然后把兩份消息摘要進(jìn)行對(duì)比，如果一樣，則證明這些東西確實(shí)是小服的，否則就不是。如圖：

這時(shí)可能有人會(huì)有疑問(wèn)，CA的公鑰是怎么拿給小客的呢？小服又怎么有CA的私鑰呢？

其實(shí)，（有些）服務(wù)器在一開(kāi)始就向認(rèn)證中心申請(qǐng)了這些證書(shū)，而客戶(hù)端里，也會(huì)內(nèi)置這些證書(shū)。如圖（此圖來(lái)元阮一峰的網(wǎng)絡(luò)日志）：

當(dāng)客戶(hù)端收到服務(wù)器返回來(lái)的數(shù)據(jù)時(shí)，就會(huì)在內(nèi)置的證書(shū)列表里，查看是否有有解開(kāi)該數(shù)字證書(shū)的公鑰。

河南億恩科技股份有限公司(m.czbl888.cn)始創(chuàng)于2000年，專(zhuān)注服務(wù)器托管租用，是國(guó)家工信部認(rèn)定的綜合電信服務(wù)運(yùn)營(yíng)商。億恩為近五十萬(wàn)的用戶(hù)提供服務(wù)器托管、服務(wù)器租用、機(jī)柜租用、云服務(wù)器、網(wǎng)站建設(shè)、網(wǎng)站托管等網(wǎng)絡(luò)基礎(chǔ)服務(wù)，另有網(wǎng)總管、名片俠網(wǎng)絡(luò)推廣服務(wù)，使得客戶(hù)不斷的獲得更大的收益。
服務(wù)器/云主機(jī) 24小時(shí)售后服務(wù)電話(huà)：0371-60135900
虛擬主機(jī)/智能建站 24小時(shí)售后服務(wù)電話(huà)：0371-55621053
網(wǎng)絡(luò)版權(quán)侵權(quán)舉報(bào)電話(huà)：0371-60135995
服務(wù)熱線(xiàn)：0371-60135900