Https 介紹什麽是Https

　　HTTPS(全稱：Hypertext Transfer Protocol over Secure Socket Layer)，是以安全為目標的HTTP通道。簡單講是HTTP的安全版。

即HTTP下增加SSL層，HTTPS的安全基礎是SSL，因此加密的具體內容就須要SSL

　　Https的作用 內容加密 建立一個信息安全通道，來保證傳輸數據的安全; 身份認證 確認站點的真實性 數據完整性 防止內容被第三方冒充或者篡改Https的劣勢 對數據進行加解密決定了它比http慢

　　須要進行非對稱的加解密。且須要三次握手。

　　https禁用了緩存HTTPS和HTTP的差別 https協議須要到CA申請證書，一般免費證書非常少。須要交費。 http是超文本傳輸協議，信息是明文傳輸;https 則是具有安全性的ssl加密傳輸協議。 http和https使用的是全然不同的連接方式。用的port也不一樣，前者是80。後者是443。

http的連接非常easy，是無狀態的;HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

　　http默認使用80port。https默認使用443port

　　以下就是https的整個架構。如今的https基本都使用TSL了。由於更加安全，所以下圖中的SSL應該換為SSL/TSL。

載入中...

　　以下就上圖中的知識點進行一個大概的介紹。

　　加解密相關知識對稱加密

　　對稱加密(也叫私鑰加密)指加密和解密使用同樣密鑰的加密算法。

有時又叫傳統password算法，就是加密密鑰可以從解密密鑰中推算出來。同一時候解密密鑰也可以從加密密鑰中推算出來。而在大多數的對稱算法中，加密密鑰和解密密鑰是同樣的。所以也稱這樣的加密算法為秘密密鑰算法或單密鑰算法。

　　常見的對稱加密有：DES(Data Encryption Standard)、AES(Advanced Encryption Standard)、RC4、IDEA

　　非對稱加密

　　與對稱加密算法不同，非對稱加密算法須要兩個密鑰：公開密鑰(publickey)和私有密鑰(privatekey);而且加密密鑰和解密密鑰是成對出現的。

非對稱加密算法在加密和解密過程使用了不同的密鑰，非對稱加密也稱為公鑰加密。在密鑰對中。當中一個密鑰是對外公開的，全部人都能夠獲取到，稱為公鑰。當中一個密鑰是不公開的稱為私鑰。

　　非對稱加密算法對加密內容的長度有限制。不能超過公鑰長度。

比方如今經常使用的公鑰長度是 2048 位，意味著待加密內容不能超過 256 個字節。

　　摘要算法

　　數字摘要是採用單項Hash函數將須要加密的明文“摘要”成一串固定長度(128位)的密文，這一串密文又稱為數字指紋，它有固定的長度，並且不同的明文摘要成密文，其結果總是不同的，而相同的明文其摘要必然一致。“數字摘要“是https能確保數據完整性和防篡改的根本原因。

　　數字簽名

　　數字簽名技術就是對“非對稱密鑰加解密”和“數字摘要“兩項技術的應用，它將摘要信息用發送者的私鑰加密。與原文一起傳送給接收者。

接收者僅僅實用發送者的公鑰才幹解密被加密的摘要信息，然後用HASH函數對收到的原文產生一個摘要信息，與解密的摘要信息對照。假設同樣，則說明收到的信息是完整的，在傳輸過程中沒有被改動，否則說明信息被改動過，因此數字簽名可以驗證信息的完整性。

　　數字簽名的步驟例如以下：

　　明文 --> hash運算 --> 摘要 --> 私鑰加密 --> 數字簽名

　　數字簽名有兩種功效：

　　一、能確定消息確實是由發送方簽名並發出來的，由於別人假冒不了發送方的簽名。

　　二、數字簽名能確定消息的完整性。

　　註意：

　　數字簽名僅僅能驗證數據的完整性，數據本身是否加密不屬於數字簽名的控制範圍

　　數字證書為什麽要有數字證書？

　　對於請求方來說，它怎麽能確定它所得到的公鑰一定是從目標主機那裏公布的。並且沒有被篡改過呢？亦或者請求的目標主機本本身就從事竊取用戶信息的不正當行為呢？這時候，我們須要有一個權威的值得信賴的第三方機構(通常是由政府審核並授權的機構)來統一對外發放主機機構的公鑰。僅僅要請求方這樣的機構獲取公鑰，就避免了上述問題的發生。

　　數字證書的頒發過程

　　用戶首先產生自己的密鑰對。並將公共密鑰及部分個人身份信息傳送給認證中心。

認證中心在核實身份後，將運行一些必要的步驟，以確信請求確實由用戶發送而來，然後，認證中心將發給用戶一個數字證書。該證書內包括用戶的個人信息和他的公鑰信息。同一時候還附有認證中心的簽名信息(根證書私鑰簽名)。用戶就能夠使用自己的數字證書進行相關的各種活動。

數字證書由獨立的證書發行機構公布，數字證書各不同樣，每種證書可提供不同級別的可信度。

　　證書包括哪些內容 證書頒發機構的名稱 證書本身的數字簽名 證書持有者公鑰 證書簽名用到的Hash算法驗證證書的有效性

　　瀏覽器默認都會內置CA根證書，當中根證書包括了CA的公鑰

　　證書頒發的機構是偽造的：瀏覽器不認識，直接覺得是危急證書 證書頒發的機構是確實存在的，於是依據CA名。找到相應內置的CA根證書、CA的公鑰。用CA的公鑰，對偽造的證書的摘要進行解密，發現解不了，覺得是危急證書。

對於篡改的證書。使用CA的公鑰對數字簽名進行解密得到摘要A，然後再依據簽名的Hash算法計算出證書的摘要B，對照A與B，若相等則正常，若不相等則是被篡改過的。 證書可在其過期前被吊銷，通常情況是該證書的私鑰已經失密。較新的瀏覽器如Chrome、Firefox、Opera和Internet Explorer都實現了在線證書狀態協議(OCSP)以排除這樣的情形：瀏覽器將站點提供的證書的序列號通過OCSP發送給證書頒發機構。後者會告訴瀏覽器證書是否還是有效的。

　　1、2點是對偽造證書進行的，3是對於篡改後的證書驗證。4是對於過期失效的驗證。

　　SSL 與 TSLSSL (Secure Socket Layer，安全套接字層)

　　SSL為Netscape所研發。用以保障在Internet上傳輸數據之安全，利用數據加密(Encryption)技術，可確保數據在網絡上之傳輸過程中不會被截取。當前為3.0版本號。

　　SSL協議可分為兩層： SSL記錄協議(SSL Record Protocol)：它建立在可靠的傳輸協議(如TCP)之上，為高層協議提供數據封裝、壓縮、加密等基本功能的支持。 SSL握手協議(SSL Handshake Protocol)：它建立在SSL記錄協議之上，用於在實際的傳輸數據開始前。通訊兩方進行身份認證、協商加密算法、交換加密密鑰等。

　　TSL (Transport Layer Security，傳輸層安全協議)

　　用於兩個應用程序之間提供保密性和數據完整性。

　　TLS 1.0是IETF(Internet Engineering Task Force，Internetproject任務組)制定的一種新的協議，它建立在SSL 3.0協議規範之上，是SSL 3.0的興許版本號。能夠理解為SSL 3.1，它是寫入了 RFC 的。

該協議由兩層組成： TLS 記錄協議(TLS Record)和 TLS 握手協議(TLS Handshake)。較低的層為 TLS 記錄協議，位於某個可靠的傳輸協議(比如 TCP)上面。

　　SSL/TSL協議作用： 認證用戶和server。確保數據發送到正確的客戶機和server; 加密數據以防止數據中途被竊取; 維護數據的完整性，確保數據在傳輸過程中不被改變。TSL比SSL的優勢 對於消息認證使用密鑰散列法：TLS 使用“消息認證代碼的密鑰散列法”(HMAC)，當記錄在開放的網絡(如因特網)上傳送時，該代碼確保記錄不會被變更。

SSLv3.0還提供鍵控消息認證，但HMAC比SSLv3.0使用的(消息認證代碼)MAC 功能更安全。

增強的偽隨機功能(PRF)：PRF生成密鑰數據。在TLS中。HMAC定義PRF。PRF使用兩種散列算法保證其安全性。假設任一算法暴露了，僅僅要另外一種算法未暴露。則數據仍然是安全的。

改進的已完畢消息驗證：TLS和SSLv3.0都對兩個端點提供已完畢的消息，該消息認證交換的消息沒有被變更。

然而，TLS將此已完畢消息基於PRF和HMAC值之上。這也比SSLv3.0更安全。 一致證書處理：與SSLv3.0不同，TLS試圖指定必須在TLS之間實現交換的證書類型。 特定警報消息：TLS提供很多其它的特定和附加警報，以指示任一會話端點檢測到的問題。

TLS還對何時應該發送某些警報進行記錄。SSL、TSL的握手過程

　　SSL與TSL握手整個步驟例如以下圖所看到的。以下會具體介紹每一步的具體內容：

載入中...

　　client首次發出請求

　　因為client(如瀏覽器)對一些加解密算法的支持程度不一樣，可是在TLS協議傳輸過程中必須使用同一套加解密算法才幹保證數據可以正常的加解密。

在TLS握手階段。client首先要告知服務端。自己支持哪些加密算法。所以client須要將本地支持的加密套件(Cipher Suite)的列表傳送給服務端。

除此之外，client還要產生一個隨機數，這個隨機數一方面須要在client保存，還有一方面須要傳送給服務端，client的隨機數須要跟服務端產生的隨機數結合起來產生後面要講到的 Master Secret 。

　　client須要提供例如以下信息：

　　支持的協議版本號，比方TLS 1.0版 一個client生成的隨機數。稍後用於生成”對話密鑰” 支持的加密方法，比方RSA公鑰加密 支持的壓縮方法服務端首次回應

　　服務端在接收到client的Client Hello之後，服務端須要確定加密協議的版本號，以及加密的算法，然後也生成一個隨機數，以及將自己的證書發送給client一並發送給client。這裏的隨機數是整個過程的第二個隨機數。

　　服務端須要提供的信息：

　　協議的版本號 加密的算法 隨機數 server證書client再次回應

　　client首先會對server下發的證書進行驗證，驗證通過之後。則會繼續以下的操作，client再次產生一個隨機數(第三個隨機數)。然後使用server證書中的公鑰進行加密。以及放一個ChangeCipherSpec消息即編碼改變的消息。還有整個前面全部消息的hash值，進行server驗證。然後用新秘鑰加密一段數據一並發送到server，確保正式通信前無誤。

　　client使用前面的兩個隨機數以及剛剛新生成的新隨機數，使用與server確定的加密算法，生成一個Session Secret。

　　ChangeCipherSpec

　　ChangeCipherSpec是一個獨立的協議，體如今數據包中就是一個字節的數據，用於告知服務端，client已經切換到之前協商好的加密套件(Cipher Suite)的狀態，準備使用之前協商好的加密套件加密數據並傳輸了。

　　server再次響應

　　服務端在接收到client傳過來的第三個隨機數的 加密數據之後，使用私鑰對這段加密數據進行解密，並對數據進行驗證，也會使用跟client相同的方式生成秘鑰。一切準備好之後，也會給client發送一個 ChangeCipherSpec，告知client已經切換到協商過的加密套件狀態。準備使用加密套件和 Session Secret加密數據了。之後，服務端也會使用 Session Secret 加密一段 Finish 消息發送給client。以驗證之前通過握手建立起來的加解密通道是否成功。

　　興許client與server間通信

　　確定秘鑰之後，server與client之間就會通過商定的秘鑰加密消息了，進行通訊了。

整個握手過程也就基本完畢了。

　　值得特別提出的是：

　　SSL協議在握手階段使用的是非對稱加密，在傳輸階段使用的是對稱加密，也就是說在SSL上傳送的數據是使用對稱密鑰加密的!由於非對稱加密的速度緩慢。耗費資源。事實上當client和主機使用非對稱加密方式建立連接後，client和主機已經決定好了在傳輸過程使用的對稱加密算法和關鍵的對稱加密密鑰，由於這個過程本身是安全可靠的，也即對稱加密密鑰是不可能被竊取盜用的，因此，保證了在傳輸過程中對數據進行對稱加密也是安全可靠的。由於除了client和主機之外，不可能有第三方竊取並解密出對稱加密密鑰!假設有人竊聽通信，他能夠知道兩方選擇的加密方法，以及三個隨機數中的兩個。整個通話的安全。僅僅取決於第三個隨機數(Premaster secret)能不能被破解。

　　其它補充

　　對於很重要的保密數據，服務端還須要對client進行驗證。以保證數據傳送給了安全的合法的client。服務端能夠向client發出 Cerficate Request 消息，要求client發送證書對client的合法性進行驗證。

比方。金融機構往往僅僅同意認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，裏面就包括了一張client證書。

　　PreMaster secret前兩個字節是TLS的版本號號，這是一個比較重要的用來核對握手數據的版本號號，由於在Client Hello階段，client會發送一份加密套件列表和當前支持的SSL/TLS的版本號號給服務端，並且是使用明文傳送的。假設握手的數據包被破解之後，攻擊者非常有可能串改數據包。選擇一個安全性較低的加密套件和版本號給服務端，從而對數據進行破解。所以。服務端須要對密文中解密出來對的PreMaster版本號號跟之前Client Hello階段的版本號號進行對照。假設版本號號變低，則說明被串改，則馬上停止發送不論什麽消息。

　　session的恢復

　　有兩種方法能夠恢復原來的session：一種叫做session ID。還有一種叫做session ticket。

　　session ID

　　session ID的思想非常easy。就是每一次對話都有一個編號(session ID)。假設對話中斷。下次重連的時候，僅僅要client給出這個編號。且server有這個編號的記錄，兩方就能夠又一次使用已有的”對話密鑰”。而不必又一次生成一把。

　　session ID是眼下全部瀏覽器都支持的方法，可是它的缺點在於session ID往往僅僅保留在一臺server上。

所以，假設client的請求發到還有一臺server。就無法恢復對話

　　session ticket

　　client發送一個server在上一次對話中發送過來的session ticket。這個session ticket是加密的。僅僅有server才幹解密。當中包含本次對話的主要信息，比方對話密鑰和加密方法。當server收到session ticket以後，解密後就不必又一次生成對話密鑰了。

　　眼下僅僅有Firefox和Chrome瀏覽器支持。

　　總結

　　https實際就是在TCP層與http層之間增加了SSL/TSL來為上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書，等技術進行client與server的數據加密傳輸。終於達到保證整個通信的安全性。

有關https安全的相關內容介紹