對於一般的開發人員來說，很少需要對安全領域內的基礎技術進行深入的研究，但是鑑於日常系統開發中遇到的各種安全相關的問題，熟悉和了解這些安全技術的基本原理和使用場景還是非常必要的。本文將對非對稱加密、數字摘要、數字簽名、數字證書、ssl、https等這些安全領域內的技術進行一番簡要的介紹，解釋他們之間的關係，同時補充一些周邊話題。
0. 概覽--常用安全技術及其之間的關聯
安全領域的技術眾多，但是歸根結底，他們都是為了保障如下三個方面：
1）認證使用者和伺服器，確保資料傳送到正確的客戶機和伺服器
2）加密資料以防止資料中途被竊取
3）維護資料的完整性，確保資料在傳輸過程中不被改變。
在我們正式開始對每一項技術進行介紹之前，讓我們先有乙個巨集觀的認識，下圖羅列我們將要涉及的安全技術以及它們之間的關聯。
圖1.安全技術堆疊
1. 從非對稱金鑰加密與數字摘要技術談起。
1.1 什麼是「非對稱金鑰加解密」技術
對於乙份資料，通過一種演算法，基於傳入的金鑰(一串由數字或字元組成的字串,也稱「key」），將明文資料轉換成了不可閱讀的密文，這是眾所周知的「加密」，同樣的，密文到達目的地後，需要再以相應的演算法，配合乙個金鑰，將密文再解密成明文，這就是「解密」。如果加密和解密使用的是同乙個金鑰,那麼這就是「對稱金鑰加解密」（最常見的對稱加密演算法是des）。如果加密和解密使用的是兩個不同的金鑰，那麼這就是「非對稱金鑰加解密」（最常用的非對稱加密演算法是rsa）。這兩個不同的金鑰乙個叫作公開金鑰（publickey）另乙個叫私有金鑰（privatekey），公開金鑰對外公開，任何人均可獲取，而私有金鑰則由自己儲存，其實公鑰和私鑰並沒有什麼不同之處，公鑰之所以成為公鑰是因為它會被公開出來，產生任意份拷貝，供任何人獲取，而只有服務主機持有唯一的乙份私鑰，從這種分發模式上看，我們不難看出其中的用意，這種分發模式實際上是web站點多客戶端(瀏覽器)與單一伺服器的網路拓撲所決定的，多客戶端意味著金鑰能被複製和公開獲取，單一伺服器意味著金鑰被嚴格控制，只能由本伺服器持有，這實際上也是後面要提到的之所以能通過資料證書確定信任主機的重要原因之一。如果我們跳出web站點的拓撲環境，其實就沒有什麼公鑰與私鑰之分了，比如，對於那些使用以金鑰為身份認證的ssh主機，往往是為每乙個使用者單獨生成乙個私鑰分發給他們自己儲存，ssh主機會儲存乙份公鑰，公鑰私鑰各有乙份，都不會公開傳播。
1.2 什麼是「數字摘要「
讓我們來看看有了「非對稱金鑰加解密」和「數字摘要「兩項技術之後，我們能做些什麼呢？假如傳送方想把乙份報文傳送給接收方，在傳送報文前，傳送方用乙個雜湊函式從報文文字中生成報文摘要,然後用自己的私人金鑰對這個摘要進行加密，這個加密後的摘要將作為報文的」簽名「和報文一起傳送給接收方，接收方首先用與傳送方一樣的雜湊函式從接收到的原始報文中計算出報文摘要，接著再用傳送方的公用金鑰來對報文附加的數字簽名進行解密，如果這兩個摘要相同、那麼接收方就能確認報文是從傳送方傳送且沒有被遺漏和修改過！這就是結合「非對稱金鑰加解密」和「數字摘要「技術所能做的事情，這也就是人們所說的「數字簽名」技術。在這個過程中，對傳送資料生成摘要並使用私鑰進行加密地過程就是生成」數字簽名「的過程，經過加密的數字摘要，就是人們所說的」數字簽名「！
數字簽名技術就是對「非對稱金鑰加解密」和「數字摘要「兩項技術的應用，它將摘要資訊用傳送者的私鑰加密，與原文一起傳送給接收者。接收者只有用傳送者的公鑰才能解密被加密的摘要資訊，然後用hash函式對收到的原文產生乙個摘要資訊，與解密的摘要資訊對比。如果相同，則說明收到的資訊是完整的，在傳輸過程中沒有被修改，否則說明資訊被修改過，因此數字簽名能夠驗證資訊的完整性。(注意，數字簽名只能驗證資料的完整性，資料本身是否加密不屬於數字簽名的控制範圍)
綜上所述，數字簽名有兩種功效：一是能確定訊息確實是由傳送方簽名併發出來的，因為別人假冒不了傳送方的簽名。二是數字簽名能確定訊息的完整性。
3. 數字證書--值得信賴的公鑰
當所有上面提及的技術介紹完之後，我們需要把它們統一起來應用於實際的網路安全傳輸了，因此，人們制定了一套協議，來定義有關的方方面面，這個協議就是ssl。ssl建立通訊的過程分為兩個階段：握手階段和傳輸階段，關於握手機制，在此不再贅述，網上有非常細緻的介紹，此處僅貼出一張簡單的示意圖：
圖2.ssl握手階段示意圖
值得特別提出的是：ssl協議在握手階段使用的是非對稱加密，在傳輸階段使用的是對稱加密，也就是說在ssl上傳送的資料是使用對稱金鑰加密的！這並不奇怪，因為非對稱加密的速度緩慢，耗費資源。其實當客戶端和主機使用非對稱加密方式建立連線後，客戶端和主機已經決定好了在傳輸過程使用的對稱加密演算法和關鍵的對稱加密金鑰，由於這個過程本身是安全可靠的，也即對稱加密金鑰是不可能被竊取盜用的，因此，保證了在傳輸過程中對資料進行對稱加密也是安全可靠的，因為除了客戶端和主機之外，不可能有第三方竊取並解密出對稱加密金鑰！
4.1 ssl保證了哪些網路安全中的哪些方面？
ssl協議主要確保了以下安全問題：
1）認證使用者和伺服器，確保資料傳送到正確的客戶機和伺服器
2）加密資料以防止資料中途被竊取
3）維護資料的完整性，確保資料在傳輸過程中不被改變。
(關於ssl是如何確保資料完整性這一點，目前我還不清楚其具體是如何實現的，因為關於ssl在傳輸過程中是否使用了數字簽名，我目前還沒有找到確切的答案。)
如果我們是在一開始來講述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」的過程！
二.對使用者的訪問進行控制，也就是控制使用者可以執行哪些操作，不能執行哪些操作。對於一般的系統來說，也就是根據使用者的角色或許可權，確定使用者能訪問哪些頁面，不能訪問哪些頁面。
加密 和安全有關的那些事
對於一般的開發人員來說，很少需要對安全領域內的基礎技術進行深入的研究，但是鑑於日常系統開發中遇到的各種安全相關的問題，熟悉和了解這些安全技術的基本原理和使用場景還是非常必要的。本文將對非對稱加密 數字摘要 數字簽名 數字證書 ssl https等這些安全領域內的技術進行一番簡要的介紹，解釋他們之間的...
oracle安全有關的物件
使用者登入資料庫的三種方式 a.一般的密碼驗證方式 b.外部驗證方式,通常驗證的密碼與資料庫所有的作業系統密碼一致 c.全域性驗證方式,此種方式也不是把密碼存放在oracle資料庫中的.最常用的就是密碼驗證方式.sql語法詳見 一.使用者管理 sql create user user name id...
elememtui 有關許可權的那些事
業務情景描述 現有乙個後台管理系統，共存在三種型別的人員，超級管理員 稱作1 組別管理員 2 普通使用者 3 每種型別的人看到的操作欄並不一樣，可以進行的操作也不盡相同，於是就需要程式處理一下各個許可權問題。迷茫的前期 1 讓後端返回關於許可權的json資料吧，但卻不太懂這樣的資料應該怎樣處理 2 ...