對於一般的開發人員來說，很少需要對安全領域內的基礎技術進行深入的研究，但是鑑於日常系統開發中遇到的各種安全相關的問題，熟悉和了解這些安全技術的基本原理和使用場景還是非常必要的。本文將對非對稱加密、數字摘要、數字簽名、數字證書、SSL、HTTPS等這些安全領域內的技術進行一番簡要的介紹，解釋他們之間的關係，同時補充一些周邊話題。
0. 概覽--常用安全技術及其之間的關聯
安全領域的技術衆多，但是歸根結底，他們都是爲了保障如下三個方面：
1）認證用戶和服務器，確保數據發送到正確的客戶機和服務器
2）加密數據以防止數據中途被竊取
3）維護數據的完整性，確保數據在傳輸過程中不被改變。
在我們正式開始對每一項技術進行介紹之前，讓我們先有一個宏觀的認識，下圖羅列我們將要涉及的安全技術以及它們之間的關聯。
圖1.安全技術堆棧
1. 從非對稱密鑰加密與數字摘要技術談起。
1.1 什麼是“非對稱密鑰加解密”技術
對於一份數據，通過一種算法，基於傳入的密鑰(一串由數字或字符組成的字符串,也稱“key”），將明文數據轉換成了不可閱讀的密文，這是衆所周知的“加密”，同樣的，密文到達目的地後，需要再以相應的算法，配合一個密鑰，將密文再解密成明文，這就是“解密”。如果加密和解密使用的是同一個密鑰,那麼這就是“對稱密鑰加解密”（最常見的對稱加密算法是DES）。如果加密和解密使用的是兩個不同的密鑰，那麼這就是“非對稱密鑰加解密”（最常用的非對稱加密算法是RSA）。這兩個不同的密鑰一個叫作公開密鑰（publickey）另一個叫私有密鑰（privatekey），公開密鑰對外公開，任何人均可獲取，而私有密鑰則由自己保存，其實公鑰和私鑰並沒有什麼不同之處，公鑰之所以成爲公鑰是因爲它會被公開出來，產生任意份拷貝，供任何人獲取，而只有服務主機持有唯一的一份私鑰，從這種分發模式上看，我們不難看出其中的用意，這種分發模式實際上是Web站點多客戶端(瀏覽器)與單一服務器的網絡拓撲所決定的，多客戶端意味着密鑰能被複制和公開獲取，單一服務器意味着密鑰被嚴格控制，只能由本服務器持有，這實際上也是後面要提到的之所以能通過數據證書確定信任主機的重要原因之一。如果我們跳出web站點的拓撲環境，其實就沒有什麼公鑰與私鑰之分了，比如，對於那些使用以密鑰爲身份認證的SSH主機，往往是爲每一個用戶單獨生成一個私鑰分發給他們自己保存，SSH主機會保存一份公鑰，公鑰私鑰各有一份，都不會公開傳播。
1.2 什麼是“數字摘要“
這個非常簡單，我們在下載文件的時候經常會看到有的下載站點也提供下載文件的“數字摘要“，供下載者驗證下載後的文件是否完整，或者說是否和服務器上的文件”一模一樣“。其實，數字摘要就是採用單項Hash函數將需要加密的明文“摘要”成一串固定長度（128位）的密文，這一串密文又稱爲數字指紋，它有固定的長度，而且不同的明文摘要成密文，其結果總是不同的，兒同樣的明文其摘要必定一致。 因此，“數字摘要“叫”數字指紋“可能會更貼切一些。“數字摘要“是https能確保數據完整性和防篡改的根本原因。
2. 數字簽名--水到渠成的技術
讓我們來看看有了“非對稱密鑰加解密”和“數字摘要“兩項技術之後，我們能做些什麼呢？假如發送方想把一份報文發送給接收方，在發送報文前，發送方用一個哈希函數從報文文本中生成報文摘要,然後用自己的私人密鑰對這個摘要進行加密，這個加密後的摘要將作爲報文的”簽名“和報文一起發送給接收方，接收方首先用與發送方一樣的哈希函數從接收到的原始報文中計算出報文摘要，接着再用發送方的公用密鑰來對報文附加的數字簽名進行解密，如果這兩個摘要相同、那麼接收方就能確認報文是從發送方發送且沒有被遺漏和修改過！這就是結合“非對稱密鑰加解密”和“數字摘要“技術所能做的事情，這也就是人們所說的“數字簽名”技術。在這個過程中，對傳送數據生成摘要並使用私鑰進行加密地過程就是生成”數字簽名“的過程，經過加密的數字摘要，就是人們所說的”數字簽名“！
數字簽名技術就是對“非對稱密鑰加解密”和“數字摘要“兩項技術的應用，它將摘要信息用發送者的私鑰加密，與原文一起傳送給接收者。接收者只有用發送者的公鑰才能解密被加密的摘要信息，然後用HASH函數對收到的原文產生一個摘要信息，與解密的摘要信息對比。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數字簽名能夠驗證信息的完整性。(注意，數字簽名只能驗證數據的完整性，數據本身是否加密不屬於數字簽名的控制範圍)
綜上所述，數字簽名有兩種功效：一是能確定消息確實是由發送方簽名並發出來的，因爲別人假冒不了發送方的簽名。二是數字簽名能確定消息的完整性。
3. 數字證書--值得信賴的公鑰
只從”準確認證發送方身份“和”確保數據完整性“兩個安全方面來看，數字簽名似乎已經完全做到了，還有漏洞存在的可能麼？有，漏洞不在數字簽名技術本身，而在它所依賴的密鑰，只有密鑰是真實可靠的前提下，使用數字簽名纔是安全有效的。考慮這種可能的情況：在上述發送方向接收方傳送報文的例子中，如果發送方所持有的公鑰來路有問題或是被替換了，那麼，持有對應私鑰的冒充接受方就有可能接收到發送方發送的報文。這裏的問題就是：對於請求方來說，它怎麼能確定它所得到的公鑰一定是從目標主機那裏發佈的，而且沒有被篡改過呢？亦或者請求的目標主機本本身就從事竊取用戶信息的不正當行爲呢？這時候，我們需要有一個權威的值得信賴的第三方機構(一般是由政府審覈並授權的機構)來統一對外發放主機機構的公鑰，只要請求方這種機構獲取公鑰，就避免了上述問題的發生。這種機構被稱爲證書權威機構（Certificate Authority, CA），它們所發放的包含主機機構名稱、公鑰在內的文件就是人們所說的“數字證書”。
數字證書的頒發過程一般爲：用戶首先產生自己的密鑰對，並將公共密鑰及部分個人身份信息傳送給認證中心。認證中心在覈實身份後，將執行一些必要的步驟，以確信請求確實由用戶發送而來，然後，認證中心將發給用戶一個數字證書，該證書內包含用戶的個人信息和他的公鑰信息，同時還附有認證中心的簽名信息。用戶就可以使用自己的數字證書進行相關的各種活動。數字證書由獨立的證書發行機構發佈。數字證書各不相同，每種證書可提供不同級別的可信度。可以從證書發行機構獲得您自己的數字證書。（本段摘自百度百科）
關於數字簽名與數字證書的解釋和差異，這裏有一篇非常優秀的文章，介紹得淺顯易懂：
中文譯文：http://www.cnblogs.com/heart-runner/archive/2012/01/30/2332020.html
英文原文：http://www.youdzone.com/signature.html
4. SSL
當所有上面提及的技術介紹完之後，我們需要把它們統一起來應用於實際的網絡安全傳輸了，因此，人們制定了一套協議，來定義有關的方方面面，這個協議就是SSL。SSL建立通信的過程分爲兩個階段：握手階段和傳輸階段，關於握手機制，在此不再贅述，網上有非常細緻的介紹，此處僅貼出一張簡單的示意圖：
圖2.SSL握手階段示意圖
值得特別提出的是：SSL協議在握手階段使用的是非對稱加密，在傳輸階段使用的是對稱加密，也就是說在SSL上傳送的數據是使用對稱密鑰加密的！這並不奇怪，因爲非對稱加密的速度緩慢，耗費資源。其實當客戶端和主機使用非對稱加密方式建立連接後，客戶端和主機已經決定好了在傳輸過程使用的對稱加密算法和關鍵的對稱加密密鑰，由於這個過程本身是安全可靠的，也即對稱加密密鑰是不可能被竊取盜用的，因此，保證了在傳輸過程中對數據進行對稱加密也是安全可靠的，因爲除了客戶端和主機之外，不可能有第三方竊取並解密出對稱加密密鑰！
4.1 SSL保證了哪些網絡安全中的哪些方面？
SSL協議主要確保了以下安全問題：
1）認證用戶和服務器，確保數據發送到正確的客戶機和服務器
2）加密數據以防止數據中途被竊取
3）維護數據的完整性，確保數據在傳輸過程中不被改變。
(關於SSL是如何確保數據完整性這一點，目前我還不清楚其具體是如何實現的，因爲關於SSL在傳輸過程中是否使用了數字簽名，我目前還沒有找到確切的答案。)
5.HTTPS
如果我們是在一開始來講述HTTPS協議，那將會是一個很大的話題，但是講到這裏的時候，實現上所有關於HTTPS的內容，我們基本上已經講完了，它所有依賴的所有安全技術就是上面我們所提及的，就像大家所知道的那樣，HTTPS是由SSL+HTTP協議構建的可進行加密傳輸、身份認證（確認客戶端連接的目標主機是否是真實正確的主機）的網絡協議。https所能實現的安全保證，正是SSL所能解決的安全問題，見上一節。
5.1 HTTPS的劣勢
https的主要缺點就是性能問題。造成https性能低於http的原因有兩個：
1.對數據進行加解密決定了它比http慢。
2.另外一個重要原因的是https禁用了緩存。
相關測試數據表明使用HTTPS協議傳輸數據的工作效率只有使用HTTP協議傳輸的十分之一。因此對於一個網站來說，只有那對那些安全要求極高的的數據纔會選擇使用https進行傳輸。
6.周邊話題
6.1 網絡安全和應用程序的安全控制兩者之間有什麼關係？
網絡安全和一個應用程序自身的安全控制之間並沒有太多直接的交集，應該說兩者的關注點不在一起，前者主要解決的是“傳輸過程”中的安全問題，即確認信任主機和防止泄密及篡改。而一個應用程序的安全控制是指在請求到達後，應用程序自身對請求進行的安全檢查，這種“檢查”主要涉及兩個方面：Authentication和Authorization，這也是所有應用程序安全控制方面要完成了兩個重要任務。關於Authentication和Authorization,詳細一點說，Authentication就是：
一.從訪問者提交的身份信息中，確認當前的訪問者是否是本系統的合法的用戶，也就是對訪問者進行“身份認證”。說得更直白些就是，覈實一下當前這個訪問者是不是我的用戶，是就讓他訪問，不是就拒絕。所以說，我們一般的系統登錄過程就是一個“Authentication”的過程！
二.對用戶的訪問進行控制，也就是控制用戶可以執行哪些操作，不能執行哪些操作。對於一般的系統來說，也就是根據用戶的角色或權限，確定用戶能訪問哪些頁面，不能訪問哪些頁面。
---------------------
原文：https://blog.csdn.net/bluishglc/article/details/7585965