為什么 HTTPS 比HTTP 更安全？HTTPS如何保證數(shù)據(jù)傳輸?shù)陌踩?/h1>

作者：程序員蛋蛋 2022-02-16 11:56:28

HTTP 本身不具備加密的功能，因此其在通信過程是使用明文方式發(fā)送的。這種方式就有可能造成通信過程中信息會(huì)被破解獲取。

大家好，我是蛋蛋。

HTTP 和 HTTPS 在許多網(wǎng)站都有用到，但是現(xiàn)在都是極力倡導(dǎo)使用 HTTPS ，究其原因就是 HTTP 它不是安全的，在數(shù)據(jù)傳輸過程中會(huì)遭到黑客竊取，本篇文章會(huì)先講解 HTTP 缺點(diǎn)，然后再講解 HTTPS 是如何解決這些問題來保證安全的。

HTTP 缺點(diǎn)

通信使用明文(不加密),內(nèi)容可能會(huì)被竊聽

HTTP 本身不具備加密的功能，因此其在通信過程是使用明文方式發(fā)送的。這種方式就有可能造成通信過程中信息會(huì)被破解獲取。例如一群佩奇在路上坐著敞篷大貨車，路過的人一下就能看到這車?yán)锒际牵畔⑼耆┞丁?/h4>

不驗(yàn)證通信方的身份，有可能遭遇偽裝

HTTP 協(xié)議在請(qǐng)求和響應(yīng)中不會(huì)對(duì)通信方進(jìn)行確認(rèn)。這就存在可能你訪問的服務(wù)器有可能不是你真正指定的服務(wù)器，拿到返回響應(yīng)的客戶端可能不是一開始發(fā)起請(qǐng)求的客戶端。

這里舉個(gè)小例子，例如母雞孵蛋，我偷偷把雞蛋換成鴨蛋，母雞照樣在那孵，不會(huì)有任何的懷疑。

無法證明報(bào)文完整性，有可能信息已遭篡改

HTTP 協(xié)議無法證明通信的報(bào)文完整性，在請(qǐng)求和響應(yīng)發(fā)出后，在傳輸過程中內(nèi)容如果遭到篡改，也沒有辦法感知到。

例如你從某個(gè)網(wǎng)站下載內(nèi)容，無法確定你客戶端下載的文件是否和服務(wù)器中存放的文件是否一致，有可能文件在傳輸過程中被篡改為其他的內(nèi)容。

什么是 HTTPS

HTTP + 加密 + 認(rèn)證 + 完整性保護(hù) = HTTPS

為了統(tǒng)一解決 HTTP 上述幾個(gè)缺點(diǎn)，我們就把加了加密及認(rèn)證機(jī)制的 HTTP 稱為 HTTPS 。

HTTPS 并不是一種新的協(xié)議。只是 HTTP 通信接口部分采用了 SSL 和 TLS 協(xié)議代替。

通常來說，HTTP 是直接和 TCP 進(jìn)行通信的。當(dāng)我們使用 SSL 時(shí)，會(huì)變成先和 SSL 通信，然后再由 SSL 和 TCP 進(jìn)行通信。

SSL/TLS

SSL 即安全套接層(Secure Sockets Layer)，在 OSI 模型中處于第 5 層。在 1999 年 SSL 更名為 TLS (傳輸層安全)，正式標(biāo)準(zhǔn)化。

OpenSSL

提到 TLS ,就要說下 OpenSSL ,它是一個(gè)開源密碼學(xué)程序庫和工具包，支持了所有公開的加密算法和協(xié)議，許多應(yīng)用軟件都適用它作為底層庫來實(shí)現(xiàn) TLS 功能，例如 Apache、Nginx等。

對(duì)稱加密與非對(duì)稱加密

HTTPS 的安全性是由 TLS 來保證的，它為 HTTP 增加了機(jī)密性、完整性和身份認(rèn)證等特性，具體是怎么實(shí)現(xiàn)的呢?

我們先來說說機(jī)密性。實(shí)現(xiàn)機(jī)密性的做法就是 “加密”，將需要傳遞的消息進(jìn)行加密，只有擁有“鑰匙”的人才能拿到原始數(shù)據(jù)。

這個(gè) 鑰匙我們叫做 “密鑰”，加密的消息叫 “明文”，加密后的叫做 “密文”。通過密鑰來還原數(shù)據(jù)的過程叫 “解密”，加密解密的整個(gè)操作過程就是 “加密算法”。

加密可以分為兩種形式，對(duì)稱加密和非對(duì)稱性加密。

對(duì)稱加密

怎么理解對(duì)稱加密呢?其實(shí)很簡(jiǎn)單，就是指加密和解密使用的密鑰都是同一個(gè)。只要保證了密鑰的安全，那整個(gè)通信過程就具有了機(jī)密性。

例如你要登陸某個(gè)網(wǎng)站，你事先和網(wǎng)站約定好使用一個(gè)對(duì)稱密碼，那么在數(shù)據(jù)傳輸過程中全是用密鑰加密后的密文，只有網(wǎng)站能解密，傳輸?shù)倪^程中即使信息被竊取，也無法獲得原始數(shù)據(jù)。

非對(duì)稱加密

對(duì)稱加密看起來好像完美實(shí)現(xiàn)了機(jī)密性，但這其中也有一定的安全隱患，就是如何把密鑰安全地傳遞給對(duì)方，因?yàn)閷?duì)稱加密只要有密鑰就能解密，如果雙方約定的密鑰在傳遞過程被竊取，就會(huì)造成數(shù)據(jù)會(huì)被很容易的解密。

例如你家的鑰匙，你跟你爸媽約定好鑰匙放在門外鞋底里，看似安全，但如果別人發(fā)現(xiàn)了這個(gè)鞋底里藏的鑰匙，那你家大門就會(huì)被打開，就很危險(xiǎn)。

那有沒有更安全的加密方式呢，就要說到非對(duì)稱加密(也叫公鑰加密算法)。

它有兩個(gè)密鑰，一個(gè)叫 “公鑰”，一個(gè)叫“私鑰”。兩個(gè)鑰匙是不同的，公鑰可以給任何人使用，但私鑰必須嚴(yán)格保密。

公鑰加密的數(shù)據(jù)只能由私鑰解密，反過來，私鑰加密后也只能用公鑰解密。

網(wǎng)站秘密保管私鑰，在網(wǎng)上隨意分發(fā)公鑰，如果你想登錄網(wǎng)站，只要用公鑰來加密即可，密文只能由私鑰持有者才能解密，即使數(shù)據(jù)傳輸過程中被黑客獲取到，他也無法破解。

混合加密

非對(duì)稱性加密雖然安全性高，但因?yàn)樗际腔趶?fù)雜的數(shù)學(xué)運(yùn)算，速度就會(huì)很慢，雖然保證了安全，但通信速度太慢，實(shí)用性也會(huì)大打折扣。

混合加密就是在通信剛開始的時(shí)候使用非對(duì)稱算法，來解決對(duì)稱加密密鑰交換安全性問題。

對(duì)方拿到密文后用私鑰解密，拿到對(duì)稱密鑰，這樣雙方就實(shí)現(xiàn)了對(duì)稱密鑰的安全交換，后續(xù)就不再使用非對(duì)稱加密，全都使用對(duì)稱加密。

這樣混合加密就實(shí)現(xiàn)了安全和性能兼顧，實(shí)現(xiàn)了可靠的機(jī)密性。

數(shù)字簽名和證書

剛剛我們實(shí)現(xiàn)了機(jī)密性，但這離安全還差的遠(yuǎn)。

黑客雖然拿不到會(huì)話密鑰，但是可以竊聽足夠多的密文，然后嘗試修改發(fā)給網(wǎng)站，服務(wù)器因?yàn)闊o法識(shí)別只能接收，它就可以通過服務(wù)器的響應(yīng)獲取到有用的信息。

另外，黑客也可以偽造身份發(fā)布公鑰，如果你拿到的是假的公鑰，那么加密就完全失效了。所以在機(jī)密性的基礎(chǔ)上還需要加上完整性、身份認(rèn)證等特性，才能實(shí)現(xiàn)安全。

摘要算法

實(shí)現(xiàn)完整性的手段主要是摘要算法，也就是散列函數(shù)、哈希函數(shù)。

通過摘要算法可以把數(shù)據(jù)壓縮成一個(gè)獨(dú)一無二的字符串，就例如你的身份證號(hào)一樣，是唯一的。

它只有算法，沒有密鑰，加密后也不能被解密，無法逆推出原數(shù)據(jù)。

完整性

摘要算法如何保證完整性呢?這里舉例說明：我發(fā)了條消息：“轉(zhuǎn)賬 0.01元 ”，然后這句明文我同時(shí)要通過摘要算法生成一個(gè)摘要密文，這個(gè)摘要密文放在明文后面一起發(fā)送給網(wǎng)站，網(wǎng)站接收到后也對(duì)收到的明文信息通過摘要算法進(jìn)行加密，與傳過來的摘要密文進(jìn)行對(duì)比，如果一樣就說明信息沒有被篡改，保持了完整性。

不過摘要算法不具備機(jī)密性，如果明文傳輸，黑客可以把明文消息進(jìn)行修改同時(shí)把摘要也一起改了，網(wǎng)站還是鑒別不出完整性。

所以真正的完整性必須建立在機(jī)密性的基礎(chǔ)上。

數(shù)字簽名

黑客其實(shí)是可以偽裝成你，向網(wǎng)站發(fā)起支付、轉(zhuǎn)賬等請(qǐng)求消息，因?yàn)榫W(wǎng)站沒有辦法確認(rèn)你的身份就會(huì)造成錢被偷走。

在現(xiàn)實(shí)生活中，我們解決身份認(rèn)證是通過身份證，簽名或者印章等等，來確定這個(gè)是本人操作的。

那 HTTPS 是如何解決身份認(rèn)證問題的?還記得之前提到的非對(duì)稱加密里的私鑰嗎，使用私鑰再加上摘要算法，就可以實(shí)現(xiàn)“數(shù)字簽名”，同時(shí)實(shí)現(xiàn)“身份認(rèn)證”。

數(shù)字簽名的原理就是把公鑰和私鑰用法反過來，之前是公鑰加密，私鑰解密，現(xiàn)在變成私鑰加密、公鑰解密。

簽名和公鑰一樣完全公開，任何人都可以獲取。但這個(gè)簽名只有用私鑰對(duì)應(yīng)的公鑰才能解開，拿到摘要后，再比對(duì)原文驗(yàn)證完整性，就可以像簽署文件一樣證明消息確實(shí)是你發(fā)的。

通過加密算法，摘要算法，數(shù)字簽名我們已經(jīng)可以實(shí)現(xiàn)數(shù)據(jù)通信過程中的加密、認(rèn)證及完整性保護(hù)，但是這其中還有一個(gè)問題，就是公鑰的信任問題。

數(shù)字證書

公鑰每個(gè)人都可以進(jìn)行發(fā)布，我們還缺少一個(gè)防止黑客偽裝公鑰的手段，也就是如何證明這個(gè)公鑰就是你的公鑰呢?

為了解決這個(gè)問題，我們需要找一個(gè)公認(rèn)的可信第三方，來幫助構(gòu)建起公鑰的信任鏈。

這個(gè)第三方就是 CA(數(shù)字證書認(rèn)證機(jī)構(gòu)),它扮演著類似網(wǎng)絡(luò)世界中的公安局，公證中心這種角色，由它來給各個(gè)公鑰簽名，用自身的信譽(yù)來保證公鑰無法偽造，是可信的。

服務(wù)器會(huì)將由數(shù)字證書認(rèn)證機(jī)構(gòu)頒發(fā)的公鑰證書發(fā)送給客戶端，接到證書的客戶端可使用公開密鑰，對(duì)那張證書上的數(shù)字簽名進(jìn)行驗(yàn)證，一旦驗(yàn)證通過，就證明服務(wù)器的公開密鑰是真實(shí)有效的。