轉(zhuǎn)自[http://heckpsi.com/archives/986]
每當我們討論到信息安全的時候罐农，我們最長接觸到的信息加密傳輸?shù)姆绞侥^于 HTTPS 了，當我們?yōu)g覽器地址欄閃現(xiàn)出綠色時幸缕，就代表著這個網(wǎng)站支持 HTTPS 的加密信息傳輸方式，并且你與它的連接確實被加密了晰韵。但是 HTTPS 并不是一個單一的東西发乔，它知識我們常見的 HTTP 協(xié)議和某個加密協(xié)議的一個混合，這個加密協(xié)議通常會是 TLS雪猪。那么 HTTPS 為什么安全呢栏尚？其實我們需要先考慮 HTTP 為什么不安全。
假設(shè)你坐在一個教室里只恨，你現(xiàn)在非常想把某個信息傳遞給教室里的另一個人译仗，一般來說，會選擇官觅，傳紙條纵菌。傳紙條這個比喻其實非常正確，這就是互聯(lián)網(wǎng)的一個基礎(chǔ)協(xié)議 TCP/IP 協(xié)議基本的工作模式休涤。而通常咱圆，HTTP 協(xié)議的數(shù)據(jù)是使用 TCP/IP 協(xié)議進行發(fā)送的。HTTP 指的是你在紙條上寫明你要傳送的目的地是哪個同學的坐位，然后再是要傳遞的內(nèi)容闷堡。途徑的同學拿到紙條后根據(jù)紙條上顯示的地址依次傳過去就好了隘膘。這樣要面臨的第一個問題就是：途徑的同學可以完全知道你寫了什么。
這就是 HTTP 面臨的第一個問題杠览，這個問題通常被叫做“竊聽” 或者 “嗅探” 弯菊，指的是和你在同一個網(wǎng)絡(luò)下或者是途徑的路由上的攻擊者可以偷窺到你傳輸?shù)膬?nèi)容。這是 HTTPS 要解決的第一個問題踱阿。這種問題通常是通過“加密”來解決的管钳。從非常原始的角度來考慮，其實就是雙方約定一個暗號软舌。用什么字母去替代什么字母之類的才漆。不過考慮到互聯(lián)網(wǎng)每天有無數(shù)信息需要加密，這種原始的加密方法似乎不太適合佛点。不過實際上方法也差不多醇滥，一般是采用一種叫做 AES 的算法來解決的。這種算法需要一個 密鑰 key 來加密整個信息超营，加密和解密所需要使用的 key 是一樣的鸳玩，所以這種加密一般也被稱為“對稱加密”。AES 在數(shù)學上保證了演闭，只要你使用的 key 足夠足夠足夠足夠的長不跟，破解是幾乎不可能的。
我們先假設(shè)這種破解確實是不可能的米碰，而且目前也確實沒有對 AES 本身能發(fā)動起有效的攻擊的案例出現(xiàn)窝革。
我們再回到這個教室，你接著要傳小紙條吕座，你把地址寫上后虐译，把要傳輸?shù)膬?nèi)容用 AES 蹭蹭蹭加密了起來。剛準備傳米诉，問題來了菱蔬。AES 不是有一個 key 嗎？key 怎么給目的地笆仿隆？如果我把密鑰直接寫在紙條上魏身，那么中間的人不依然可以解密嗎惊橱？在現(xiàn)實中你可以通過一些其它方法來把密鑰安全傳輸給目的地而不被其他人看見，但是在互聯(lián)網(wǎng)上箭昵，要想這么做難度就很大了税朴，畢竟傳輸終究要經(jīng)過這些路由，所以要做加密，還得找一個更復(fù)雜的數(shù)學方法正林。
于是聰明的人們發(fā)明了一種更復(fù)雜的加密算法——非對稱加密泡一。這種加密或許理解起來比較困難，這種加密指的是可以生成一對密鑰 (k1, k2)觅廓。凡是 k1 加密的數(shù)據(jù)鼻忠，k1 自身不能解密，而需要 k2 才能解密杈绸；凡是 k2 加密的數(shù)據(jù)帖蔓，k2 不能解密，需要 k1 才能解密瞳脓。這種算法事實上有很多塑娇，常用的是 RSA，其基于的數(shù)學原理是兩個大素數(shù)的乘積很容易算劫侧，而拿到這個乘積去算出是哪兩個素數(shù)相乘就很復(fù)雜了埋酬。好在以目前的技術(shù)，分解大數(shù)的素因數(shù)確實比較困難烧栋，尤其是當這個大數(shù)足夠大的時候（通常使用2的10次方個二進制位這么大）奇瘦，就算是超級計算機解密也需要非常長的時間。
現(xiàn)在利用這種非對稱加密的方法劲弦，我們來設(shè)想一個場景耳标。你繼續(xù)想要傳紙條，但是傳紙條之前你先準備把接下來通訊的對稱加密密鑰給傳輸過去邑跪。于是你用 RSA 技術(shù)生成了一對 k1次坡、k2，你把 k1 用明文發(fā)送了出去画畅，路經(jīng)有人或許會截取砸琅，但是沒有用，k1 加密的數(shù)據(jù)需要用 k2 才能解密轴踱。而此時症脂，k2 在你自己的手里。k1 送達目的地后淫僻，目的地的人會去準備一個接下來用于對稱加密傳輸?shù)拿荑€ key诱篷，然后用收到的 k1 把 key 加密了，把加密好的數(shù)據(jù)傳回來雳灵。路上的人就算截取到了棕所，也解密不出 key。等到了你自己手上悯辙，你用手上的 k2 把用 k1 加密的 key 解出來琳省，現(xiàn)在全教室就只有你和你的目的地擁有 key迎吵，你們就可以用 AES 算法進行對稱加密的傳輸啦！這時候你和目的地的通訊將無法再被任何人竊聽针贬！
當然击费，這時候你可能會問兩個問題。
既然 非對稱加密 可以那么安全桦他，為什么我們不直接用它來加密信息蔫巩，而是去加密 對稱加密 的密鑰呢？
這是因為 非對稱加密 的密碼對生成和加密的消耗時間比較長瞬铸，為了節(jié)省雙方的計算時間批幌，通常只用它來交換密鑰，而非直接用來傳輸數(shù)據(jù)嗓节。
使用 非對稱加密 是完全安全的嗎荧缘？
聽起來確實是挺安全的，但實際上拦宣，還有一種更惡劣的攻擊是這種方法無法防范的截粗，這就是傳說中的“中間人攻擊”。我們繼續(xù)讓你坐在教室里傳小紙條⊥宜恚現(xiàn)在你和目的地上途徑一個中間人绸罗，他有意想要知道你們的消息。由于這個描述比較復(fù)雜豆瘫，我們將你稱為 A珊蟀，你的目的地稱為 B，而中間人稱為 M外驱。當你要和 B 完成第一次密鑰交換的時候育灸，途徑了 M。M 知道你要進行密鑰交換了昵宇，它把小紙條扣了下來磅崭，假裝自己是 B，偽造了一個 key 瓦哎，然后用你發(fā)來的 k1 加密了 key 發(fā)還給你砸喻，你以為你和 B 完成了密鑰交換，實際上你是和 M 完成了密鑰交換蒋譬。同時 M 和 B 完成一次密鑰交換割岛，讓 B 誤以為和你完成了密鑰交換。現(xiàn)在羡铲，由 A -> B完整的加密蜂桶，變成了 A（加密連接1） -> M（明文）->B（加密連接2）的情況了。這時候 M 依然可以知道 A 和 B 傳輸中的全部信息也切。
對于這種事扑媚，我們似乎很難找到一個解決方法來解決這個問題，除非我們能從源頭保證雷恃，你密鑰交換的對象是安全的疆股。這時候我們就要認識互聯(lián)網(wǎng) HTTPS 和你傳紙條的微妙區(qū)別了。你傳紙條時倒槐，你和你的目的地的關(guān)系幾乎是對等的旬痹。而你訪問網(wǎng)站時，你訪問的對象通常是一個比較大的服務(wù)供應(yīng)商讨越，他們有充沛的資源两残，也許可以證明他們的合法性。
這時候我們會引入一個第三方叫做 CA把跨。CA 是一些非常權(quán)威的專門用于認證一個網(wǎng)站合法性的組織人弓。服務(wù)商可以向他們申請一個證書，使得他們建立安全連接時可以帶上 CA 的簽名着逐。而 CA 的安全性由操作系統(tǒng)或瀏覽器來認證崔赌。你的 Windows、Mac耸别、Linux健芭、Chrome、Safari 等會在安裝時帶上一個他們認為安全的 CA 證書列表秀姐。如果和你建立安全連接的人帶著這些人的簽名慈迈，那么認為這個安全連接是安全的，沒有遭到中間人攻擊省有。
CA 證書通常情況下是安全的痒留。因為一旦某個 CA 頒發(fā)出的某個證書被用于了非法用途，瀏覽器和操作系統(tǒng)一般會通過更新將整個 CA 頒發(fā)過的全部證書全部視為不安全锥咸。這使得 CA 通常在頒發(fā)證書時是比較小心的狭瞎。
所以通過 對稱加密 + 非對稱加密 + CA認證 這三個技術(shù)混合在一起，才使得 HTTP 的后面加上了一個 S —— Security搏予。實際上 HTTPS 的協(xié)議比我這里描述的更復(fù)雜一些熊锭，我這里說的主要是基本的實現(xiàn)原理。因為其中任何一環(huán)稍有閃失雪侥，就會使得整個加密都將變得不安全碗殷。這也是為什么 HTTPS 的加密協(xié)議從SSL 1.0 升級到 SSL 3.0 再被 TLS 1.0 現(xiàn)在被 TLS 1.2 取代，其背后都是一環(huán)環(huán)細節(jié)上的修改速缨，以防任何地方的閃失锌妻。
但即使如此，你的 HTTPS 盡可能的保證了你傳輸?shù)陌踩@種安全也不是絕對的仿粹。比如 CA 證書出了問題被用于了中間人攻擊搁吓，在短期內(nèi)，你的安全將會陷入直接的麻煩直到瀏覽器或操作系統(tǒng)重新更新了你的 CA 列表或者你手動調(diào)整了這個列表吭历。但大多情況下不必杞人憂天堕仔，它基本上是安全的。
當然了晌区，路由也可以選擇直接丟包摩骨，它看不到的，也不讓你看到朗若。
