前些天發現了一個巨牛的人工智能學習網站，通俗易懂，風趣幽默，忍不住分享一下給大家。點擊跳轉到教程。

關于加密

在解釋SSH、SSL與HTTPS協議之前我先介紹一下非對稱加密協議。在1976年以前，所有的加密都采用對稱加密，既A使用某種加密規則對信息加密，B收到信息后逆向加密規則解密數據。這通信方式產生了一個難以解決的問題：A如何安全的把加密規則通知B？

在1976年有兩位數學家提出了一個嶄新的非對加密的概念：


1.A生成一對兩把密鑰（公鑰和私鑰）。公鑰是公開的，任何人都可以獲得，私鑰則是保密的。
2.B獲取乙方的公鑰，然后用它對信息加密。
3.A得到加密后的信息，用私鑰解密。

受這個思路的啟發，三位數學家Rivest、Shamir 和 Adleman 設計了一種具體實現上面描述的非對稱加密的算法，以他們三個人的名字命名，就是目前在計算機領域應用非常廣泛的非對稱加密算法RSA加密算法。這樣網絡上傳輸的數據都經過公鑰加密，然后用私鑰解密，就算被第三方截獲也無法解密出原始數據。想深入理解非對稱加密解密的原理可以看這里。

雖然非對稱加密很安全很強大，但是它也有缺點，相對于對稱加密它計算量更大，計算時間更長。所以在大規模數據的安全通信場景中，普遍采用非對稱加密技術來交換對稱加密密鑰，之后的通信都采用對稱加密技術加密。

SSH

維基百科中對SSH協議的定義如下

Secure Shell（縮寫為SSH），由IETF的網絡工作小組（Network Working Group）所制定；SSH為一項創建在應用層和傳輸層基礎上的安全協議，為計算機上的Shell（殼層）提供安全的傳輸和使用環境。
傳統的網絡服務程序，如rsh、FTP、POP和Telnet其本質上都是不安全的；因為它們在網絡上用明文傳送數據、用戶帳號和用戶口令，很容易受到中間人（man-in-the-middle）攻擊方式的攻擊。就是存在另一個人或者一臺機器冒充真正的服務器接收用戶傳給服務器的數據，然后再冒充用戶把數據傳給真正的服務器。
而SSH是目前較可靠，專為遠程登錄會話和其他網絡服務提供安全性的協議。利用SSH協議可以有效防止遠程管理過程中的信息泄露問題。通過SSH可以對所有傳輸的數據進行加密，也能夠防止DNS欺騙和IP欺騙。
SSH之另一項優點為其傳輸的數據可以是經過壓縮的，所以可以加快傳輸的速度。SSH有很多功能，它既可以代替Telnet，又可以為FTP、POP、甚至為PPP提供一個安全的“通道”。

相信大家看了上面的段定義也是云里霧里。用最通俗的方式來解釋一下SSH。有這么一個場景：有一個服務器在互聯網的另一頭，你需要遠程登錄到服務器來執行一些命令配置這臺服務器。這個時候你和服務器之間就需要有數據通信。假設客戶端叫A，服務器叫B。

要實現通信，最簡單的想法就是，客戶端服務器之間建立一個TCP連接，這樣你的指令就可以通過TCP連接從A傳輸到B。再仔細想想，不對，A與B之間需要通信的數據中間經過了C、D、E、F等網絡路由器設備，這其中任何一個路由器被黑客攻破，你們之間的通信數據就毫無保留的被別人看到。

所以，你需要用一個密鑰把數據加密吧。這樣A和B之間的數據就算被第三方看到，他們也不知道內容是什么。可是這里又存在一個問題，A如何通知B（或者B如何通知A）它的密鑰是什么呢？要知道只要數據是在互聯網上傳輸，就有被截獲的可能。密鑰被截獲了，你就沒有秘密可言了。

現在我們需要考慮一個安全的方式來傳輸密鑰！讓我想想——非對稱加密！

A、B之間建立TCP連接
B生成一對公私密鑰
B把公鑰發送給A
A生成一個用于加密數據的密鑰K（既我們想通知給客戶端的密鑰，之后的數據通信都使用這個密鑰加密，這個密鑰不可讓第三方知道）
A把K用公鑰加密發送給B，B解密后，從此A、B之間的通信數據都用K密鑰進行加密和解密。

這樣假如中間的C、D、E截獲了A發給B的K密鑰內容的數據包，可是這個密鑰是用B服務器生成的公鑰加密過的，只有B服務器知道如何解密。于是我們的數據很安全了。。。

看起來很簡單不是嗎？一切大功告成。等等...如果黑客H埋伏在了A和B之間的某一個路由器上，他假冒B生成一對公私密鑰，然后把公鑰發送給A，這樣A與H之間就建成了一個加密通道，A把所有信息發送給H，H截獲A的信息，在假冒A與B通信。如此一來，A、B之間的通信就完全暴漏給了H，而A、B卻完全不知道，這就是有名的“中間人”攻擊。

為解決這個問題，SSH協議采用由人工判斷公鑰的fingerprint是否可信的方式。當使用ssh命令連接服務器時，命令行會提示如下信息:

The authenticity of host '168.30.9.213 (<no hostip for proxy command>)' can't be established.
RSA key fingerprint is 23:42:c1:e4:3f:d2:cc:37:1d:89:cb:e7:5d:be:5d:53.
Are you sure you want to continue connecting (yes/no)?

輸入yes之后才會連接到遠程服務器，同時這個信息會存儲到用戶的.ssh/known_hosts文件中，下次再登錄的時候，會檢查known_host文件，如果存在相同的公鑰信息，就不在提示用戶確認了。

這種認證方式假設想登陸服務器的用戶已經知道服務器公鑰（作為服務器的用戶他自然有渠道得知服務器公鑰）。fingerprint其實就代表公鑰，可以看成是公鑰的一個壓縮版。有了這個步驟，如果有中間人想冒充服務器B發送公鑰給A，它不可能生成一對和B生成的一樣的公私密鑰，他發送給A的公鑰必然與B服務器的不同，所以用戶就可以根據printfinger判斷所連接的服務器是否可信，有沒有被中間人冒充。

SSH的實現細節

上面只是粗略講解SSH的安全協議的設計思路，實際上SSH通信協議在安全通信過程中分了幾個階段，每個階段又細分了幾個步驟，具體的可參看SSH原理簡介。幾個主要階段如下：

協議協商階段
服務端認證階段
客戶端認證階段
數據傳輸階段

客戶端認證

這里我想單獨談談客戶端認證，因為對于使用linux遠程登錄功能的系統管理員來說能有直觀感覺的也就是是這個環節了。一般我們能接觸到的的認證方式有兩種：

密碼認證
Public Key認證

密碼認證很好理解，就是我們在登錄遠程linux服務器的時候提供用戶名和密碼？這里面稍微提示一下，在你的用戶名和密碼通過網絡傳輸給服務器之前，已經經過了服務器認證協商階段，這是一個安全的加密信道已經建立，所以你的用戶名和密碼都是加密后傳輸給服務器的，保證不會被第三方截獲。

每次登錄都要輸入密碼很麻煩，且密碼如果簡單的話可能還會被暴力破解。Public Key認證提供了一種更安全便捷的認證客戶端的方式。這個技術也用到了非對稱加密技術，由客戶端生成公私密鑰對，然后將公鑰保存在服務器上。認證的過程大體如下：

客戶端發起一個Public Key的認證請求，并發送RSA Key的模數作為標識符。（如果想深入了解RSA Key詳細 -->維基百科）
服務端檢查是否存在請求帳號的公鑰（Linux中存儲在~/.ssh/authorized_keys文件中），以及其擁有的訪問權限。如果沒有則斷開連接
服務端使用對應的公鑰對一個隨機的256位的字符串進行加密，并發送給客戶端
客戶端使用私鑰對字符串進行解密，并將其結合session id生成一個MD5值發送給服務端。*結合session id的目的是為了避免攻擊者采用重放攻擊（replay attack）。
服務端采用同樣的方式生成MD5值與客戶端返回的MD5值進行比較，完成對客戶端的認證。

為更廣大群眾設計的SSL與TLS

上面wiki上也有寫，SSH其實是專門為shell設計的一種通信協議，它垮了兩個網絡層（傳輸層和應用層）。通俗點講就是只有SSH客戶端，和SSH服務器端之間的通信才能使用這個協議，其他軟件服務無法使用它。但是其實我們非常需要一個通用的，建立在應用層之下的一個傳輸層安全協議，它的目標是建立一種對上層應用協議透明的，不管是HTTP、FTP、還是電子郵件協議或其他任何應用層協議都可以依賴的底層的可安全通信的傳輸層協議。

網景公司于1994年為解決上面的問題，設計了SSL（Secure Sockets Layer）協議的1.0版本，但并未發布，直到1996年發布SSL3.0之后，開始大規模應用于互聯網服務。可能很多人聽所過TLS（Transport Layer Security）。它相當于是SSL協議的一個后續版本，他是SSL經過IETF標準化之后的產物（詳細參考傳輸層安全協議，下文中所說的SSL協議也包括TSL）。

跟SSH相比SSL所面臨的問題要更復雜一些，上面我們提到，SSH協議通過人工鑒別Public Key的printfinger來判斷與之通信的服務器是否可信（不是偽裝的中間人）。可是SSL是為了整個互聯網上的所有客戶端與服務器之間通信而設計的，他們彼此之間不可能自己判斷通信的對方是否可信。那么如何解決這個問題呢？

在構思解決方案之前我先講一個概念數字簽名。。。。

想了一下，還是不寫了。。。阮老師的這篇blog對數字簽名解釋的非常到位，良心推薦，如果有不了解數字簽名概念的讀者，建議先看看阮老師的文章。

回到上面我們所要解決的問題，以瀏覽器和網站服務器之前的安全通信舉例，首先瀏覽器要求和某WEB服務器建立安全的SSL連接通道，這時需要服務器的公鑰用來加密瀏覽器生成的通信密鑰，發給WEB服務器，以確定通信密鑰。假如瀏覽器接受到一個公鑰，它如何知道這個公鑰確實是來自那個WEB服務器，而不是中間的某個攻擊者截獲了它的請求，假扮WEB服務器給它的假密鑰？瀏覽器總不能記錄所有可信任站點的公鑰吧。

解決問題的思路是這樣的，在SSL協議中引入了一種類似公共機關（類似于我國的國家公證處？）的概念，就是我們熟知的CA(數字證書認證機構)。它為瀏覽器發行一個叫數字證書的東西。這個東西大體上如下圖所示，其中比較重要的信息有：

對象的公開密鑰
數字簽名

有了數字證書，瀏覽器在建立SSL連接之前，并不只是簡單獲取服務器的公鑰，而從服務器獲取數字證書。數字證書里有服務器的公鑰，并且有CA給這個證書簽發的簽名。這個簽名其實是證書內容的摘要經過CA私鑰加密生成的。這樣瀏覽器得證書內容和摘要，并用CA的公鑰（每個瀏覽器都存儲著一些權威CA的公鑰）對數字簽名解密，也得到證書的摘要，比對兩個摘要如果相同，說明證書是真的，且未經過修改。信任問題就這么解決了，如果上面這段話不好理解的話，再次建議讀一讀阮老師的數字簽名是什么？。

原文見：https://www.jianshu.com/p/5e3f9dfd2cb4