HTTPS科普掃盲,看過(guò)的人都恍然大悟!
為什么需要HTTPS
HTTP是明文傳輸?shù)模簿鸵馕吨?,介于發(fā)送端、接收端中間的任意節(jié)點(diǎn)都可以知道你們傳輸?shù)膬?nèi)容是什么。這些節(jié)點(diǎn)可能是路由器、代理等。
舉個(gè)最常見(jiàn)的例子,用戶(hù)登陸。用戶(hù)輸入賬號(hào),密碼,采用HTTP的話,只要在代理服務(wù)器上做點(diǎn)手腳就可以拿到你的密碼了。
用戶(hù)登陸 --> 代理服務(wù)器(做手腳)--> 實(shí)際授權(quán)服務(wù)器
在發(fā)送端對(duì)密碼進(jìn)行加密?沒(méi)用的,雖然別人不知道你原始密碼是多少,但能夠拿到加密后的賬號(hào)密碼,照樣能登陸。
HTTPS是如何保障安全的
HTTPS其實(shí)就是secure http的意思啦,也就是HTTP的安全升級(jí)版。稍微了解網(wǎng)絡(luò)基礎(chǔ)的同學(xué)都知道,HTTP是應(yīng)用層協(xié)議,位于HTTP協(xié)議之下是傳輸協(xié)議TCP。TCP負(fù)責(zé)傳輸,HTTP則定義了數(shù)據(jù)如何進(jìn)行包裝。
HTTP --> TCP (明文傳輸)
HTTPS相對(duì)于HTTP有哪些不同呢?其實(shí)就是在HTTP跟TCP中間加多了一層加密層TLS/SSL。
神馬是TLS/SSL?
通俗的講,TLS、SSL其實(shí)是類(lèi)似的東西,SSL是個(gè)加密套件,負(fù)責(zé)對(duì)HTTP的數(shù)據(jù)進(jìn)行加密。TLS是SSL的升級(jí)版?,F(xiàn)在提到HTTPS,加密套件基本指的是TLS。
傳輸加密的流程
原先是應(yīng)用層將數(shù)據(jù)直接給到TCP進(jìn)行傳輸,現(xiàn)在改成應(yīng)用層將數(shù)據(jù)給到TLS/SSL,將數(shù)據(jù)加密后,再給到TCP進(jìn)行傳輸。
大致如圖所示。
就是這么回事。將數(shù)據(jù)加密后再傳輸,而不是任由數(shù)據(jù)在復(fù)雜而又充滿危險(xiǎn)的網(wǎng)絡(luò)上明文裸奔,在很大程度上確保了數(shù)據(jù)的安全。這樣的話,即使數(shù)據(jù)被中間節(jié)點(diǎn)截獲,壞人也看不懂。
HTTPS是如何加密數(shù)據(jù)的
對(duì)安全或密碼學(xué)基礎(chǔ)有了解的同學(xué),應(yīng)該知道常見(jiàn)的加密手段。一般來(lái)說(shuō),加密分為對(duì)稱(chēng)加密、非對(duì)稱(chēng)加密(也叫公開(kāi)密鑰加密)。
對(duì)稱(chēng)加密
對(duì)稱(chēng)加密的意思就是,加密數(shù)據(jù)用的密鑰,跟解密數(shù)據(jù)用的密鑰是一樣的。
對(duì)稱(chēng)加密的優(yōu)點(diǎn)在于加密、解密效率通常比較高。缺點(diǎn)在于,數(shù)據(jù)發(fā)送方、數(shù)據(jù)接收方需要協(xié)商、共享同一把密鑰,并確保密鑰不泄露給其他人。此外,對(duì)于多個(gè)有數(shù)據(jù)交換需求的個(gè)體,兩兩之間需要分配并維護(hù)一把密鑰,這個(gè)帶來(lái)的成本基本是不可接受的。
非對(duì)稱(chēng)加密
非對(duì)稱(chēng)加密的意思就是,加密數(shù)據(jù)用的密鑰(公鑰),跟解密數(shù)據(jù)用的密鑰(私鑰)是不一樣的。
什么叫做公鑰呢?其實(shí)就是字面上的意思——公開(kāi)的密鑰,誰(shuí)都可以查到。因此非對(duì)稱(chēng)加密也叫做公開(kāi)密鑰加密。
相對(duì)應(yīng)的,私鑰就是非公開(kāi)的密鑰,一般是由網(wǎng)站的管理員持有。
公鑰、私鑰兩個(gè)有什么聯(lián)系呢?
簡(jiǎn)單的說(shuō)就是,通過(guò)公鑰加密的數(shù)據(jù),只能通過(guò)私鑰解開(kāi)。通過(guò)私鑰加密的數(shù)據(jù),只能通過(guò)公鑰解開(kāi)。
很多同學(xué)都知道用私鑰能解開(kāi)公鑰加密的數(shù)據(jù),但忽略了一點(diǎn),私鑰加密的數(shù)據(jù),同樣可以用公鑰解密出來(lái)。而這點(diǎn)對(duì)于理解HTTPS的整套加密、授權(quán)體系非常關(guān)鍵。
舉個(gè)非對(duì)稱(chēng)加密的例子
- 登陸用戶(hù):小明
- 授權(quán)網(wǎng)站:某知名社交網(wǎng)站(以下簡(jiǎn)稱(chēng)XX)
小明都是某知名社交網(wǎng)站XX的用戶(hù),XX出于安全考慮在登陸的地方用了非對(duì)稱(chēng)加密。小明在登陸界面敲入賬號(hào)、密碼,點(diǎn)擊“登陸”。于是,瀏覽器利用公鑰對(duì)小明的賬號(hào)密碼進(jìn)行了加密,并向XX發(fā)送登陸請(qǐng)求。XX的登陸授權(quán)程序通過(guò)私鑰,將賬號(hào)、密碼解密,并驗(yàn)證通過(guò)。之后,將小明的個(gè)人信息(含隱私),通過(guò)私鑰加密后,傳輸回瀏覽器。瀏覽器通過(guò)公鑰解密數(shù)據(jù),并展示給小明。
- 步驟一: 小明輸入賬號(hào)密碼 --> 瀏覽器用公鑰加密 --> 請(qǐng)求發(fā)送給XX
- 步驟二: XX用私鑰解密,驗(yàn)證通過(guò) --> 獲取小明社交數(shù)據(jù),用私鑰加密 --> 瀏覽器用公鑰解密數(shù)據(jù),并展示。
用非對(duì)稱(chēng)加密,就能解決數(shù)據(jù)傳輸安全的問(wèn)題了嗎?前面特意強(qiáng)調(diào)了一下,私鑰加密的數(shù)據(jù),公鑰是可以解開(kāi)的,而公鑰又是加密的。也就是說(shuō),非對(duì)稱(chēng)加密只能保證單向數(shù)據(jù)傳輸?shù)陌踩浴?/p>
此外,還有公鑰如何分發(fā)/獲取的問(wèn)題。下面會(huì)對(duì)這兩個(gè)問(wèn)題進(jìn)行進(jìn)一步的探討。
公開(kāi)密鑰加密:兩個(gè)明顯的問(wèn)題
前面舉了小明登陸社交網(wǎng)站XX的例子,并提到,單純使用公開(kāi)密鑰加密存在兩個(gè)比較明顯的問(wèn)題。
- 公鑰如何獲取
- 數(shù)據(jù)傳輸僅單向安全
問(wèn)題一:公鑰如何獲取
瀏覽器是怎么獲得XX的公鑰的?當(dāng)然,小明可以自己去網(wǎng)上查,XX也可以將公鑰貼在自己的主頁(yè)。然而,對(duì)于一個(gè)動(dòng)不動(dòng)就成敗上千萬(wàn)的社交網(wǎng)站來(lái)說(shuō),會(huì)給用戶(hù)造成極大的不便利,畢竟大部分用戶(hù)都不知道“公鑰”是什么東西。
問(wèn)題二:數(shù)據(jù)傳輸僅單向安全
前面提到,公鑰加密的數(shù)據(jù),只有私鑰能解開(kāi),于是小明的賬號(hào)、密碼是安全了,半路不怕被攔截。
然后有個(gè)很大的問(wèn)題:私鑰加密的數(shù)據(jù),公鑰也能解開(kāi)。加上公鑰是公開(kāi)的,小明的隱私數(shù)據(jù)相當(dāng)于在網(wǎng)上換了種方式裸奔。(中間代理服務(wù)器拿到了公鑰后,毫不猶豫的就可以解密小明的數(shù)據(jù))
下面就分別針對(duì)這兩個(gè)問(wèn)題進(jìn)行解答。
問(wèn)題一:公鑰如何獲取
這里要涉及兩個(gè)非常重要的概念:證書(shū)、CA(證書(shū)頒發(fā)機(jī)構(gòu))。
證書(shū)
可以暫時(shí)把它理解為網(wǎng)站的身份證。這個(gè)身份證里包含了很多信息,其中就包含了上面提到的公鑰。
也就是說(shuō),當(dāng)小明、小王、小光等用戶(hù)訪問(wèn)XX的時(shí)候,再也不用滿世界的找XX的公鑰了。當(dāng)他們?cè)L問(wèn)XX的時(shí)候,XX就會(huì)把證書(shū)發(fā)給瀏覽器,告訴他們說(shuō),乖,用這個(gè)里面的公鑰加密數(shù)據(jù)。
這里有個(gè)問(wèn)題,所謂的“證書(shū)”是哪來(lái)的?這就是下面要提到的CA負(fù)責(zé)的活了。
CA(證書(shū)頒發(fā)機(jī)構(gòu))
強(qiáng)調(diào)兩點(diǎn):
- 可以頒發(fā)證書(shū)的CA有很多(國(guó)內(nèi)外都有)。
- 只有少數(shù)CA被認(rèn)為是權(quán)威、公正的,這些CA頒發(fā)的證書(shū),瀏覽器才認(rèn)為是信得過(guò)的。比如VeriSign。(CA自己偽造證書(shū)的事情也不是沒(méi)發(fā)生過(guò)。。。)
證書(shū)頒發(fā)的細(xì)節(jié)這里先不展開(kāi),可以先簡(jiǎn)單理解為,網(wǎng)站向CA提交了申請(qǐng),CA審核通過(guò)后,將證書(shū)頒發(fā)給網(wǎng)站,用戶(hù)訪問(wèn)網(wǎng)站的時(shí)候,網(wǎng)站將證書(shū)給到用戶(hù)。
至于證書(shū)的細(xì)節(jié),同樣在后面講到。
問(wèn)題二:數(shù)據(jù)傳輸僅單向安全
上面提到,通過(guò)私鑰加密的數(shù)據(jù),可以用公鑰解密還原。那么,這是不是就意味著,網(wǎng)站傳給用戶(hù)的數(shù)據(jù)是不安全的?
答案是:是!?。。ㄈ齻€(gè)嘆號(hào)表示強(qiáng)調(diào)的三次方)
看到這里,可能你心里會(huì)有這樣想:用了HTTPS,數(shù)據(jù)還是裸奔,這么不靠譜,還不如直接用HTTP來(lái)的省事。
但是,為什么業(yè)界對(duì)網(wǎng)站HTTPS化的呼聲越來(lái)越高呢?這明顯跟我們的感性認(rèn)識(shí)相違背啊。
因?yàn)椋篐TTPS雖然用到了公開(kāi)密鑰加密,但同時(shí)也結(jié)合了其他手段,如對(duì)稱(chēng)加密,來(lái)確保授權(quán)、加密傳輸?shù)男?、安全性?/p>
概括來(lái)說(shuō),整個(gè)簡(jiǎn)化的加密通信的流程就是:
- 小明訪問(wèn)XX,XX將自己的證書(shū)給到小明(其實(shí)是給到瀏覽器,小明不會(huì)有感知)
- 瀏覽器從證書(shū)中拿到XX的公鑰A
- 瀏覽器生成一個(gè)只有自己自己的對(duì)稱(chēng)密鑰B,用公鑰A加密,并傳給XX(其實(shí)是有協(xié)商的過(guò)程,這里為了便于理解先簡(jiǎn)化)
- XX通過(guò)私鑰解密,拿到對(duì)稱(chēng)密鑰B
- 瀏覽器、XX 之后的數(shù)據(jù)通信,都用密鑰B進(jìn)行加密
注意:對(duì)于每個(gè)訪問(wèn)XX的用戶(hù),生成的對(duì)稱(chēng)密鑰B理論上來(lái)說(shuō)都是不一樣的。比如小明、小王、小光,可能生成的就是B1、B2、B3.
參考下圖:(附上原圖出處)
證書(shū)可能存在哪些問(wèn)題
了解了HTTPS加密通信的流程后,對(duì)于數(shù)據(jù)裸奔的疑慮應(yīng)該基本打消了。然而,細(xì)心的觀眾可能又有疑問(wèn)了:怎么樣確保證書(shū)有合法有效的?
證書(shū)非法可能有兩種情況:
- 證書(shū)是偽造的:壓根不是CA頒發(fā)的
- 證書(shū)被篡改過(guò):比如將XX網(wǎng)站的公鑰給替換了
舉個(gè)例子:
我們知道,這個(gè)世界上存在一種東西叫做代理,于是,上面小明登陸XX網(wǎng)站有可能是這樣的,小明的登陸請(qǐng)求先到了代理服務(wù)器,代理服務(wù)器再將請(qǐng)求轉(zhuǎn)發(fā)到的授權(quán)服務(wù)器。
小明 --> 邪惡的代理服務(wù)器 --> 登陸授權(quán)服務(wù)器 小明 <-- 邪惡的代理服務(wù)器 <-- 登陸授權(quán)服務(wù)器
然后,這個(gè)世界壞人太多了,某一天,代理服務(wù)器動(dòng)了壞心思(也有可能是被入侵),將小明的請(qǐng)求攔截了。同時(shí),返回了一個(gè)非法的證書(shū)。
小明 --> 邪惡的代理服務(wù)器 --x--> 登陸授權(quán)服務(wù)器 小明 <-- 邪惡的代理服務(wù)器 --x--> 登陸授權(quán)服務(wù)器
如果善良的小明相信了這個(gè)證書(shū),那他就再次裸奔了。當(dāng)然不能這樣,那么,是通過(guò)什么機(jī)制來(lái)防止這種事情的放生的呢。
下面,我們先來(lái)看看”證書(shū)”有哪些內(nèi)容,然后就可以大致猜到是如何進(jìn)行預(yù)防的了。
證書(shū)簡(jiǎn)介
在正式介紹證書(shū)的格式前,先插播個(gè)小廣告,科普下數(shù)字簽名和摘要,然后再對(duì)證書(shū)進(jìn)行非深入的介紹。
為什么呢?因?yàn)閿?shù)字簽名、摘要是證書(shū)防偽非常關(guān)鍵的武器。
數(shù)字簽名與摘要
簡(jiǎn)單的來(lái)說(shuō),“摘要”就是對(duì)傳輸?shù)膬?nèi)容,通過(guò)hash算法計(jì)算出一段固定長(zhǎng)度的串(是不是聯(lián)想到了文章摘要)。然后,在通過(guò)CA的私鑰對(duì)這段摘要進(jìn)行加密,加密后得到的結(jié)果就是“數(shù)字簽名”。(這里提到CA的私鑰,后面再進(jìn)行介紹)
明文 --> hash運(yùn)算 --> 摘要 --> 私鑰加密 --> 數(shù)字簽名
結(jié)合上面內(nèi)容,我們知道,這段數(shù)字簽名只有CA的公鑰才能夠解密。
接下來(lái),我們?cè)賮?lái)看看神秘的“證書(shū)”究竟包含了什么內(nèi)容,然后就大致猜到是如何對(duì)非法證書(shū)進(jìn)行預(yù)防的了。
數(shù)字簽名、摘要進(jìn)一步了解可參考 這篇文章。
證書(shū)格式
先無(wú)恥的貼上一大段內(nèi)容,證書(shū)格式來(lái)自這篇不錯(cuò)的文章《OpenSSL 與 SSL 數(shù)字證書(shū)概念貼》
內(nèi)容非常多,這里我們需要關(guān)注的有幾個(gè)點(diǎn):
- 證書(shū)包含了頒發(fā)證書(shū)的機(jī)構(gòu)的名字 -- CA
- 證書(shū)內(nèi)容本身的數(shù)字簽名(用CA私鑰加密)
- 證書(shū)持有者的公鑰
- 證書(shū)簽名用到的hash算法
此外,有一點(diǎn)需要補(bǔ)充下,就是:
- CA本身有自己的證書(shū),江湖人稱(chēng)“根證書(shū)”。這個(gè)“根證書(shū)”是用來(lái)證明CA的身份的,本質(zhì)是一份普通的數(shù)字證書(shū)。
- 瀏覽器通常會(huì)內(nèi)置大多數(shù)主流權(quán)威CA的根證書(shū)。
證書(shū)格式
1. 證書(shū)版本號(hào)(Version)
版本號(hào)指明X.509證書(shū)的格式版本,現(xiàn)在的值可以為:
1) 0: v1
2) 1: v2
3) 2: v3也為將來(lái)的版本進(jìn)行了預(yù)定義
2. 證書(shū)序列號(hào)(Serial Number)
序列號(hào)指定由CA分配給證書(shū)的唯一的"數(shù)字型標(biāo)識(shí)符"。當(dāng)證書(shū)被取消時(shí),實(shí)際上是將此證書(shū)的序列號(hào)放入由CA簽發(fā)的CRL中,
這也是序列號(hào)唯一的原因。
3. 簽名算法標(biāo)識(shí)符(Signature Algorithm)
簽名算法標(biāo)識(shí)用來(lái)指定由CA簽發(fā)證書(shū)時(shí)所使用的"簽名算法"。算法標(biāo)識(shí)符用來(lái)指定CA簽發(fā)證書(shū)時(shí)所使用的:
1) 公開(kāi)密鑰算法
2) hash算法example: sha256WithRSAEncryption
須向國(guó)際知名標(biāo)準(zhǔn)組織(如ISO)注冊(cè)
4. 簽發(fā)機(jī)構(gòu)名(Issuer)
此域用來(lái)標(biāo)識(shí)簽發(fā)證書(shū)的CA的X.500 DN(DN-Distinguished Name)名字。包括:
1) 國(guó)家(C)
2) 省市(ST)
3) 地區(qū)(L)
4) 組織機(jī)構(gòu)(O)
5) 單位部門(mén)(OU)
6) 通用名(CN)
7) 郵箱地址
5. 有效期(Validity)
指定證書(shū)的有效期,包括:
1) 證書(shū)開(kāi)始生效的日期時(shí)間
2) 證書(shū)失效的日期和時(shí)間每次使用證書(shū)時(shí),需要檢查證書(shū)是否在有效期內(nèi)。
6. 證書(shū)用戶(hù)名(Subject)
指定證書(shū)持有者的X.500唯一名字。包括:
1) 國(guó)家(C)
2) 省市(ST)
3) 地區(qū)(L)
4) 組織機(jī)構(gòu)(O)
5) 單位部門(mén)(OU)
6) 通用名(CN)
7) 郵箱地址
7. 證書(shū)持有者公開(kāi)密鑰信息(Subject Public Key Info)
證書(shū)持有者公開(kāi)密鑰信息域包含兩個(gè)重要信息:
1) 證書(shū)持有者的公開(kāi)密鑰的值
2) 公開(kāi)密鑰使用的算法標(biāo)識(shí)符。此標(biāo)識(shí)符包含公開(kāi)密鑰算法和hash算法。
8. 擴(kuò)展項(xiàng)(extension)
X.509 V3證書(shū)是在v2的基礎(chǔ)上一標(biāo)準(zhǔn)形式或普通形式增加了擴(kuò)展項(xiàng),以使證書(shū)能夠附帶額外信息。標(biāo)準(zhǔn)擴(kuò)展是指由X.509 V3版本定義的對(duì)V2版本增加的具有廣泛應(yīng)用前景的擴(kuò)展項(xiàng),任何人都可以向一些權(quán)威機(jī)構(gòu),如ISO,來(lái)注冊(cè)一些其他擴(kuò)展,如果這些擴(kuò)展項(xiàng)應(yīng)用廣泛,也許以后會(huì)成為標(biāo)準(zhǔn)擴(kuò)展項(xiàng)。
9. 簽發(fā)者唯一標(biāo)識(shí)符(Issuer Unique Identifier)
簽發(fā)者唯一標(biāo)識(shí)符在第2版加入證書(shū)定義中。此域用在當(dāng)同一個(gè)X.500名字用于多個(gè)認(rèn)證機(jī)構(gòu)時(shí),用一比特字符串來(lái)唯一標(biāo)識(shí)簽發(fā)者的X.500名字??蛇x。
10. 證書(shū)持有者唯一標(biāo)識(shí)符(Subject Unique Identifier)
持有證書(shū)者唯一標(biāo)識(shí)符在第2版的標(biāo)準(zhǔn)中加入X.509證書(shū)定義。此域用在當(dāng)同一個(gè)X.500名字用于多個(gè)證書(shū)持有者時(shí),用一比特字符串來(lái)唯一標(biāo)識(shí)證書(shū)持有者的X.500名字??蛇x。
11. 簽名算法(Signature Algorithm)
證書(shū)簽發(fā)機(jī)構(gòu)對(duì)證書(shū)上述內(nèi)容的簽名算法
example: sha256WithRSAEncryption
12. 簽名值(Issuer's Signature)
證書(shū)簽發(fā)機(jī)構(gòu)對(duì)證書(shū)上述內(nèi)容的簽名值
如何辨別非法證書(shū)
上面提到,XX證書(shū)包含了如下內(nèi)容:
- 證書(shū)包含了頒發(fā)證書(shū)的機(jī)構(gòu)的名字 -- CA
- 證書(shū)內(nèi)容本身的數(shù)字簽名(用CA私鑰加密)
- 證書(shū)持有者的公鑰
- 證書(shū)簽名用到的hash算法
瀏覽器內(nèi)置的CA的根證書(shū)包含了如下關(guān)鍵內(nèi)容:
CA的公鑰(非常重要?。。。?/p>
好了,接下來(lái)針對(duì)之前提到的兩種非法證書(shū)的場(chǎng)景,講解下怎么識(shí)別
完全偽造的證書(shū)
這種情況比較簡(jiǎn)單,對(duì)證書(shū)進(jìn)行檢查:
- 證書(shū)頒發(fā)的機(jī)構(gòu)是偽造的:瀏覽器不認(rèn)識(shí),直接認(rèn)為是危險(xiǎn)證書(shū)
- 證書(shū)頒發(fā)的機(jī)構(gòu)是確實(shí)存在的,于是根據(jù)CA名,找到對(duì)應(yīng)內(nèi)置的CA根證書(shū)、CA的公鑰。
- 用CA的公鑰,對(duì)偽造的證書(shū)的摘要進(jìn)行解密,發(fā)現(xiàn)解不了。認(rèn)為是危險(xiǎn)證書(shū)
篡改過(guò)的證書(shū)
假設(shè)代理通過(guò)某種途徑,拿到XX的證書(shū),然后將證書(shū)的公鑰偷偷修改成自己的,然后喜滋滋的認(rèn)為用戶(hù)要上鉤了。然而太單純了:
- 檢查證書(shū),根據(jù)CA名,找到對(duì)應(yīng)的CA根證書(shū),以及CA的公鑰。
- 用CA的公鑰,對(duì)證書(shū)的數(shù)字簽名進(jìn)行解密,得到對(duì)應(yīng)的證書(shū)摘要AA
- 根據(jù)證書(shū)簽名使用的hash算法,計(jì)算出當(dāng)前證書(shū)的摘要BB
- 對(duì)比AA跟BB,發(fā)現(xiàn)不一致--> 判定是危險(xiǎn)證書(shū)
HTTPS握手流程
上面啰啰嗦嗦講了一大通,HTTPS如何確保數(shù)據(jù)加密傳輸?shù)陌踩臋C(jī)制基本都覆蓋到了,太過(guò)技術(shù)細(xì)節(jié)的就直接跳過(guò)了。
最后還有最后兩個(gè)問(wèn)題:
- 網(wǎng)站是怎么把證書(shū)給到用戶(hù)(瀏覽器)的
- 上面提到的對(duì)稱(chēng)密鑰是怎么協(xié)商出來(lái)的
上面兩個(gè)問(wèn)題,其實(shí)就是HTTPS握手階段要干的事情。HTTPS的數(shù)據(jù)傳輸流程整體上跟HTTP是類(lèi)似的,同樣包含兩個(gè)階段:握手、數(shù)據(jù)傳輸。
- 握手:證書(shū)下發(fā),密鑰協(xié)商(這個(gè)階段都是明文的)
- 數(shù)據(jù)傳輸:這個(gè)階段才是加密的,用的就是握手階段協(xié)商出來(lái)的對(duì)稱(chēng)密鑰
作者:程序猿小卡
原文:http://www.cnblogs.com/chyingp/p/https-introduction.html#undefined