SSL/TLS工做原理

之前已經介紹過HTTP協議和HTTPS協議的區別，此次就來了解一下HTTPS協議的加密原理。

爲了保證網絡通訊的安全性，須要對網絡上傳遞的數據進行加密。如今主流的加密方法就是SSL (Secure Socket Layer)，TLS (Transport Layer Security)。後者比前者要新一些，不過在不少場合仍是用SSL指代SSL和TLS。先來回顧一下網絡通訊加密的發展過程，假設A和B之間要網絡通訊。

上古時代
隨着時代的發展，漸漸的有了一類人---C。C不只會監聽A和B之間的網絡數據，還會攔截A和B之間的數據，僞造以後再發給A或者B，進而欺騙A和B。C就是中間人攻擊（Man In The Middle Attack）。爲了應對C的攻擊，A和B開始對本身的數據進行加密。A和B會使用一個共享的密鑰，A在發送數據以前，用這個密鑰對數據加密。B在收到數據以後，用這個密鑰對數據解密。由於加密解密用的是同一個密鑰，因此這裏的加密算法稱爲對稱加密算法。

在1981年，DES（Data Encryption Standard）被提出，這是一種對稱加密算法。DES使用一個56bit的密鑰，來完成數據的加解密。儘管56bit看起來有點短，但時間畢竟是在上古時代，56bit已經夠用了。就這樣，網絡數據的加密開始了。由於採用了DES，A和B如今不用擔憂數據被C攔截了。由於就算C攔截了，也只能獲取加密以後的數據， 沒有密鑰就沒有辦法獲取原始數據。可是A和B之間又有了一個新的問題，他們須要一個共享的56bit密鑰，而且這個密鑰必定要保持私密，不然被C拿到了，就沒有加密的意義了。首先AB不能經過網絡來傳遞密鑰，由於密鑰肯定之前，全部的網絡通訊都是不安全。若是經過網絡傳遞密鑰，密鑰有可能被攔截。攔截了就沒有加密的意義了。爲了安全，A和B只能先見一面，私下商量好密鑰，這樣C就沒辦法獲取密鑰。若是由於任何緣由，以前的密鑰泄露了，那麼AB還得再見一面，從新商量一個密鑰。如今A和B之間，最私密的信息就是這個密鑰了，只要保證密鑰的安全，那麼AB之間整個網絡通訊都是安全的。

中古時代
A和B當心的保護着密鑰，不讓C知道。可是道高一尺，魔高一丈。隨着技術的發展，計算機速度變得很快，快到能夠經過暴力破解的方法來解密通過DES加密的信息。不就是56bit的密鑰嗎？C找了一個好點的計算機，嘗試每個可能的值，這樣總能找到一個密鑰破解A和B之間的加密信息。倒不是說DES在提出時沒有考慮過這種狀況，只是在上古時代，計算機沒這麼快，破解56bit的密鑰須要的時間很是長。可是如今是中古時代，可能只須要幾天就能夠破解56bit的密鑰。爲了應對這個狀況，新的協議被提出，例如triple-DES（最長168bit的密鑰），AES（最高256bit的密鑰）。通過這些改進，至少在能夠預見的將來，計算機是沒有辦法在有限的時間內，暴力破解這個長度的密鑰。因此，在中古時代，將對稱加密算法的密鑰長度變長，來應對中間人攻擊。可是A和B仍是須要見面商量一個密鑰。

現代
非對稱加密

時間到了現代。網絡通訊變得十分發達，A不僅與B通訊，還同時還跟其餘10000我的進行網絡通訊。A不可能每一個人都跑去跟他們見個面，商量一個密鑰。

因此一種新的加密算法被提出，這就是非對稱加密算法。非對稱加密使用兩個密鑰，一個是public key，一個是private key。經過一個特殊的數學算法，使得數據的加密和解密使用不一樣的密鑰。由於用的是不一樣的密鑰，因此稱爲非對稱加密。非對稱加密最著名的是RSA算法，這是以其發明者Rivest, Shamir 和Adleman命名。非對稱加密算法裏面的public key和private key在數學上是相關的，這樣才能用一個加密，用另外一個解密。不過，儘管是相關的，但以現有的數學算法，又沒有辦法從一個密鑰，算出另外一個密鑰。

非對稱加密的好處在於，如今A能夠保留private key，經過網絡傳遞public key。這樣，就算public key被C攔截了，由於沒有private key，C仍是沒有辦法完成信息的破解。既然不怕C知道public key，那如今A和B不用再見面商量密鑰，直接經過網絡傳遞public key就行。

具體在使用中，A和B都各有一個public key和一個private key，這些key根據相應的算法已經生成好了。private key只保留在各自的本地，public key傳給對方。A要給B發送網絡數據，那麼A先使用本身的private key（只有A知道）加密數據的hash值，以後再用B的public key加密數據。以後，A將加密的hash值和加密的數據再加一些其餘的信息，發送給B。B收到了以後，先用本身的private key（只有B知道）解密數據，本地運算一個hash值，以後用A的public key解密hash值，對比兩個hash值，以檢驗數據的完整性。

在這個過程當中，總共有4個密鑰，分別是A的public/private key，和B的public/private key。若是B的解密結果符合預期，那麼至少能夠證實，這個信息只有B能獲取，由於B的private key參與瞭解密，而B的private key其餘人都不知道。而且，這個信息是來自A，而不是C僞造的，由於A的public key參與瞭解密。一切看起來彷佛很美好。

非對稱加密的安全隱患

可是在一切的最開始，A和B要經過網絡交換public key。若是C在中間攔截了呢？假設有這種狀況，C攔截了A和B的public key，又分別用本身的public key發給A和B。A和B並不知道，他們還覺得這個public key來自對方。當A給B發消息時，A先用本身的private key加密數據的hash值，以後用C傳來的假的public key加密數據，再發出去。C攔截到以後，先用C本身的private key解密數據，C就獲取了A的原始信息！以後，C能夠篡改數據內容，再用本身的private key加密數據的hash值，用以前攔截的B的public key加密數據，再發給B。B收到之後，先用本身的private key解密數據，再用C傳來的假public key解密hash值，發現匹配。這樣，B收到了一條來自C的假的信息，可是B還覺得信息來自於A。中間人攻擊仍然可能存在！

完了，一切都崩了，加密搞的這麼複雜，竟然還不能保證網絡數據的安全。回顧一下，問題出就出在最開始經過網絡交換public key。看起來爲了保證public key不被攔截，A和B彷佛仍是要見一面，交換一下public key。這一下就回到了上古時代。

不過，雖然A和B如今仍是要見一面，但見面的實質已經變了。在上古時代，見面是爲了商量一個密鑰，密鑰的內容很重要，不能讓別人知道密鑰的內容。而在現代，見面是爲了確認public key的真實性，public key的內容是能夠公開的。

那若是有其餘辦法能保證public key的真實性，A和B是能夠不用見面交換public key的。

CA

現實中，經過CA（Certificate Authority）來保證public key的真實性。CA也是基於非對稱加密算法來工做。有了CA，B會先把本身的public key（和一些其餘信息）交給CA。CA用本身的private key加密這些數據，加密完的數據稱爲B的數字證書。如今B要向A傳遞public key，B傳遞的是CA加密以後的數字證書。A收到之後，會經過CA發佈的CA證書（包含了CA的public key），來解密B的數字證書，從而得到B的public key。

可是等等，A怎麼確保CA證書不被劫持。C徹底能夠把一個假的CA證書發給A，進而欺騙A。CA的大殺器就是，CA把本身的CA證書集成在了瀏覽器和操做系統裏面。A拿到瀏覽器或者操做系統的時候，已經有了CA證書，沒有必要經過網絡獲取，那天然也不存在劫持的問題。

如今A和B都有了CA認證的數字證書。在交換public key的階段，直接交換彼此的數字證書就行。而中間人C，仍是能夠攔截A和B的public key，也能夠用CA證書解密得到A和B的public key。可是，C沒有辦法僞造public key了。由於C不在CA體系裏面，C沒有CA的private key，因此C是沒有辦法僞造出一個能夠經過CA認證的數字證書。若是不能經過CA認證，A和B天然也不會相信這個僞造的證書。因此，採用CA認證之後，A和B的public key的真實性獲得了保證，A和B能夠經過網絡交換public key（實際是被CA加密以後的數字證書）。

除非有種狀況，A內置的CA證書被篡改了，例如A使用了盜版的系統，「優化」了的非官方瀏覽器，或者被病毒攻擊了，那這個時候，A有可能會承認非CA認證的數字證書，C就有機會發起中間人攻擊。因此，用正版至少是安全的。

實際使用

非對稱加密算法比對稱加密算法要複雜的多，處理起來也要慢得多。若是全部的網絡數據都用非對稱加密算法來加密，那效率會很低。因此在實際中，非對稱加密只會用來傳遞一條信息，那就是用於對稱加密的密鑰。當用於對稱加密的密鑰肯定了，A和B仍是經過對稱加密算法進行網絡通訊。這樣，既保證了網絡通訊的安全性，又不影響效率，A和B也不用見面商量密鑰了。

因此，在現代，A和B之間要進行安全，省心的網絡通訊，須要通過如下幾個步驟

經過CA體系交換public key
經過非對稱加密算法，交換用於對稱加密的密鑰
經過對稱加密算法，加密正常的網絡通訊
這基本就是SSL/TLS的工做過程了。

HTTPS

HTTPS全稱是HTTP over SSL，也就是經過SSL/TLS加密HTTP數據，這或許是SSL最普遍的應用。

前面提到了CA做爲一個公證機構，能確保數字證書的真實性。可是在實際使用中，CA認證通常是要收費的，普通人不會去作CA認證，進而得到屬於本身的數字證書。更多的是，一些大的機構，例如銀行，網店，金融機構，它們去得到本身的數字證書。那這種狀況如何保證網絡通訊的安全呢？

這些機構獲取到CA授予的數字證書以後，將數字證書加到本身的web服務器上。當用戶要去訪問它們的網頁，例如https://domain.com，會通過下圖所示的步驟。

用戶向web服務器發起一個安全鏈接的請求
服務器返回通過CA認證的數字證書，證書裏面包含了服務器的public key
用戶拿到數字證書，用本身瀏覽器內置的CA證書解密獲得服務器的public key
用戶用服務器的public key加密一個用於接下來的對稱加密算法的密鑰，傳給web服務器
由於只有服務器有private key能夠解密，因此不用擔憂中間人攔截這個加密的密鑰
服務器拿到這個加密的密鑰，解密獲取密鑰，再使用對稱加密算法，和用戶完成接下來的網絡通訊
如今用戶知道本身訪問的網站是正規的網站，不然用戶瀏覽器會報錯說不能用CA證書解析。服務器經過CA授予的數字證書自證了身份。但，這裏的安全隱患在於，服務器怎麼知道訪問者就是真用戶呢？以前介紹的雙向認證是能夠經過數字證書驗明用戶的正身，如今用戶爲了省錢沒有數字證書。這種狀況下通常是經過用戶名密碼來確認用戶。因此，你們要保管好本身的密碼。
本文轉載自：https://zhuanlan.zhihu.com/p/36981565