為什么 HTTPS 比HTTP 更安全?HTTPS如何保證數(shù)據(jù)傳輸?shù)陌踩?/h1>
大家好,我是蛋蛋。
HTTP 和 HTTPS 在許多網(wǎng)站都有用到,但是現(xiàn)在都是極力倡導(dǎo)使用 HTTPS ,究其原因就是 HTTP 它不是安全的,在數(shù)據(jù)傳輸過(guò)程中會(huì)遭到黑客竊取,本篇文章會(huì)先講解 HTTP 缺點(diǎn),然后再講解 HTTPS 是如何解決這些問(wèn)題來(lái)保證安全的。
HTTP 缺點(diǎn)
通信使用明文(不加密),內(nèi)容可能會(huì)被竊聽
HTTP 
本身不具備加密的功能,因此其在通信過(guò)程是使用明文方式發(fā)送的。這種方式就有可能造成通信過(guò)程中信息會(huì)被破解獲取。例如一群佩奇在路上坐著敞篷大貨車,路過(guò)的人一下就能看到這車?yán)锒际?,信息完全暴露?/h4>不驗(yàn)證通信方的身份,有可能遭遇偽裝
HTTP 協(xié)議在請(qǐng)求和響應(yīng)中不會(huì)對(duì)通信方進(jìn)行確認(rèn)。這就存在可能你訪問(wèn)的服務(wù)器有可能不是你真正指定的服務(wù)器,拿到返回響應(yīng)的客戶端可能不是一開始發(fā)起請(qǐng)求的客戶端。
這里舉個(gè)小例子,例如母雞孵蛋,我偷偷把雞蛋換成鴨蛋,母雞照樣在那孵,不會(huì)有任何的懷疑。

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

例如你從某個(gè)網(wǎng)站下載內(nèi)容,無(wú)法確定你客戶端下載的文件是否和服務(wù)器中存放的文件是否一致,有可能文件在傳輸過(guò)程中被篡改為其他的內(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é)議代替。
通常來(lái)說(shuō),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 ,就要說(shuō)下 OpenSSL ,它是一個(gè)開源密碼學(xué)程序庫(kù)和工具包,支持了所有公開的加密算法和協(xié)議,許多應(yīng)用軟件都適用它作為底層庫(kù)來(lái)實(shí)現(xiàn) TLS 功能,例如 Apache、Nginx等。
對(duì)稱加密與非對(duì)稱加密
HTTPS 的安全性是由 TLS 來(lái)保證的,它為 HTTP 增加了機(jī)密性、完整性和身份認(rèn)證等特性,具體是怎么實(shí)現(xiàn)的呢?
我們先來(lái)說(shuō)說(shuō)機(jī)密性。實(shí)現(xiàn)機(jī)密性的做法就是 “加密”,將需要傳遞的消息進(jìn)行加密,只有擁有“鑰匙”的人才能拿到原始數(shù)據(jù)。
這個(gè) 鑰匙 我們叫做 “密鑰”,加密的消息叫 “明文”,加密后的叫做 “密文”。通過(guò)密鑰來(lái)還原數(shù)據(jù)的過(guò)程叫 “解密”,加密解密的整個(gè)操作過(guò)程就是 “加密算法”。
加密可以分為兩種形式,對(duì)稱加密和非對(duì)稱性加密。
對(duì)稱加密
怎么理解對(duì)稱加密呢?其實(shí)很簡(jiǎn)單,就是指加密和解密使用的密鑰都是同一個(gè)。只要保證了密鑰的安全,那整個(gè)通信過(guò)程就具有了機(jī)密性。
例如你要登陸某個(gè)網(wǎng)站,你事先和網(wǎng)站約定好使用一個(gè)對(duì)稱密碼,那么在數(shù)據(jù)傳輸過(guò)程中全是用密鑰加密后的密文,只有網(wǎng)站能解密,傳輸?shù)倪^(guò)程中即使信息被竊取,也無(wú)法獲得原始數(shù)據(jù)。

非對(duì)稱加密
對(duì)稱加密看起來(lái)好像完美實(shí)現(xiàn)了機(jī)密性,但這其中也有一定的安全隱患,就是如何把密鑰安全地傳遞給對(duì)方,因?yàn)閷?duì)稱加密只要有密鑰就能解密,如果雙方約定的密鑰在傳遞過(guò)程被竊取,就會(huì)造成數(shù)據(jù)會(huì)被很容易的解密。
例如你家的鑰匙,你跟你爸媽約定好鑰匙放在門外鞋底里,看似安全,但如果別人發(fā)現(xiàn)了這個(gè)鞋底里藏的鑰匙,那你家大門就會(huì)被打開,就很危險(xiǎn)。
那有沒有更安全的加密方式呢,就要說(shuō)到非對(duì)稱加密(也叫公鑰加密算法)。
它有兩個(gè)密鑰,一個(gè)叫 “公鑰”,一個(gè)叫“私鑰”。兩個(gè)鑰匙是不同的,公鑰可以給任何人使用,但私鑰必須嚴(yán)格保密。
公鑰加密的數(shù)據(jù)只能由私鑰解密,反過(guò)來(lái),私鑰加密后也只能用公鑰解密。
網(wǎng)站秘密保管私鑰,在網(wǎng)上隨意分發(fā)公鑰,如果你想登錄網(wǎng)站,只要用公鑰來(lái)加密即可,密文只能由私鑰持有者才能解密,即使數(shù)據(jù)傳輸過(guò)程中被黑客獲取到,他也無(wú)法破解。

混合加密
非對(duì)稱性加密雖然安全性高,但因?yàn)樗际腔趶?fù)雜的數(shù)學(xué)運(yùn)算,速度就會(huì)很慢,雖然保證了安全,但通信速度太慢,實(shí)用性也會(huì)大打折扣。
混合加密就是在通信剛開始的時(shí)候使用非對(duì)稱算法,來(lái)解決對(duì)稱加密密鑰交換安全性問(wèn)題。
對(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(wú)法識(shí)別只能接收,它就可以通過(guò)服務(wù)器的響應(yīng)獲取到有用的信息。
另外,黑客也可以偽造身份發(fā)布公鑰,如果你拿到的是假的公鑰,那么加密就完全失效了。所以在機(jī)密性的基礎(chǔ)上還需要加上完整性、身份認(rèn)證等特性,才能實(shí)現(xiàn)安全。
摘要算法
實(shí)現(xiàn)完整性的手段主要是摘要算法,也就是散列函數(shù)、哈希函數(shù)。
通過(guò)摘要算法可以把數(shù)據(jù)壓縮成一個(gè)獨(dú)一無(wú)二的字符串,就例如你的身份證號(hào)一樣,是唯一的。
它只有算法,沒有密鑰,加密后也不能被解密,無(wú)法逆推出原數(shù)據(jù)。
完整性
摘要算法如何保證完整性呢?這里舉例說(shuō)明: 我發(fā)了條消息:“轉(zhuǎn)賬 0.01元 ”,然后這句明文我同時(shí)要通過(guò)摘要算法生成一個(gè)摘要密文,這個(gè)摘要密文放在明文后面一起發(fā)送給網(wǎng)站,網(wǎng)站接收到后也對(duì)收到的明文信息通過(guò)摘要算法進(jìn)行加密,與傳過(guò)來(lái)的摘要密文進(jìn)行對(duì)比,如果一樣就說(shuō)明信息沒有被篡改,保持了完整性。
不過(guò)摘要算法不具備機(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)證是通過(guò)身份證,簽名或者印章等等,來(lái)確定這個(gè)是本人操作的。
那 HTTPS 是如何解決身份認(rèn)證問(wèn)題的?還記得之前提到的非對(duì)稱加密里的私鑰嗎,使用私鑰再加上摘要算法,就可以實(shí)現(xiàn)“數(shù)字簽名”,同時(shí)實(shí)現(xiàn)“身份認(rèn)證”。
數(shù)字簽名的原理就是把公鑰和私鑰用法反過(guò)來(lái),之前是公鑰加密,私鑰解密,現(xiàn)在變成私鑰加密、公鑰解密。
簽名和公鑰一樣完全公開,任何人都可以獲取。但這個(gè)簽名只有用私鑰對(duì)應(yīng)的公鑰才能解開,拿到摘要后,再比對(duì)原文驗(yàn)證完整性,就可以像簽署文件一樣證明消息確實(shí)是你發(fā)的。

通過(guò)加密算法,摘要算法,數(shù)字簽名我們已經(jīng)可以實(shí)現(xiàn)數(shù)據(jù)通信過(guò)程中的加密、認(rèn)證及完整性保護(hù),但是這其中還有一個(gè)問(wèn)題,就是公鑰的信任問(wèn)題。
數(shù)字證書
公鑰每個(gè)人都可以進(jìn)行發(fā)布,我們還缺少一個(gè)防止黑客偽裝公鑰的手段,也就是如何證明這個(gè)公鑰就是你的公鑰呢?
為了解決這個(gè)問(wèn)題,我們需要找一個(gè)公認(rèn)的可信第三方,來(lái)幫助構(gòu)建起公鑰的信任鏈。
這個(gè)第三方就是 CA(數(shù)字證書認(rèn)證機(jī)構(gòu)),它扮演著類似網(wǎng)絡(luò)世界中的公安局,公證中心這種角色,由它來(lái)給各個(gè)公鑰簽名,用自身的信譽(yù)來(lái)保證公鑰無(wú)法偽造,是可信的。
服務(wù)器會(huì)將由數(shù)字證書認(rèn)證機(jī)構(gòu)頒發(fā)的公鑰證書發(fā)送給客戶端,接到證書的客戶端可使用公開密鑰,對(duì)那張證書上的數(shù)字簽名進(jìn)行驗(yàn)證,一旦驗(yàn)證通過(guò),就證明服務(wù)器的公開密鑰是真實(shí)有效的。

為什么不全部使用 HTTPS
通過(guò)前面的介紹,HTTPS 的安全性比 HTTP 強(qiáng)太多,但是 依然會(huì)有很多 Web 網(wǎng)站沒有一直使用 HTTPS。
究其原因就是加密通信會(huì)消耗更多的 CPU 及內(nèi)存資源,如果每次通信都進(jìn)行加密,會(huì)消耗相當(dāng)多的資源。因此如果是非敏感信息則使用 HTTP 通信,包含個(gè)人信息等敏感數(shù)據(jù),才利用 HTTPS 加密通信。
使用 HTTPS 還有一個(gè)問(wèn)題就是需要證書,而證書必須向認(rèn)證機(jī)構(gòu)(CA)去購(gòu)買,這也是一筆不小的費(fèi)用。















 
 
 








 
 
 
 