Java安全(加密、摘要、簽名、證書、SSL、HTTPS)

對於通常的開發人員來講，不多須要對安全領域內的基礎技術進行深刻的研究，可是鑑於平常系統開發中遇到的各類安全相關的問題，熟悉和了解這些安全技術的基本原理和使用場景仍是很是必要的。本文將對非對稱加密、數字摘要、數字簽名、數字證書、SSL、HTTPS等這些安全領域內的技術進行一番簡要的介紹，解釋他們之間的關係，同時補充一些周邊話題。

安全領域的技術衆多，可是歸根結底，他們都是爲了保障以下三個方面：

   1）認證用戶和服務器，確保數據發送到正確的客戶機和服務器    2）加密數據以防止數據中途被竊取    3）維護數據的完整性，確保數據在傳輸過程當中不被改變。 

對稱加密和非對稱密鑰加解密        對於一份數據，經過一種算法，基於傳入的密鑰(一串由數字或字符組成的字符串,也稱「key」），將明文數據轉換成了不可閱讀的密文，這是衆所周知的「加密」，一樣的，密文到達目的地後，須要再以相應的算法，配合一個密鑰，將密文再解密成明文，這就是「解密」。若是加密和解密使用的是同一個密鑰,那麼這就是「對稱密鑰加解密」（最多見的對稱加密算法是DES）。若是加密和解密使用的是兩個不一樣的密鑰，那麼這就是「非對稱密鑰加解密」（最經常使用的非對稱加密算法是RSA）。這兩個不一樣的密鑰一個叫做公開密鑰（publickey）另外一個叫私有密鑰（privatekey），公開密鑰對外公開，任何人都可獲取，而私有密鑰則由本身保存，其實公鑰和私鑰並無什麼不一樣之處，公鑰之因此成爲公鑰是由於它會被公開出來，產生任意份拷貝，供任何人獲取，而只有服務主機持有惟一的一份私鑰，從這種分發模式上看，咱們不難看出其中的用意，這種分發模式其實是Web站點多客戶端(瀏覽器)與單一服務器的網絡拓撲所決定的，多客戶端意味着密鑰能被複制和公開獲取，單一服務器意味着密鑰被嚴格控制，只能由本服務器持有，這實際上也是後面要提到的之因此能經過數據證書肯定信任主機的重要緣由之一。若是咱們跳出web站點的拓撲環境，其實就沒有什麼公鑰與私鑰之分了，好比，對於那些使用以密鑰爲身份認證的SSH主機，每每是爲每個用戶單獨生成一個私鑰分發給他們本身保存，SSH主機會保存一份公鑰，公鑰私鑰各有一份，都不會公開傳播。

簡言之：

對稱加密速度快，但加密和解密的鑰匙必須相同，只有通訊雙方纔能知道鑰匙 非對稱加密速度慢，加密和解密的鑰匙不相同，某一我的持有私鑰，任何人均可以知道公鑰

數字摘要--數據完整性的校驗         這個很是簡單，咱們在下載文件的時候常常會看到有的下載站點也提供下載文件的「數字摘要「，供下載者驗證下載後的文件是否完整，或者說是否和服務器上的文件」如出一轍「。其實，數字摘要就是採用單項Hash函數將須要加密的明文「摘要」成一串固定長度（128位）的密文，這一串密文又稱爲數字指紋，它有固定的長度，並且不一樣的明文摘要成密文，其結果老是不一樣的，兒一樣的明文其摘要一定一致。 所以，「數字摘要「叫」數字指紋「可能會更貼切一些。「數字摘要「是https能確保數據完整性和防篡改的根本緣由。

數字簽名--水到渠成的技術         讓咱們來看看有了「非對稱密鑰加解密」和「數字摘要「兩項技術以後，咱們能作些什麼呢？假如發送方想把一份報文發送給接收方，在發送報文前，發送方用一個哈希函數從報文文本中生成報文摘要,而後用本身的私人密鑰對這個摘要進行加密，這個加密後的摘要將做爲報文的」簽名「和報文一塊兒發送給接收方，接收方首先用與發送方同樣的哈希函數從接收到的原始報文中計算出報文摘要，接着再用發送方的公用密鑰來對報文附加的數字簽名進行解密，若是這兩個摘要相同、那麼接收方就能確認報文是從發送方發送且沒有被遺漏和修改過！這就是結合「非對稱密鑰加解密」和「數字摘要「技術所能作的事情，這也就是人們所說的「數字簽名」技術。在這個過程當中，對傳送數據生成摘要並使用私鑰進行加密地過程就是生成」數字簽名「的過程，通過加密的數字摘要，就是人們所說的」數字簽名「！        數字簽名技術就是對「非對稱密鑰加解密」和「數字摘要「兩項技術的應用，它將摘要信息用發送者的私鑰加密，與原文一塊兒傳送給接收者。接收者只有用發送者的公鑰才能解密被加密的摘要信息，而後用HASH函數對收到的原文產生一個摘要信息，與解密的摘要信息對比。若是相同，則說明收到的信息是完整的，在傳輸過程當中沒有被修改，不然說明信息被修改過，所以數字簽名可以驗證信息的完整性。(注意，數字簽名只能驗證數據的完整性，數據自己是否加密不屬於數字簽名的控制範圍) 綜上所述，數字簽名有兩種功效：一是能肯定消息確實是由發送方簽名併發出來的，由於別人假冒不了發送方的簽名。二是數字簽名能肯定消息的完整性。

數字證書--值得信賴的公鑰         只從」準確認證發送方身份「和」確保數據完整性「兩個安全方面來看，數字簽名彷佛已經徹底作到了，還有漏洞存在的可能麼？有，漏洞不在數字簽名技術自己，而在它所依賴的密鑰，只有密鑰是真實可靠的前提下，使用數字簽名纔是安全有效的。考慮這種可能的狀況：在上述發送方向接收方傳送報文的例子中，若是發送方所持有的公鑰來路有問題或是被替換了，那麼，持有對應私鑰的冒充接受方就有可能接收到發送方發送的報文。這裏的問題就是：對於請求方來講，它怎麼能肯定它所獲得的公鑰必定是從目標主機那裏發佈的，並且沒有被篡改過呢？亦或者請求的目標主機本自己就從事竊取用戶信息的不正當行爲呢？這時候，咱們須要有一個權威的值得信賴的第三方機構(通常是由政府審覈並受權的機構)來統一對外發放主機機構的公鑰，只要請求方這種機構獲取公鑰，就避免了上述問題的發生。這種機構被稱爲證書權威機構（Certificate Authority, CA），它們所發放的包含主機機構名稱、公鑰在內的文件就是人們所說的「數字證書」。         數字證書的頒發過程通常爲：用戶首先產生本身的密鑰對，並將公共密鑰及部分我的身份信息傳送給認證中心。認證中心在覈實身份後，將執行一些必要的步驟，以確信請求確實由用戶發送而來，而後，認證中心將發給用戶一個數字證書，該證書內包含用戶的我的信息和他的公鑰信息，同時還附有認證中心的簽名信息。用戶就可使用本身的數字證書進行相關的各類活動。數字證書由獨立的證書發行機構發佈。數字證書各不相同，每種證書可提供不一樣級別的可信度。能夠從證書發行機構得到您本身的數字證書。（本段摘自百度百科）

SSL

        SSL(Secure Socket Layer)是netscape公司設計的主要用於web的安全傳輸協議。這種協議在WEB上得到了普遍的應用，IETF(www.ietf.org)將SSL做了標準化，即RFC2246,並將其稱爲TLS（Transport Layer Security），從技術上講，TLS1.0與SSL3.0的差異很是微小。 基本原理：先非對稱加密傳遞對稱加密所要用的鑰匙，而後雙方用該鑰匙對稱加密和解密往來的數據

要求：服務器端需安裝數字證書，用戶可能須要確認證書，會話過程當中的加密與解密過程由瀏覽器與服務器自動完成，對用戶徹底透明。

SSL握手階段示意圖：

工做過程：

瀏覽器向服務器發出請求，詢問對方支持的對稱加密算法和非對稱加密算法；服務器迴應本身支持的算法。 瀏覽器選擇雙方都支持的加密算法，並請求服務器出示本身的證書；服務器迴應本身的證書。  瀏覽器隨機產生一個用於本次會話的對稱加密的鑰匙，並使用服務器證書中附帶的公鑰對該鑰匙進行加密後傳遞給服務器；服務器爲本次會話保持該對稱加密的鑰匙。第三方不知道服務器的私鑰，即便截獲了數據也沒法解密。非對稱加密讓任何瀏覽器均可以與服務器進行加密會話。 瀏覽器使用對稱加密的鑰匙對請求消息加密後傳送給服務器，服務器使用該對稱加密的鑰匙進行解密；服務器使用對稱加密的鑰匙對響應消息加密後傳送給瀏覽器，瀏覽器使用該對稱加密的鑰匙進行解密。第三方不知道對稱加密的鑰匙，即便截獲了數據也沒法解密。對稱加密提升了加密速度。

HTTPS 若是咱們是在一開始來說述HTTPS協議，那將會是一個很大的話題，可是講到這裏的時候，實現上全部關於HTTPS的內容，咱們基本上已經講完了，它全部依賴的全部安全技術就是上面咱們所說起的，就像你們所知道的那樣，HTTPS是由SSL+HTTP協議構建的可進行加密傳輸、身份認證（確認客戶端鏈接的目標主機是不是真實正確的主機）的網絡協議。https所能實現的安全保證，正是SSL所能解決的安全問題。

HTTPS的劣勢： https的主要缺點就是性能問題。形成https性能低於http的緣由有兩個： 1.對數據進行加解密決定了它比http慢。 2.另一個重要緣由的是https禁用了緩存。 相關測試數據代表使用HTTPS協議傳輸數據的工做效率只有使用HTTP協議傳輸的十分之一。所以對於一個網站來講，只有那對那些安全要求極高的的數據纔會選擇使用https進行傳輸。

對以上的知識聯通起來作一個集中圖示，相信你們會有更加清晰的理解：

1.鮑勃有兩把鑰匙，一把是公鑰，另外一把是私鑰。

                               

2.鮑勃把公鑰送給他的朋友們----帕蒂、道格、蘇珊----每人一把。                                    

           

3.蘇珊要給鮑勃寫一封保密的信。她寫完後用鮑勃的公鑰加密，就能夠達到保密的效果。

                              

4.鮑勃收信後，用私鑰解密，就看到了信件內容。這裏要強調的是，只要鮑勃的私鑰不泄露，這封信就是安全的，即便落在別人手裏，也沒法解密。

   

5.鮑勃給蘇珊回信，決定採用"數字簽名"。他寫完後先用Hash函數，生成信件的數字摘要（digest）。

6.而後，鮑勃使用私鑰，對這個數字摘要加密，生成"數字簽名"（signature）。

7.鮑勃將這個簽名，附在信件下面，一塊兒發給蘇珊。

8.蘇珊收信後，取下數字簽名，用鮑勃的公鑰解密，獲得信件的摘要。由此證實，這封信確實是鮑勃發出的。

9.蘇珊再對信件自己使用Hash函數，將獲得的結果，與上一步獲得的摘要進行對比。若是二者一致，就證實這封信未被修改過。

10.複雜的狀況出現了。道格想欺騙蘇珊，他偷偷使用了蘇珊的電腦，用本身的公鑰換走了鮑勃的公鑰。此時，蘇珊實際擁有的是道格的公鑰，可是還覺得這是鮑勃的公鑰。所以，道格就能夠冒充鮑勃，用本身的私鑰作成"數字簽名"，寫信給蘇珊，讓蘇珊用假的鮑勃公鑰進行解密。

11.後來，蘇珊感受不對勁，發現本身沒法肯定公鑰是否真的屬於鮑勃。她想到了一個辦法，要求鮑勃去找"證書中心"（certificate authority，簡稱CA），爲公鑰作認證。證書中心用本身的私鑰，對鮑勃的公鑰和一些相關信息一塊兒加密，生成"數字證書"（Digital Certificate）。

12.鮑勃拿到數字證書之後，就能夠放心了。之後再給蘇珊寫信，只要在簽名的同時，再附上數字證書就好了。

13.蘇珊收信後，用CA的公鑰解開數字證書，就能夠拿到鮑勃真實的公鑰了，而後就能證實"數字簽名"是否真的是鮑勃籤的。

14.咱們看一個應用"數字證書"的實例：https協議。這個協議主要用於網頁加密

15.首先，客戶端向服務器發出加密請求。

16.服務器用本身的私鑰加密網頁之後，連同自己的數字證書，一塊兒發送給客戶端。

17.客戶端（瀏覽器）的"證書管理器"，有"受信任的根證書頒發機構"列表。客戶端會根據這張列表，查看解開數字證書的公鑰是否在列表以內。

18.若是數字證書記載的網址，與你正在瀏覽的網址不一致，就說明這張證書可能被冒用，瀏覽器會發出警告。

19.若是這張數字證書不是由受信任的機構頒發的，瀏覽器會發出另外一種警告。

20.若是數字證書是可靠的，客戶端就可使用證書中的服務器公鑰，對信息進行加密，而後與服務器交換加密信息。