前言:在一個(gè)app運(yùn)行時(shí)期,由于android進(jìn)程隔離的原因,每個(gè)應(yīng)用都有自己獨(dú)立的內(nèi)存空間,其他應(yīng)用是無(wú)法直接訪問(wèn)的,當(dāng)然除非該APP對(duì)外提供接口,這樣的話,在app運(yùn)行時(shí)主要的安全隱患就在于對(duì)外的通訊上,而最主要的通訊也就是網(wǎng)絡(luò)通訊,在網(wǎng)絡(luò)通訊中數(shù)據(jù)從客戶端發(fā)送到服務(wù)端,中間會(huì)通過(guò)多個(gè)網(wǎng)絡(luò)節(jié)點(diǎn),如何保證數(shù)據(jù)的安全需要考慮.
本章主要通過(guò)兩個(gè)方面來(lái)理解https
1.一步步還原h(huán)ttps的設(shè)計(jì)過(guò)程
2.根據(jù)設(shè)計(jì)過(guò)程來(lái)分析SSL在握手時(shí)所做的事情
在開(kāi)始之前需要明白幾個(gè)知識(shí)點(diǎn):
1.什么是第三方網(wǎng)絡(luò)節(jié)點(diǎn)?
當(dāng)我們通過(guò)網(wǎng)絡(luò)傳遞數(shù)據(jù)時(shí),數(shù)據(jù)不是直接從客戶端傳遞到服務(wù)端的,而是會(huì)經(jīng)過(guò)一些網(wǎng)絡(luò)節(jié)點(diǎn),比如說(shuō)路由器,代理服務(wù)器等,他們都屬于網(wǎng)絡(luò)節(jié)點(diǎn).
打個(gè)簡(jiǎn)單的比方:當(dāng)我們寄信件時(shí),我就相當(dāng)于客戶端,而收件人就相當(dāng)于服務(wù)端,中間經(jīng)過(guò)的所有快遞員都屬于第三方的網(wǎng)絡(luò)節(jié)點(diǎn).
2.如何保證數(shù)據(jù)的安全?
保證數(shù)據(jù)的安全需要從三方面,數(shù)據(jù)內(nèi)容的加密,通訊雙方的身份校驗(yàn),檢查數(shù)據(jù)的完整性
數(shù)據(jù)內(nèi)容的加密:通訊雙方協(xié)定一組加密算法,所有通訊的內(nèi)容通過(guò)這套算法加密后再進(jìn)行傳輸.相當(dāng)于在將信件的內(nèi)容加密,從而防止快遞員獲取信件上的內(nèi)容.
通訊雙方的身份校驗(yàn): 接到消息以后需要檢查發(fā)送方的身份.相當(dāng)于在接到信件時(shí)檢查寄件人的簽名,防止快遞員將信件調(diào)包.
數(shù)據(jù)內(nèi)容的完整性:保證數(shù)據(jù)不被篡改,就算被篡改,也可以察覺(jué).相當(dāng)于檢查信件的內(nèi)容是被修改,防止快遞員對(duì)信件內(nèi)容進(jìn)行修改.
有了以上的保證,可以滿足一條數(shù)據(jù)傳遞的安全性.
3.常用的加密算法
對(duì)稱加密:AES,DES等加密算法通過(guò)一個(gè)密鑰進(jìn)行加密和解密,計(jì)算速度快.但如果中介人獲取密鑰,則整個(gè)通訊就是不安全的.
非對(duì)稱加密:DES算法,生成公鑰和私鑰,客戶端通過(guò)公鑰加密,服務(wù)其通過(guò)私鑰解密,同理服務(wù)端通過(guò)私鑰加密,客戶端通過(guò)公鑰解密.好處相比與對(duì)稱加密更安全,但是運(yùn)算速度慢.
HASH加密算法:MD5,SHA1 加密得到一32位或者64位的值,也叫做數(shù)字指紋,這個(gè)過(guò)程是不可逆的.
有了以上的知識(shí)點(diǎn),我們來(lái)通過(guò)抽象的角度來(lái)模擬還原h(huán)ttps的設(shè)計(jì)過(guò)程.
1.為了保證數(shù)據(jù)的安全性,server端要求在發(fā)送數(shù)據(jù)包時(shí)的使用通過(guò)一套加密規(guī)則對(duì)內(nèi)容進(jìn)行加密,保證數(shù)據(jù)不會(huì)被泄露.
問(wèn)題:服務(wù)器和客戶端如果通過(guò)AES進(jìn)行加密.由于客戶端數(shù)量太多,如果所有的客戶端對(duì)服務(wù)器都使用同一套加密方法的話,整個(gè)通訊就顯得不安全了.
2.為了解決以上問(wèn)題,需要服務(wù)端為每個(gè)客戶端采用不同的加密規(guī)則,
問(wèn)題:但是如何協(xié)商這個(gè)規(guī)則又成了問(wèn)題,服務(wù)器不能直接將加密規(guī)則發(fā)送給客戶端,因?yàn)檫@樣會(huì)讓中間人(網(wǎng)絡(luò)結(jié)點(diǎn)獲取到加密規(guī)則).中間人一樣可以通過(guò)獲取的加密規(guī)則破解信息.
3.這時(shí)候我們不能將加密規(guī)則繼續(xù)加密,否則就會(huì)進(jìn)入死循環(huán)進(jìn)入雞生蛋,蛋生雞的問(wèn)題上了.為了解決這個(gè)問(wèn)題,用一套非對(duì)稱加密的算法給加密規(guī)則進(jìn)行加密.首先服務(wù)器為每個(gè)客戶端生成一個(gè)公鑰,將公鑰發(fā)送給客戶端,然后客戶端選擇一個(gè)支持的加密算法通過(guò)接受到的公鑰進(jìn)行加密發(fā)送給服務(wù)器,之后的通訊就按照這套加密算法來(lái)完成.這樣做的好處是:即使中間人獲取到了公鑰,他也無(wú)法獲取客戶端用公鑰加密的加密算法
問(wèn)題:但是卻由于一個(gè)問(wèn)題就是中間人可以將服務(wù)器發(fā)送的公鑰調(diào)包,而客戶端無(wú)法辨別發(fā)送到的公鑰是中間人的還是服務(wù)器的公鑰,這樣就造成中間人攻擊的漏洞.
4.為了解決以上問(wèn)題,需要解決身份校驗(yàn)的問(wèn)題,而在HTTPS中解決身份校驗(yàn)問(wèn)題則使用權(quán)威的第三方機(jī)構(gòu)也就是CA機(jī)構(gòu)向安全的服務(wù)器來(lái)頒發(fā)證書證明身份的合法性,服務(wù)器通過(guò)CA辦法的證書將自己服務(wù)器的公鑰加密生成一個(gè)數(shù)字證書發(fā)送給客戶端,客戶端接受到數(shù)字證書以后通過(guò)第三方機(jī)構(gòu)的公鑰將數(shù)字證書解密,獲取服務(wù)器的公鑰,然后繼續(xù)走剛才說(shuō)的上面的流程.這樣就保證了這一次通訊的安全性.
這里涉及到兩個(gè)問(wèn)題:
4.1客戶端如何得到第三方機(jī)構(gòu)的公鑰?
一般在瀏覽器和操作系統(tǒng)上都會(huì)存放一些權(quán)威的第三方機(jī)構(gòu)的公鑰.
4.2如果惡意中間人得到第三方CA機(jī)構(gòu)的認(rèn)證會(huì)怎么辦?
如果惡意服務(wù)器獲取到CA頒發(fā)的證書的話,則這個(gè)CA機(jī)構(gòu)頒發(fā)的所有證書都會(huì)被視為不安全的,所以CA在頒發(fā)證書的時(shí)候一定特別小心.
5.由于CA機(jī)構(gòu)的認(rèn)證是收費(fèi)的,所以我們也可以自己制作證書,客戶端將證書的公鑰放入資源文件中,在驗(yàn)證數(shù)字證書合法性時(shí)通過(guò)自己制作的證書,而不是通過(guò)系統(tǒng)提供的CA頒發(fā)的公鑰,在使用自己證書的時(shí)候由于是在客戶端的包下,有可能會(huì)被一些不法的網(wǎng)站獲取后進(jìn)行中間人攻擊,所以需要對(duì)數(shù)字證書進(jìn)行數(shù)字簽名的驗(yàn)證,驗(yàn)證數(shù)字證書的方法很簡(jiǎn)單,數(shù)字證書中包含證書編號(hào),而這個(gè)證書編號(hào)是通過(guò)服務(wù)器的網(wǎng)址和證書的內(nèi)容通過(guò)加密算法得到的,客戶端只需要通過(guò)這個(gè)加密算法對(duì)證書進(jìn)行再一次的計(jì)算以后,然后與證書編號(hào)比對(duì)是否一樣.這樣就可以得知是否被篡改.
通過(guò)以上的了解相信大家對(duì)HTTPS的流程會(huì)有一點(diǎn)的了解,那么我們通過(guò)TLS/SSL建立鏈接時(shí)的握手過(guò)程來(lái)進(jìn)一步理解https
我們都知道Http的數(shù)據(jù)都是通過(guò)明文傳輸?shù)?而在HTTPS中真正起到加密的是TLS/SSL協(xié)議,而這個(gè)協(xié)議在網(wǎng)絡(luò)分層模型處于繪畫層的也就是在傳輸層TCP協(xié)議建立鏈接以后,在http協(xié)議傳遞數(shù)據(jù)之前.所以對(duì)于上層協(xié)議HTTP來(lái)他是無(wú)感知的.這就是網(wǎng)絡(luò)分層模型的優(yōu)點(diǎn).
我們通過(guò)上面的圖來(lái)分析一下SSL/TLS握手的過(guò)程
1.從藍(lán)色部分可以看出先通過(guò)TCP協(xié)議的三次握手建立TCP/IP的鏈接.SSL是在TCP鏈接之上進(jìn)行的.
2.Client Hello.:握手第一步是客戶端向服務(wù)端發(fā)送 Client Hello 消息绪囱，這個(gè)消息里包含了一個(gè)客戶端生成的隨機(jī)數(shù) Random1杉编、客戶端支持的加密算法和 SSL Version 等信息
3.ServerHello:服務(wù)器收到客戶端的Hello Client請(qǐng)求,取出Random1以及支持的加密算法,并生成一個(gè)隨機(jī)數(shù)Random2,然后從客戶端支持的加密算法中選出一種,發(fā)送給客戶端ServerHello.
4.Certificate:這一步是讓客戶端對(duì)服務(wù)器進(jìn)行身份校驗(yàn),服務(wù)端通過(guò)將自己的公鑰通過(guò)數(shù)字證書的方式發(fā)送給客戶端
5.Client Key Exchange:客戶端收到服務(wù)端傳來(lái)的證書后，先從 CA 驗(yàn)證該證書的合法性赘艳，驗(yàn)證通過(guò)后取出證書中的服務(wù)端公鑰斯够，再生成一個(gè)隨機(jī)數(shù) Random3，再用服務(wù)端公鑰非對(duì)稱加密 Random3 生成 PreMaster Key六剥。并將PreMaster Key發(fā)送到服務(wù)端,服務(wù)端通過(guò)私鑰將PreMaster Key解密獲取到Random3,此時(shí)客戶端和服務(wù)器都持有三個(gè)隨機(jī)數(shù)Random1 Random2 Random3,雙方在通過(guò)這三個(gè)隨即書生成一個(gè)對(duì)稱加密的密鑰.雙方根據(jù)這三個(gè)隨即數(shù)聽(tīng)過(guò)相同的算法生成一個(gè)密鑰,而以后應(yīng)用層傳輸?shù)臄?shù)據(jù)都使用這套密鑰進(jìn)行加密.
6.Change Cipher Spec:告訴客戶端以后的通訊都使用這一套密鑰來(lái)進(jìn)行.
以上就是一個(gè)簡(jiǎn)單的TLS/SSL握手過(guò)程.其實(shí)https就是在Http的基礎(chǔ)上加入TLS/SSL來(lái)保證數(shù)據(jù)的安全性.
用一句話總結(jié)https的的工作方式就是:
https要使客戶端與服務(wù)端通訊的安全保障,必須通過(guò)對(duì)稱加密來(lái)對(duì)內(nèi)容進(jìn)行處理,但是在協(xié)商對(duì)稱加密算法時(shí)需要用到不對(duì)稱加密來(lái)保障協(xié)商過(guò)程的安全,但是非對(duì)稱加密本身也是不安全的,可能會(huì)被中間人篡改公鑰而進(jìn)行中間人攻擊,而只能通過(guò)數(shù)字證書簽發(fā)機(jī)構(gòu)來(lái)對(duì)非對(duì)稱加密時(shí)的身份校驗(yàn)來(lái)保證非對(duì)稱加密本身的安全性,通過(guò)這套機(jī)制來(lái)協(xié)商出一套對(duì)稱加密的算法,而使http通訊時(shí)通過(guò)這套算法來(lái)對(duì)內(nèi)容進(jìn)行加密.
