每當(dāng)我們討論到信息安全的時候，我們最長接觸到的信息加密傳輸?shù)姆绞侥^于HTTPS了，當(dāng)我們?yōu)g覽器地址欄閃現(xiàn)出綠色時，就代表著這個網(wǎng)站支持HTTPS的加密信息傳輸方式，并且你與它的連接確實(shí)被加密了。但是HTTPS并不是一個單一的東西，它知識我們常見的HTTP協(xié)議和某個加密協(xié)議的一個混合，這個加密協(xié)議通常會是TLS。那么HTTPS為什么安全呢？其實(shí)我們需要先考慮HTTP為什么不安全。

假設(shè)你坐在一個教室里，你現(xiàn)在非常想把某個信息傳遞給教室里的另一個人，一般來說，會選擇，傳紙條。傳紙條這個比喻其實(shí)非常正確，這就是互聯(lián)網(wǎng)的一個基礎(chǔ)協(xié)議TCP/IP協(xié)議基本的工作模式。而通常，HTTP協(xié)議的數(shù)據(jù)是使用TCP/IP協(xié)議進(jìn)行發(fā)送的。HTTP指的是你在紙條上寫明你要傳送的目的地是哪個同學(xué)的坐位，然后再是要傳遞的內(nèi)容。途徑的同學(xué)拿到紙條后根據(jù)紙條上顯示的地址依次傳過去就好了。這樣要面臨的第一個問題就是：途徑的同學(xué)可以完全知道你寫了什么。

這就是HTTP面臨的第一個問題，這個問題通常被叫做“竊聽”或者“嗅探”，指的是和你在同一個網(wǎng)絡(luò)下或者是途徑的路由上的攻擊者可以偷窺到你傳輸?shù)膬?nèi)容。這是HTTPS要解決的第一個問題。這種問題通常是通過“加密”來解決的。從非常原始的角度來考慮，其實(shí)就是雙方約定一個暗號。用什么字母去替代什么字母之類的。不過考慮到互聯(lián)網(wǎng)每天有無數(shù)信息需要加密，這種原始的加密方法似乎不太適合。不過實(shí)際上方法也差不多，一般是采用一種叫做AES的算法來解決的。這種算法需要一個密鑰key來加密整個信息，加密和解密所需要使用的key是一樣的，所以這種加密一般也被稱為“對稱加密”。AES在數(shù)學(xué)上保證了，只要你使用的key足夠足夠足夠足夠的長，破解是幾乎不可能的。

我們先假設(shè)這種破解確實(shí)是不可能的，而且目前也確實(shí)沒有對AES本身能發(fā)動起有效的攻擊的案例出現(xiàn)。

我們再回到這個教室，你接著要傳小紙條，你把地址寫上后，把要傳輸?shù)膬?nèi)容用AES蹭蹭蹭加密了起來。剛準(zhǔn)備傳，問題來了。AES不是有一個key嗎？key怎么給目的地??？如果我把密鑰直接寫在紙條上，那么中間的人不依然可以解密嗎？在現(xiàn)實(shí)中你可以通過一些其它方法來把密鑰安全傳輸給目的地而不被其他人看見，但是在互聯(lián)網(wǎng)上，要想這么做難度就很大了，畢竟傳輸終究要經(jīng)過這些路由，所以要做加密，還得找一個更復(fù)雜的數(shù)學(xué)方法。

于是聰明的人們發(fā)明了一種更復(fù)雜的加密算法——非對稱加密。這種加密或許理解起來比較困難，這種加密指的是可以生成一對密鑰(k1,k2)。凡是k1加密的數(shù)據(jù)，k1自身不能解密，而需要k2才能解密；凡是k2加密的數(shù)據(jù)，k2不能解密，需要k1才能解密。這種算法事實(shí)上有很多，常用的是RSA，其基于的數(shù)學(xué)原理是兩個大素?cái)?shù)的乘積很容易算，而拿到這個乘積去算出是哪兩個素?cái)?shù)相乘就很復(fù)雜了。好在以目前的技術(shù)，分解大數(shù)的素因數(shù)確實(shí)比較困難，尤其是當(dāng)這個大數(shù)足夠大的時候（通常使用2的10次方個二進(jìn)制位這么大），就算是超級計(jì)算機(jī)解密也需要非常長的時間。

現(xiàn)在利用這種非對稱加密的方法，我們來設(shè)想一個場景。你繼續(xù)想要傳紙條，但是傳紙條之前你先準(zhǔn)備把接下來通訊的對稱加密密鑰給傳輸過去。于是你用RSA技術(shù)生成了一對k1、k2，你把k1用明文發(fā)送了出去，路經(jīng)有人或許會截取，但是沒有用，k1加密的數(shù)據(jù)需要用k2才能解密。而此時，k2在你自己的手里。k1送達(dá)目的地后，目的地的人會去準(zhǔn)備一個接下來用于對稱加密傳輸?shù)拿荑€key，然后用收到的k1把key加密了，把加密好的數(shù)據(jù)傳回來。路上的人就算截取到了，也解密不出key。等到了你自己手上，你用手上的k2把用k1加密的key解出來，現(xiàn)在全教室就只有你和你的目的地?fù)碛衚ey，你們就可以用AES算法進(jìn)行對稱加密的傳輸啦！這時候你和目的地的通訊將無法再被任何人竊聽！

當(dāng)然，這時候你可能會問兩個問題。

既然非對稱加密可以那么安全，為什么我們不直接用它來加密信息，而是去加密對稱加密的密鑰呢？

這是因?yàn)榉菍ΨQ加密的密碼對生成和加密的消耗時間比較長，為了節(jié)省雙方的計(jì)算時間，通常只用它來交換密鑰，而非直接用來傳輸數(shù)據(jù)。

使用非對稱加密是完全安全的嗎？

聽起來確實(shí)是挺安全的，但實(shí)際上，還有一種更惡劣的攻擊是這種方法無法防范的，這就是傳說中的“中間人攻擊”。我們繼續(xù)讓你坐在教室里傳小紙條?，F(xiàn)在你和目的地上途徑一個中間人，他有意想要知道你們的消息。由于這個描述比較復(fù)雜，我們將你稱為A，你的目的地稱為B，而中間人稱為M。當(dāng)你要和B完成第一次密鑰交換的時候，途徑了M。M知道你要進(jìn)行密鑰交換了，它把小紙條扣了下來，假裝自己是B，偽造了一個key，然后用你發(fā)來的k1加密了key發(fā)還給你，你以為你和B完成了密鑰交換，實(shí)際上你是和M完成了密鑰交換。同時M和B完成一次密鑰交換，讓B誤以為和你完成了密鑰交換?，F(xiàn)在，由A->B完整的加密，變成了A（加密連接1）->M（明文）->B（加密連接2）的情況了。這時候M依然可以知道A和B傳輸中的全部信息。

對于這種事，我們似乎很難找到一個解決方法來解決這個問題，除非我們能從源頭保證，你密鑰交換的對象是安全的。這時候我們就要認(rèn)識互聯(lián)網(wǎng)HTTPS和你傳紙條的微妙區(qū)別了。你傳紙條時，你和你的目的地的關(guān)系幾乎是對等的。而你訪問網(wǎng)站時，你訪問的對象通常是一個比較大的服務(wù)供應(yīng)商，他們有充沛的資源，也許可以證明他們的合法性。

這時候我們會引入一個第三方叫做CA。CA是一些非常權(quán)威的專門用于認(rèn)證一個網(wǎng)站合法性的組織。服務(wù)商可以向他們申請一個證書，使得他們建立安全連接時可以帶上CA的簽名。而CA的安全性由操作系統(tǒng)或?yàn)g覽器來認(rèn)證。你的Windows、Mac、Linux、Chrome、Safari等會在安裝時帶上一個他們認(rèn)為安全的CA證書列表。如果和你建立安全連接的人帶著這些人的簽名，那么認(rèn)為這個安全連接是安全的，沒有遭到中間人攻擊。

CA證書通常情況下是安全的。因?yàn)橐坏┠硞€CA頒發(fā)出的某個證書被用于了非法用途，瀏覽器和操作系統(tǒng)一般會通過更新將整個CA頒發(fā)過的全部證書全部視為不安全。這使得CA通常在頒發(fā)證書時是比較小心的。

所以通過對稱加密+非對稱加密+CA認(rèn)證這三個技術(shù)混合在一起，才使得HTTP的后面加上了一個S——Security。實(shí)際上HTTPS的協(xié)議比我這里描述的更復(fù)雜一些，我這里說的主要是基本的實(shí)現(xiàn)原理。因?yàn)槠渲腥魏我画h(huán)稍有閃失，就會使得整個加密都將變得不安全。這也是為什么HTTPS的加密協(xié)議從SSL1.0升級到SSL3.0再被TLS1.0現(xiàn)在被TLS1.2取代，其背后都是一環(huán)環(huán)細(xì)節(jié)上的修改，以防任何地方的閃失。

但即使如此，你的HTTPS盡可能的保證了你傳輸?shù)陌踩@種安全也不是絕對的。比如CA證書出了問題被用于了中間人攻擊，在短期內(nèi)，你的安全將會陷入直接的麻煩直到瀏覽器或操作系統(tǒng)重新更新了你的CA列表或者你手動調(diào)整了這個列表。但大多情況下不必杞人憂天，它基本上是安全的。

當(dāng)然了，路由也可以選擇直接丟包，它看不到的，也不讓你看到。

最新評論