前面聊了HTTP
的相關(guān)東西勺像,今天就來聊一聊HTTPS
的東西。
因為HTTP
協(xié)議本身存在著明文傳輸、不能很好的驗證通信方的身份和無法驗證報文的完整性等一些安全方面的確點,所以才有了HTTPS
的缺陷瀑梗。
HTTPS
確切的的說不是一種協(xié)議,而是HTTP + SSL (TSL)
的結(jié)合體蔑鹦。HTTP
報文經(jīng)過SSL
層加密后交付給TCP
層進行傳輸夺克。SSL
(安全套節(jié)層)主要采取的是RSA
(非對稱加密)與AES
(對稱加密)結(jié)合的加密方式箕宙。先通過RSA
交互AES
的密鑰嚎朽,然后通過AES
進行報文加密和解密。
一柬帕、RSA與AES簡述
如果你在公司做過支付相關(guān)的東西哟忍,對數(shù)據(jù)傳輸?shù)陌踩砸蟊容^高狡门,這時候就得采取一些加密措施將傳輸?shù)膱笪倪M行加密,必要時再進行MD5驗簽锅很。當然本部分聊的RAS
與AES
是比較簡潔的其馏,關(guān)于這兩者具體的內(nèi)容,請自行Google吧爆安。因為HTTPS
在傳輸?shù)倪^程中使用到了RSA
與AES
加密算法叛复,所以在聊HTTP+SSL
之前呢,我們先簡單的聊一下AE
S與RSA
扔仓。
1褐奥、 AES高級加密標準(對稱加密)
AES
:全稱Advanced Encryption Standard
高級加密標準。該加密算法有一個密鑰翘簇,該密鑰可以用來加密撬码,也可以用來解密,所以AES是對稱加密算法版保。下方這個就是AES
加密和解密的過程呜笑。Client
端與Server
端有一個共同的Key
, 這個Key
是用來加密和解密的。如果報文在傳輸?shù)倪^程中被竊取了彻犁,沒有這個key
, 對加密的內(nèi)容進行破解是非常困難的叫胁,當然竊取者如果有key
的話,也是可以輕而易舉的解密的汞幢。所以在AES
中曹抬,key
是關(guān)鍵。這也就相當于你們家的門鑰匙急鳄,誰拿到鑰匙后都可以打開你們家的門谤民。即使門鎖再結(jié)實,再安全疾宏,在鑰匙面前也是不行呢张足。
所以對于AES
加密策略來說這個Key
的保密措施要做足一些。比如每次加密的Key
都是從一個密碼本中動態(tài)生成的坎藐,而這個密碼本服務(wù)端和客戶端都有同一本为牍,每次傳輸?shù)氖且恍﹨?shù)。這些參數(shù)在經(jīng)過一些算法的映射岩馍,從密碼本中取出相應(yīng)的key
用來解密碉咆。這樣一來,就相當于給AES
加了一層防盜門蛀恩,加大了破解的難度疫铜。這樣做的好處是每次加密的key都是不同的,而且需要密碼本以及映射算法的支持双谆。
2壳咕、RSA 公鑰加密算法(非對稱加密)
RAS
這個名字席揽,就是該算法三位發(fā)明者的名字的首字母的組合。RAS
是非對稱加密谓厘,其在加密和解密的過程中幌羞,需要兩個Key
,一個公鑰(public key
)竟稳,一個是私鑰(private key
)属桦。公鑰負責加密,而私鑰負責解密他爸。從名字就可以看出地啰,公鑰是可以開放出去的,任何人都可以持有公鑰進行加密讲逛。而私鑰必須得進行保護亏吝,因為是用來解密的。
這樣一來盏混,加密和解密就可以用不同的鑰匙來處理蔚鸥。對于加密放來說,即使你可以對報文進行加密许赃,如果沒有私有的話也是不可以對你加密的內(nèi)容進行解密的止喷。這就相當于一個盒子,盒子上有把鎖混聊。你可以把東西放進去弹谁,然后再鎖上盒子。但是如果你沒有鑰匙的話句喜,也是打不開這把鎖的预愤。
下方這個簡圖就是服務(wù)端單向驗證的RAS
非對稱加密算法,Client
內(nèi)置了一個公鑰咳胃,該公鑰與Server
端的私鑰是配對的植康,所以Client
端可以使用這個內(nèi)置的Public key
加密,而服務(wù)端就可以使用這個private key
進行解密展懈。目前最常用的是服務(wù)端單向認證機制销睁。
二、CA(Certificate Authority)證書
如果你自己通過RAS
算法生成了一個私鑰和公鑰存崖,在公鑰發(fā)送給客戶端的過程中有可能被篡改成其他的公鑰冻记,而客戶端在沒有其他措施的保護下是不知道該公鑰是否就是服務(wù)器那邊的私鑰對應(yīng)的公鑰的。這種自己做的RAS
的公鑰和私鑰有可能在公鑰分發(fā)的過程中被篡改来惧。下方就是Client
從Server
端獲取公鑰時被中間者篡改了冗栗,將public
換成了自己的偽public key
, 同樣這個中間者持有這個偽public key
所對應(yīng)的偽private key
。如果客戶端使用的偽public key
進行加密傳輸?shù)脑挘敲粗虚g者是可以使用自己的private key
進行解密的贞瞒。
舉個例子來類比一下這個問題偶房。
假設(shè)你在古代趁曼,你出門在外军浆,妻子在家養(yǎng)子。你們家有個箱子挡闰,箱子上有把鎖乒融,這就是你和你妻子互通的工具。你媳婦兒負責往箱子里放東西摄悯,然后上鎖赞季。你有把獨特的鑰匙,你負責開鎖奢驯,取東西申钩。可是你再將箱子給鏢局托運的的過程中瘪阁,被鏢局的“小黑”掉包了撒遣,箱子的外表一致,鎖看起來也一樣管跺,可是已經(jīng)不是你的箱子了义黎。因為路途遙遠,古代又沒有什么iPhone啥的豁跑,你媳婦沒辦法來辨別該箱子是否是原裝的廉涕。然后就將一些東西放在了箱子里邊,然后上鎖交給了鏢局的“小黑”艇拍。
因為“小黑”掉包的箱子狐蜕,所以小黑有箱子的鑰匙呢,然后就可以打開這個箱子卸夕,取東西了馏鹤。原來的箱子又在小黑那,小黑就可以往原來的箱子里邊隨便往箱子放點沒有價值的東西給你就行了娇哆。當你發(fā)現(xiàn)箱子里的東西不是你想要的時候湃累,完了,小黑從鏢局辭職了碍讨,找不到人了治力。找鏢局的人討說法,可是鏢局的人說“小黑”是鏢局的臨時工勃黍,這個責任鏢局說了宵统,我們不能擔。鑒于你無權(quán)無勢,這事兒也就此罷了马澈。(故事純屬虛構(gòu)瓢省,如有雷同純屬巧合)
為了防止“小黑”再次作案,所以頒布一個公正機構(gòu)來證明你媳婦收到的箱子就是你發(fā)出的箱子痊班。在RAS加密中也有一個第三方機構(gòu)來充當這個角色勤婚,負責證明客戶端收到的證書就是你發(fā)送的證書,中間沒有被篡改涤伐。這個中間認證機構(gòu)馒胆,就是數(shù)組證書認證機構(gòu), 其頒發(fā)的證書也就是我們常說的CA證書(CA , Certificate Authority)。
下面我們就來詳細的敘述一下證書簽名凝果,證書分發(fā)以及證書驗證的整個過程祝迂。
1、服務(wù)端人員使用RSA算法生成兩個密鑰器净,一個用來加密一個用來解密型雳。將負責加密的那個密鑰公布出去,所以我們稱之為公鑰(Public Key)山害,而用來解密的那個密鑰纠俭,不能對外公布,只有服務(wù)端持有粗恢,所以我們稱之為私鑰(Private Key)柑晒。服務(wù)端在將Public Key進行分發(fā)證書之前需要向CA機構(gòu)申請給將要分發(fā)的公鑰進行數(shù)字簽名。(**服務(wù)器公鑰負責加密眷射,服務(wù)器私鑰負責解密**)
2匙赞、生成數(shù)字簽名公鑰證書:對于CA機構(gòu)來說,其也有兩個密鑰妖碉,我們暫且稱之為CA私鑰和CA公鑰涌庭。CA機構(gòu)將服務(wù)端的Public Key作為輸入?yún)?shù)將其轉(zhuǎn)換為一個特有的Hash值。然后使用CA私鑰將這個Hash值進行加密處理欧宜,并與服務(wù)端的Public Key綁定在一起坐榆,生成數(shù)字簽名證書巍沙。其實數(shù)字簽名證書的本質(zhì)就是服務(wù)端的公鑰+CA私鑰加密的Hash值清焕。(**CA私鑰負責簽名,CA公鑰負責驗證**)
3杈女、服務(wù)器獲取到這個已經(jīng)含有數(shù)字簽名并帶有公鑰的證書夏漱,將該證書發(fā)送給客戶端豪诲。當客戶端收到該公鑰數(shù)字證書后,會驗證其有效性挂绰。大部分客戶端都會預(yù)裝CA機構(gòu)的公鑰屎篱,也就是CA公鑰。客戶端使用CA公鑰對數(shù)字證書上的簽名進行驗證交播,這個驗證的過程就是使用CA公鑰對CA私鑰加密的內(nèi)容進行解密重虑,將解密后的內(nèi)容與服務(wù)端的Public Key所生成的Hash值進行匹配,如果匹配成功秦士,則說明該證書就是相應(yīng)的服務(wù)端發(fā)過來的缺厉。否則就是非法證書。
4伍宦、驗證完服務(wù)端公鑰的合法性后芽死,就可以使用該公鑰進行加密通信了乏梁。
下方這個截圖就是蘋果的根證書的一些信息次洼,從下方可以看出,CA證書內(nèi)容中包括加密算法遇骑,公共密鑰以及數(shù)字簽名卖毁。
下方就是公鑰以及數(shù)字簽名的具體內(nèi)容,當對下方公共密鑰進行驗證時落萎,需要使用內(nèi)置的CA公鑰將數(shù)字簽名進行解密亥啦。然后將解密后的內(nèi)容,與公鑰生成的Hash值進行比較练链,如果匹配成功翔脱,那么該證書就是CA機構(gòu)頒布的合法證書。
三媒鼓、HTTPS安全通信機制的建立
上面我們聊完AES
與RSA
加密策略届吁,然后又聊了帶有數(shù)字簽名的公共密鑰。上面這兩部分內(nèi)容都是為HTTPS
做鋪墊的绿鸣,接下來就看一看HTTP+SSL
是如何進行數(shù)據(jù)傳輸?shù)摹?/p>
1疚沐、HTTPS簡介
在開頭的部分也說了,HTTPS
不是一個新的通信協(xié)議潮模,而是HTTP
與SSL
(或TSL
)的組合亮蛔。--SSL
安全套節(jié)層(Secure Socket Layer
), TSL
(Transport Layer Security
安全傳輸層)是以SSL
為原型開發(fā)的協(xié)議,IETF
以SSL3.0
為基準后又制定了TLS1.0擎厢、TLS1.1和TLS1.2
究流,當前主流版本為SSL3.0與TLS1.0
。
HTTPS
就是在HTTP
與TCP
層中間添加了一個SSL
層动遭。因為HTTPS
被HTTP
多了這層加密的流程芬探,所以HTTPS
的速度要比HTTP
慢的多(需要各種加密解密驗證)。
2沽损、 HTTPS的通信過程
SSL
的加密過程是RSA
與AES
混合進行的灯节。簡單概括一下,就是通過RSA
加密方式來交換AES
加解密的密鑰,然后使用AES
加密的方式來傳輸報文炎疆。下方是SSL
建立連接以及傳輸數(shù)據(jù)的圖解卡骂。在下圖中大體可以分為四步:
第一步:有客戶端發(fā)起的第一次握手,此次握手過程的主要目的是從服務(wù)端獲取數(shù)字簽名證書形入,服務(wù)端在發(fā)送數(shù)字簽名證書之前要先確認客戶端的
SSL
版本全跨、加密算法等信息。
第二步:完成第一次握手后亿遂,接著進行第二次握手浓若。第二次握手是在客戶端收到證書后發(fā)起的,主要目的是將
AES
加解密使用的Key (Pre-master secret)
發(fā)送給服務(wù)端蛇数。當然這個AES_KEY
是使用第一次握手獲取的公鑰進行加密的挪钓。客戶端收到這個使用公鑰加密后的AES_KEY
耳舅,使用服務(wù)端的私鑰進行解密碌上。這樣客戶端和服務(wù)端經(jīng)過二次握手后都持有了AES
加解密的KEY
。
第三步:當
Client
與Server
端都持有AES_KEY
后浦徊,就可以對HTTP
報文進行加解密了馏予。
END: 最后就是斷開連接了。具體如下圖所示:
出處:http://www.cnblogs.com/ludashi/
如果文中有什么錯誤盔性,歡迎指出霞丧。以免更多的人被誤導(dǎo)。