產(chǎn)生原因:
- HTTP:未加密础倍、明文捅膘。
-
SSL(Secure Sockets Layer)
=>TLS(Transport Layer Security)
郁妈,目前大部分https都是用的TLS堡距,只不過SSL出現(xiàn)最早我們有時候也依然叫SSL猩系。 - HTTPS = HTTP + TLS
對稱加密和非對稱加密
對稱加密就是用同一個密鑰加密媚送、解密。
如圖寇甸,A如果直接發(fā)送data塘偎,肯定會經(jīng)過若干中間人M(如路由等),HTTP就是純明文的拿霉,M可以獲取所有明文數(shù)據(jù)吟秩。
而通過對稱加密,如果A和B都有密鑰key绽淘,M沒有密鑰就無法得到明文的data涵防。
但問題來了,現(xiàn)在A生成了一個密鑰key沪铭,怎么將其傳給B呢壮池?若直接發(fā)送,那M也會得到伦意,那加密也沒啥意義了火窒。非對稱加密
就是為了解決這個而誕生的。
非對稱加密驮肉,就是生成倆key熏矿,一個公鑰key1一個私鑰key2,key1加密的數(shù)據(jù)只能用key2解密离钝,而key2加密的數(shù)據(jù)只能用key1解密票编。這種算法事實上有很多,常用的是 RSA卵渴,其基于的數(shù)學原理是兩個大素數(shù)的乘積很容易算慧域,而拿到這個乘積去算出是哪兩個素數(shù)相乘就很復雜了。好在以目前的技術浪读,分解大數(shù)的素因數(shù)確實比較困難昔榴,尤其是當這個大數(shù)足夠大的時候(通常使用2的10次方個二進制位這么大)辛藻,就算是超級計算機解密也需要非常長的時間。
- 先在A生成公鑰key1和私鑰key2互订,發(fā)送公鑰key1給B吱肌,M可以拿到明文的key1,但拿到也沒啥用仰禽。
- B拿到公鑰key1后氮墨,生成一個密鑰key,然后用公鑰key1把密鑰key加密吐葵,回傳給A规揪。此時通過M時,因為數(shù)據(jù)只能用私鑰key2才能解密温峭,M只有key1猛铅,所以并不能看到其內(nèi)容。
- A拿到加密后的密鑰key后诚镰,通過key2解密奕坟。此時,A清笨、B都擁有了密鑰key,可以通過密鑰key進行對稱加密了刃跛。
CA證書(Certification Authority)
然而抠艾,非對稱加密一定是安全的嗎?
- M在收到公鑰key1的時候桨昙,把key1存起來检号,同時又生成一個偽公鑰key_a和偽私鑰key_b,
- M把偽公鑰key_a發(fā)送給B蛙酪,B依然按照原來的邏輯生成密鑰key齐苛。然后通過收到的偽公鑰key_a加密密鑰key,然后發(fā)送給M桂塞。
- M收到數(shù)據(jù)后凹蜂,通過偽私鑰key_b解密,得到了明文的密鑰key阁危。然后用key1加密密鑰玛痊,再發(fā)送給A,最后A通過key2解密得到密鑰key狂打。
-
此時A擂煞、B、M都知道了密鑰趴乡,但是A对省、B并不知道M已經(jīng)知道了密鑰蝗拿,接下來的消息傳遞對M來說都是明文的了。
這就要用到了CA證書蒿涎。CA 是一些非常權威的專門用于認證一個網(wǎng)站合法性的組織蛹磺。服務商可以向他們申請一個證書,使得他們建立安全連接時可以帶上 CA 的簽名同仆。而 CA 的安全性由操作系統(tǒng)或瀏覽器來認證萤捆。你的 Windows、Mac俗批、Linux俗或、Chrome、Safari 等會在安裝時帶上一個他們認為安全的 CA 證書列表岁忘。如果和你建立安全連接的人帶著這些人的簽名辛慰,那么認為這個安全連接是安全的,沒有遭到中間人攻擊干像。
CA 證書通常情況下是安全的帅腌。因為一旦某個 CA 頒發(fā)出的某個證書被用于了非法用途,瀏覽器和操作系統(tǒng)一般會通過更新將整個 CA 頒發(fā)過的全部證書全部視為不安全麻汰。這使得 CA 通常在頒發(fā)證書時是比較小心的速客。
所以通過 對稱加密 + 非對稱加密 + CA認證 這三個技術混合在一起,才使得 HTTP 的后面加上了一個 S —— Security五鲫。
HTTPS原理
下圖是一個簡單的原理:
- 1.瀏覽器輸入url請求網(wǎng)站溺职,并附帶自己支持的一套加密規(guī)則。
- 2.網(wǎng)站制作證書位喂,這個應該是網(wǎng)站建站的時候就已經(jīng)弄好了浪耘。證書分為服務器證書和客戶端證書,我們所說的證書一般都是指服務器證書塑崖。制作過程如下:
ssl證書相關:http://www.reibang.com/p/4494774963a9
- a) 制作CSR文件七冲。就是制作Certificate Secure Request證書請求文件,制作過程中规婆,系統(tǒng)會產(chǎn)生2個密鑰澜躺,一個是公鑰就是這個CSR文件,另一個是私鑰聋呢,存在服務器上苗踪。
- b) CA認證。將CSR文件提交給CA削锰,一般有兩種認證方式:域名認證 和 企業(yè)文檔認證通铲。
- c) 證書安裝。收到CA證書后器贩,將證書部署在服務器上颅夺。
- 3.網(wǎng)站從瀏覽器發(fā)過來的加密規(guī)則中選一組自身也支持的加密算法和hash算法朋截,并向瀏覽器發(fā)送帶有公鑰的證書,當然證書還包含了很多信息吧黄,如網(wǎng)站地址部服、證書的頒發(fā)機構、過期時間等拗慨。
- 4.瀏覽器解析證書廓八。
- a) 驗證證書的合法性。如頒發(fā)機構是否合法赵抢、證書中的網(wǎng)站地址是否與訪問的地址一致剧蹂,若不合法,則瀏覽器提示證書不受信任烦却,若合法宠叼,瀏覽器會顯示一個小鎖頭。
- b) 若合法其爵,或用戶接受了不合法的證書冒冬,瀏覽器會生成一串隨機數(shù)的密碼(即密鑰),并用證書中提供的公鑰加密摩渺。
- c) 使用約定好的hash計算握手消息简烤,并使用生成的隨機數(shù)(即密鑰)對消息進行加密,最后將之前生成的所有消息一并發(fā)送給網(wǎng)站服務器证逻。
- 5.網(wǎng)站服務器解析消息乐埠。用已有的私鑰將密鑰解密出來,然后用密鑰解密發(fā)過來的握手消息囚企,并驗證是否跟瀏覽器傳過來的一致。然后再用密鑰加密一段握手消息瑞眼,發(fā)送給瀏覽器龙宏。
-
6.瀏覽器解密并計算握手消息的HASH,如果與服務端發(fā)來的HASH一致伤疙,此時握手過程結束银酗,之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機密碼并利用對稱加密算法進行加密。這里瀏覽器與網(wǎng)站互相發(fā)送加密的握手消息并驗證徒像,目的是為了保證雙方都獲得了一致的密碼黍特,并且可以正常的加密解密數(shù)據(jù),為后續(xù)真正數(shù)據(jù)的傳輸做一次測試锯蛀。
另外灭衷,HTTPS一般使用的加密與HASH算法如下:
非對稱加密算法:RSA,DSA/DSS
對稱加密算法:AES旁涤,RC4翔曲,3DES
HASH算法:MD5迫像,SHA1,SHA256
其中非對稱加密算法用于在握手過程中加密生成的密碼瞳遍,對稱加密算法用于對真正傳輸?shù)臄?shù)據(jù)進行加密闻妓,而HASH算法用于驗證數(shù)據(jù)的完整性。由于瀏覽器生成的密碼是整個數(shù)據(jù)加密的關鍵掠械,因此在傳輸?shù)臅r候使用了非對稱加密算法對其加密由缆。非對稱加密算法會生成公鑰和私鑰,公鑰只能用于加密數(shù)據(jù)猾蒂,因此可以隨意傳輸均唉,而網(wǎng)站的私鑰用于對數(shù)據(jù)進行解密,所以網(wǎng)站都會非常小心的保管自己的私鑰婚夫,防止泄漏浸卦。
TLS握手過程中如果有任何錯誤,都會使加密連接斷開案糙,從而阻止了隱私信息的傳輸限嫌。正是由于HTTPS非常的安全,攻擊者無法從中找到下手的地方时捌,于是更多的是采用了假證書的手法來欺騙客戶端怒医,從而獲取明文的信息,但是這些手段都可以被識別出來奢讨。
其他參考:http://www.admin5.com/article/20150505/597061.shtml
https://wenku.baidu.com/view/4112d2cf960590c69ec376b4.html
https://wenku.baidu.com/view/b753d97a79563c1ec4da715d.html?from=search