SSL相關知識科普

一個天朗氣清的週末，決定看一下Composer的源碼，從安裝文件先看起，一路順暢，直到遇到了openssl_xxx()，什麼鬼啊這是，忽然回想起在系統上安裝軟件的時候常常出現SSL:xxxx的錯誤?他們之間究竟有什麼關係，聽說Https和ssl也有關係，媽耶，因而有了這篇科普文。

文章邏輯是按照筆者的思考問題的歷程寫下的，可能有些跳躍，你們多擔待。

文中大部份內容是經過維基百科和百度百科來的，可能本身有部分理解不對，環境你們提出指正。

什麼是OpenSSL

維基百科:OpenSSL是一個開放源代碼的軟件庫包，應用程序可使用這個包來進行安全通訊，避免竊聽，同時確認另外一端連線者的身份。

問題來了

1. 怎麼樣就是安全通訊了？
2. 都知道Https比Http安全，可是究竟安全在哪裏？
3. SSL是什麼東西？
4. SSL和TSL有什麼區別？

接下來，挨個來突破這些問題。

安全通訊

我曾經覺得的安全通訊

例子1

小明開發了一個多人博客網站，全部人均可以在上面發表文章，下載資源

例子2

小黑開發了一個多人博客網站，只容許登陸的用戶在上面發表文章，下載資源

以前我一直覺得，用戶認證的過程就是安全通訊的過程。: (

如下是英文版維基百科的定義，中文版的維基百科和百度百科沒有找到相關的定義。

Secure communication is when two entities are communicating and do not want a third party to listen in.

中文：安全通訊是指兩個實體正在通訊而且不但願第三方監聽。
複製代碼

爲了達到上述的目標，就須要**以不易被竊聽或攔截**的方式進行通訊。

維基百科中還有一段話，附上

Other than spoken face-to-face communication with no possible eavesdropper, it is probably safe to say that no communication is guaranteed secure in this sense, although practical obstacles such as legislation, resources, technical issues (interception and encryption), and the sheer volume of communication serve to limit surveillance.

中文大體意思：除了無法監聽面對面交流，理論上其餘的手段只能限制監聽。
複製代碼

Tips：有興趣能夠閱讀如下維基百科原文 en.wikipedia.org/wiki/Secure… 有一些關於安全的討論。

OK！看完百科的定義，咱們能夠get一些關鍵詞：監聽和攔截，安全通訊，就是圍繞這兩個概念展開的。

竊聽

關於竊聽，有兩個問題。

1. 竊聽的定義
2. 怎麼作到竊聽

先來看問題1，計算機中竊聽，一般指的是網絡竊聽，接下來，有請萬能的維基百科。

在電腦網絡中，竊聽攻擊是在網絡層，利用軟件，收集其餘電腦送出的封包（Packet），分析其內容，以取得其中的資訊。
複製代碼

get到關鍵詞，網絡層和Packet，對於這兩個概念不熟悉的同窗，請出門右轉(點擊這裏)

網絡層提供路由與尋址功能，若是在這一層動手腳，那麼源IP+端口/目標IP+端口/Packet咱們在這一層中均可以獲取到，解析Packet，就能夠獲取到咱們所發送的內容。

再來看問題2，理論上，大部分的公共wifi均可以被竊聽，運營商的基站，甚至是一些代理。原理也比較簡單，附上一個教程github

攔截

不贅述，附上百科

理論上，咱們是沒法避免竊聽的，由於咱們開發的應用是在應用層，遠在網絡層的攻擊，咱們是沒法避免的。咱們能作的，就是即便數據被監聽了，他沒法解析出來他想要的數據。

Http與Https

Http與Https的區別就是，Https將Http明文傳輸的協議進行加密，即便信息被截取，也沒法破解。

Https使用的加密方式是對稱加密

配置過Https的都知道，配置流程中，只須要申請pem和key文件(CA證書)，在nginx中配置規則，開啓443端口便可。

那麼問題來了：

1. 客戶端(瀏覽器/app)是根據什麼規則加密的(注意:客戶端是沒有任何配置的)
2. 服務器是根據什麼規則解密的
3. 怎麼保證中間人竊聽到數據沒法解密呢

咱們去看Https的維基百科(長文預警)。

HTTPS的主要思想是在不安全的網絡上建立一安全信道，並可在使用適當的加密包和服務器證書可被驗證且可被信任時，對竊聽和中間人攻擊提供合理的防禦。

HTTPS的信任繼承基於預先安裝在瀏覽器中的證書頒發機構（如Symantec、Comodo、GoDaddy和GlobalSign等）（意即「我信任證書頒發機構告訴我應該信任的」）。所以，一個到某網站的HTTPS鏈接可被信任，當且僅當：
- 用戶相信他們的瀏覽器正確實現了HTTPS且安裝了正確的證書頒發機構；
- 用戶相信證書頒發機構僅信任合法的網站；
- 被訪問的網站提供了一個有效的證書，意即，它是由一個被信任的證書頒發機構簽發的（大部分瀏覽器會對無效的證書發出警告）；
- 該證書正確地驗證了被訪問的網站（如，訪問https://example.com時收到了給example.com而不是其它組織的證書）；
- 互聯網上相關的節點是值得信任的，或者用戶相信本協議的加密層（TLS或SSL）不能被竊聽者破壞。
複製代碼

關鍵詞提取：預先安裝在瀏覽器中的證書頒發機構

也就是說中，預先安裝了一個叫證書頒發機構的東西，想知道這個東西有什麼用，咱們就須要瞭解客戶端的證書頒發機構和服務器端(CA證書)的工做原理(SSL握手過程)，如下內容來自百度百科：

1. 客戶端的瀏覽器向服務器傳送客戶端SSL 協議的版本號，加密算法的種類，產生的隨機數，以及其餘服務器和客戶端之間通信所須要的各類信息。
2. 服務器向客戶端傳送SSL 協議的版本號，加密算法的種類，隨機數以及其餘相關信息，同時服務器還將向客戶端傳送本身的證書。
3. 客戶利用服務器傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過時，發行服務器證書的CA 是否可靠，發行者證書的公鑰可否正確解開服務器證書的「發行者的數字簽名」，服務器證書上的域名是否和服務器的實際域名相匹配。若是合法性驗證沒有經過，通信將斷開；若是合法性驗證經過，將繼續進行第四步
4. 用戶端隨機產生一個用於後面通信的「對稱密碼」，而後用服務器的公鑰（服務器的公鑰從步驟②中的服務器的證書中得到）對其加密，而後將加密後的「預主密碼」傳給服務器。
5. 若是服務器要求客戶的身份認證（在握手過程當中爲可選），用戶能夠創建一個隨機數而後對其進行數據簽名，將這個含有簽名的隨機數和客戶本身的證書以及加密過的「預主密碼」一塊兒傳給服務器。
6. 若是服務器要求客戶的身份認證，服務器必須檢驗客戶證書和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，爲客戶提供證書的CA 是否可靠，發行CA 的公鑰可否正確解開客戶證書的發行CA 的數字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗若是沒有經過，通信馬上中斷；若是驗證經過，服務器將用本身的私鑰解開加密的「預主密碼」，而後執行一系列步驟來產生主通信密碼（客戶端也將經過一樣的方法產生相同的主通信密碼）。
7. 服務器和客戶端用相同的主密碼即「通話密碼」，一個對稱密鑰用於SSL 協議的安全數據通信的加解密通信。同時在SSL 通信過程當中還要完成數據通信的完整性，防止數據通信中的任何變化。
8. 客戶端向服務器端發出信息，指明後面的數據通信將使用的步驟⑦中的主密碼爲對稱密鑰，同時通知服務器客戶端的握手過程結束。
9. 服務器向客戶端發出信息，指明後面的數據通信將使用的步驟⑦中的主密碼爲對稱密鑰，同時通知客戶端服務器端的握手過程結束。
10. SSL 的握手部分結束，SSL 安全通道的數據通信開始，客戶和服務器開始使用相同的對稱密鑰進行數據通信，同時進行通信完整性的檢驗。

感嘆一聲，大寫的NB！！！

不理解上述步驟的，看一下個人簡化版(C客戶端，S服務器)：

1. C端與S端驗證對方證書的合法性
2. C端產生一個隨機數1，用S端公匙加密，產生隨機密碼1
3. S端用本身的私匙解析隨機密碼1，獲取隨機數1，此時，C端與S端使用相同的方式對隨機數1進行運算獲得一個通信密碼
4. C端與S端使用相同的通信密碼對數據進行對稱加密

什麼是SSL

哈哈哈，上面不當心已經解釋過SSL創建鏈接的過程了。這裏只簡單說幾點：

1. SSL是一種安全協議
2. SSL針對HTTP進行了特別設計，是的HTTP協議可以在SSL運行
3. HTTPS是HTTP+SSL
4. HTTPS運行在443端口，HTTP運行在80端口
5. HTTPS須要申請證書CA
6. 在我寫的SSL簡化握手步驟中的123步，爲何須要這種方式來生成對稱加密的密碼，有如下幾點緣由：
   • 若是C與S使用默認的密匙，那麼這個密匙一旦被別人獲取到，那麼加密數據就會被解析出來
   • 若是使用非堆成加密的方式，若是服務端經過私匙加密的數據被截取到的話，也是會被加戲出來的，由於公匙是公開的，並且非對稱加密消耗的時間長，而且公匙一旦泄露，也有風險

TSL 與 SSL的區別

SSL是協議層安全性協議 TSL是傳輸層安全性協議

認證方式不一樣

TSL使用X.509認證(看到這裏，終於知道composer安裝文件中爲何大量出現openssl_x509_parse，媽耶) SSL認證方式前面已經提到

工做地點不一樣

TLS工做在傳輸層，應用層協議能透明地運行在TLS協議之上

OpenSSL與php的關係

php中的openssl_xxx()系列的函數，只是php的一個openssl的擴展庫，封裝了大量的關於加密解密方面的函數。

openssl是ssl協議的相關實現。

結束。

Life is fantastic！！！