此文章轉載來源於http://blog.csdn.net/tenfyguo/article/details/40958727點選開啟連結

1.  HTTPS

1.1. 什麼是HTTPS

HTTPS（HypertextTransfer Protocol Secure）即安全的HTTP。HTTPS的安全基礎是安全套接層（Secure Sockets Layer，SSL）。HTTP工作在應用層（OSI模型的最高層），SSL協議工作在一個較低的子層，位於TCP/IP協議和HTTP協議之間。在HTTP報文傳輸前對其加密，並在到達時對其解密。嚴格地講，HTTPS並不是一個單獨的協議，而是工作在SSL協議上的HTTP協議。

TLS對SSL進行了擴充，是SSL的繼任者，但兩者區別不大，以下討論中不對TLS和SSL做嚴格區分。

HTTPS主要作用有兩種：（1）確認通訊雙方的身份，（2）建立安全通道，保證資料傳輸安全。

1.2. HTTPS的主要作用

1.2.1. 確認通訊雙方的身份

HTTPS通訊中，通過簽名技術通訊雙方可以確認對方身份。身份認證分為單向認證和雙向認證。單向認證中只有伺服器端有證書，雙向認證中伺服器和客戶端都有證書。一般的HTTPS站點只有伺服器有證書，而客戶端無證書。

單向認證是雙向認證的簡化版，本文討論過程中如無特殊說明都認為是雙向認證。

1.2.2. 建立安全通道，保證資料傳輸安全

基於SSL協議通訊雙方可以協商一個用於對稱加密的金鑰，該金鑰是一個難以破解的隨機數，而且依賴通訊雙方的證書、私鑰等來協商。金鑰協商好後，通訊雙方用該金鑰對資料進行加解密，從而保證資料安全。

1.3. HTTPS與HTTP協議的差異

(1).   HTTP 的URL是以“http://”開始，HTTPS的URL是以“https://”開始；

(2).   HTTP預設埠為80，HTTPS的預設埠為443；

(3).   採用HTTPS的Web Server需要到CA申請證書；

(4).   HTTPS由HTTP+SSL來實現，可進行加密傳輸、身份認證等，要比HTTP安全

(5).   HTTP的資訊是明文傳輸，而HTTPS的資訊是加密傳輸

2.  公開金鑰加密

2.1. 什麼是公開金鑰加密？

公開金鑰加密也稱非對稱金鑰加密，該加密演算法使用兩個不同的金鑰：加密金鑰和解密金鑰。前者公開，又稱公開金鑰，簡稱公鑰；後者保密，又稱私有金鑰，簡稱私鑰。這兩個金鑰是數學相關的，用某使用者加密金鑰加密後所得的資訊只能用該使用者的解密金鑰才能解密。RSA演算法（由發明者Rivest，Shmir和Adleman姓氏首字母縮寫而來）是著名的公開金鑰加密演算法。

公鑰加密的另一用途是身份驗證：用私鑰加密的資訊，可以用公鑰對其解密，接收者由此可知這條資訊確實來自於擁有私鑰的某人。私鑰加密的過程即數字簽名。

用公鑰加密的資料只有私鑰才能解密；相反的，用私鑰加密的資料只有公鑰才能解密，正是這種不對稱性才使得公用金鑰密碼系統被廣泛應用。

2.2. 優點

與對稱金鑰加密相比，優點在於無需共享的通用金鑰，解密的私鑰不發往任何使用者。即使公鑰在網上被截獲，如果沒有與其匹配的私鑰，也無法解密，所截獲的公鑰是沒有任何用處的。　　

2.3. 過程

假設兩個使用者A，B進行通訊，公鑰為c,私鑰為d，明文為x.

Step 1. A用公鑰對明文進行加密形成密文c(x)，然後傳輸密文；

Step 2. B收到密文，用私鑰對密文進行解密d(c(x)),得到要通訊的明文

2.4. 對稱金鑰加密

對稱金鑰加密又叫專用金鑰加密，即傳送和接收資料的雙方必須使用相同的金鑰對明文進行加密和解密運算。

3.    數字證書和CA

3.1. 確認主機的真實性

採用https 的server（伺服器）必須從CA （CertificateAuthority）申請一個用於證明伺服器用途型別的數字證書（或者叫CA證書）. 該證書只有用於對應的server 時，客戶端才信任此主機.

CA（Certificate Authority）即"認證機構"，是負責簽發證書、認證證書、管理已頒發證書的機構，是PKI（Public Key Infrastructure，公鑰基礎設施）的核心。它要制定政策和具體步驟來驗證、識別使用者身份，並對使用者證書進行簽名，以確保證書持有者的身份和公鑰的擁有權。

CA 也擁有一個證書（內含公鑰）和私鑰。網上的公眾使用者通過驗證 CA 的簽字從而信任CA ，任何人都可以得到 CA 的證書（含公鑰），用以驗證它所簽發的證書。

3.2. 什麼是數字證書

數字證書（CA證書是經過認證的數字證書）是一個用於網際網路通訊中認證身份的工具，由權威機構——CA機構（Certificate Authority）發行。其作用類似於司機的駕駛執照和公民身份證。CA作為公正的第三方來確保證書的有效性[6]。全國存在多個CA機構（只要你有公信力你也可以成立一家CA機構）。

數字證書包含一個公鑰以及該金鑰所有者的資訊。證書還標明有有效期，並通過另一金鑰（CA私鑰）進行簽名，該金鑰能保證這些屬性的真實性，最重要的是，保證公鑰本身的真實性[14]。最簡單的證書包含一個公鑰、名稱以及證書授權中心的數字簽名（公開金鑰只是證書的一部分內容）。目前，證書的格式和驗證方法普遍遵循X.509 國際標準。

CA機構自身也擁有一個證書（內含公鑰）和一個私鑰。

使用者如果想得到一個數字證書，他應先向 CA申請，CA審查申請者的身份後，給他分配一個公鑰，並將公鑰與申請者的身份資訊綁在一起，同時用自己的私鑰簽字，最終生成一個證書，發給申請者；同時還將一個與公鑰關聯的私鑰也發給申請者。證書的內容主要有：CA資訊、CA簽字、證書擁有者資訊、證書公鑰和證書有效期等。

某人需要驗證一個證書時，用簽發該證書的CA的公鑰來解密其簽名信息，以驗證證書是否可信。CA證書也需要驗證，驗證CA證書是一個遞迴上溯的過程，驗證過程終止於根證書。根證書是一份特殊的證書，它的簽發者是它本身，下載根證書就表明使用者對該根證書，以及其所簽發的證書都信任。

3.3. 數字證書基本原理

數字證書採用公開金鑰加密體制，利用一個強關聯的金鑰對進行加、解密。證書擁有者儲存好自己的私鑰，用它進行解密和簽名；並把公鑰公開，供一組使用者所共享，用於加密和驗證簽名。

1、加密：傳送資料時，傳送方使用接收方的公鑰對資料加密，接收方用私鑰解密，還原訊息。演算法保證公鑰加密的資料只有對應的私鑰才能解密。

2、數字簽名：證書擁有者用私鑰對資訊進行加密，由於私鑰僅為本人所有，這樣就生成了別人無法偽造的資料，該資料即數字簽名。採用數字簽名，能夠確認以下兩點：

（1）保證資訊是由簽名者所傳送，簽名者不能否認或者難以否認；

（2）保證資訊自簽發後到收到為止，未曾做過任何修改，簽發的檔案是真實的檔案。

演算法保證只有公鑰才能解開私鑰加密的資訊。

3.4. 如何生成數字證書

略

4.  SSL

4.1. 什麼是SSL

SSL 是一個安全協議，它提供使用TCP/IP 的通訊應用程式間的隱私與完整性。傳輸層安全（Transport Layer Security，TLS）對SSL進行了升級改造，將成為SSL的繼任者。

4.2. 加密過程

SSL 協議既用到了公鑰加密技術(非對稱加密)，又用到了對稱加密技術。

Step 1：用公開金鑰加密技術（通常為RSA）驗證彼此身份（有時伺服器不需要驗證客戶端身份），並協商Step2中通訊時所用的對稱加密金鑰；

Step 2：用對稱金鑰加密技術（如DES，或者RC4）加密伺服器端和客戶端通訊時的資料。

這樣做的好處是：公開金鑰加密相對複雜，速度慢，可用來完成安全性要求較高的身份認證、金鑰協商等事務；對稱金鑰加密技術相對簡單，速度快，可用來加密資料量大的傳輸內容。

4.3. 構成

SSL協議的優勢在於它與應用層協議是獨立無關的。高層的應用層協議 (例如：Http、FTP、Telnet等等 ) 能透明的建立於SSL協議之上。SSL協議在應用層協議通訊之前就已完成資料加密、通訊金鑰的協商和伺服器的認證等工作。在此之後應用層協議所傳送的資料都會被加密，從而保證通訊的私密性。

SSL協議位於TCP/IP協議與各種應用層協議之間，為資料通訊提供安全支援。SSL協議可分為兩層：記錄協議（SSL Record Protocol）和握手協議（SSL Handshake Protocol）。記錄協議建立在可靠的傳輸協議（如TCP）之上，為高層協議，如握手協議，提供資料封裝、壓縮、加解密等支援。握手協議建立在SSL記錄協議之上，用於在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密金鑰等。握手協議協商好加密演算法、壓縮演算法和對稱加密金鑰等後，開始應用層資料傳輸（如HTTP協議的資料傳輸）。應用層的資料傳輸也是工作在記錄協議之上，由記錄層用協商好的金鑰對其資料進行加解密，確保資料安全。

4.4. RSA演算法

1977年美國麻省理工學院的Ron Rivest、Adi Shamirh和LenAdleman共同發明了RSA加密演算法。。該演算法基於一個十分簡單的數論事實：將兩個大素數相乘十分容易，但要對其乘積進行因式分解卻極其困難。

4.5. SSL協議的身份認證和對稱加密金鑰的協商

4.5.1. TSL協議互動過程

TSL的身份認證和金鑰協商大致過程如下（下面只考慮新建會話的情況，而不考慮重啟存在會話的情況）：

Step1：客戶端往伺服器端發ClientHello訊息

訊息特點：該訊息是客戶端連線伺服器端時傳送的第一個訊息。

訊息構成：

(1).   使用的TLS協議版本。

(2).    隨機數；用於計算對稱加密時的“主密碼”。

(3).   會話ID；重連時有用，可為空。

(4).   加密演算法列表；客戶端支援的加密演算法列表，並按照客戶端的偏好從前往後排。

(5).   壓縮演算法列表；客戶端支援的壓縮演算法列表，並按照客戶端的偏好從前往後排。

(6).   擴充套件資訊。

訊息作用：用於發起會話、交換隨機數、協商加密演算法、壓縮演算法等。

Step2：伺服器端驗證ClientHello訊息，主要驗證：

(1)   訊息格式是否合法；

(2)   能否至少支援客戶端所列舉的一個加密演算法和一個壓縮演算法等。

驗證不通過則傳送訊息斷開會話，驗證通過則執行下一步。

Step3：伺服器往客戶端傳送ServerHello訊息。

訊息特點：該訊息是伺服器收到ClientHello後返回給客戶端的第一個訊息。

訊息構成：

(1).   使用的TLS協議版本。

(2).    隨機數；用於計算對稱加密時的“主密碼”(這個隨機數是伺服器傳送給客戶端的,跟第一步驟的隨機數不同,第一個是客戶端傳送給服務的)

(3).   一個加密演算法；伺服器從客戶端的加密演算法列表中選中的一個加密演算法。

(4).   一個壓縮演算法；伺服器從客戶端的壓縮演算法列表中選中的一個壓縮演算法。

(5).    會話ID；新建的唯一的會話ID。

(6).   擴充套件資訊。

訊息作用：用於交換隨機數、確定加密演算法、壓縮演算法等。

Step4：伺服器往客戶端傳送Certificate訊息。

訊息特點：該訊息必須在ServerHello傳送完後立即傳送。如果是匿名協商，則無須發該訊息。

訊息構成：

(1).   證書列表；伺服器的證書必須為證書列表的第一個，其後為簽發伺服器證書的證書，依次類推，最後一個證書為根證書籤署的證書。根證書不在證書列表中，它是通過其他途徑給到客戶端的。(好多時候是瀏覽器預裝好的)

訊息作用：傳送伺服器證書，或者證書鏈。

Step5：伺服器往客戶端傳送ServerKeyExchange訊息。

訊息特點：

(1).   該訊息必須在Certificate傳送完後立即傳送（如果是匿名協商，則該訊息緊跟在ServerHello後）。

(2).    該訊息只有當Certificate訊息無法提供足夠資訊讓客戶端完成“預主密碼”交換時才需要。

訊息構成：

(1).   金鑰交換演算法

訊息作用：該訊息用於傳送金鑰交換演算法給客戶端。客戶端可利用這些演算法和伺服器端完成“預主密碼”的交換。

Step6：伺服器往客戶端傳送CertificateRequest訊息。

訊息特點：

(1).    非匿名的伺服器可通過該訊息來要求客戶端傳送證書驗證其身份。

(2).   如果傳送該訊息則該訊息在ServerKeyExchange傳送完後立即傳送(如果該次互動不傳送ServerKeyExchange，則該訊息緊跟Certificate訊息)

訊息構成：

(1).   證書型別列表；客戶端的證書型別必須是證書型別列表中一種。

(2).   簽名和雜湊演算法列表；列舉伺服器所支援的簽名演算法和雜湊演算法。

(3).   CA名字列表；伺服器只接受的列表中所列出的CA所發行的證書，其他證書無法驗證。

訊息作用：請求客戶端傳送證書驗證其身份。(只有雙向認證才需要,即伺服器也需要認證客戶端)

Step7：伺服器往客戶端傳送ServerHelloDone訊息。

訊息特點：

訊息構成：

(1).   無訊息內容。

訊息作用：該訊息用來告訴客戶端ServerHello以及附屬訊息都已傳送完畢。發完該訊息後伺服器等待客戶端訊息。

Step8：客戶端往伺服器端傳送ClientCertificate訊息。

訊息特點：

(1).    該訊息僅當收到伺服器CertificateRequest時才傳送，即伺服器要求驗證客戶端。

(2).   如果傳送該訊息，則該訊息必須是客戶端收到ServerHelloDone訊息後發往伺服器的第一個訊息。

訊息構成：

(1).   證書列表。

訊息作用：傳送客戶端證書讓伺服器認證。(只有雙向認證才需要,即伺服器也需要認證客戶端)

Step9：客戶端往伺服器端傳送ClientKeyExchange訊息。

訊息特點：

(1).   如果有ClientCertificate訊息，則該訊息必須緊跟其後傳送；如果無ClientCertificate訊息，則該訊息是收到ServerHelloDone訊息後發往伺服器的第一個訊息。

(2).   訊息用RSA演算法或者 Diffie-Hellman引數來協商預主密碼。

(3).    採用RAS加密的協商預主密碼時，先生成一個長的隨機數，由該隨機數和客戶端的TSL版本號構成一個結構體，用伺服器證書的公鑰（從伺服器證書獲得）對結構體進行加密，並把加密後的資料發給伺服器。

(4).   Diffie-Hellman引數協商比較複雜，暫不討論。

訊息構成：因加密演算法而異。

訊息作用：協商預主密碼

Step10：客戶端往伺服器端傳送CertificateVerify訊息。

訊息特點：

(1).   該訊息只有當客戶端證書有簽名能力時(Tenfy:即有客戶端證書，且證書是公鑰和私鑰都有的)傳送，其它情況不傳送（不含固定Diffie-Hellman引數的證書都有簽名能力）。

(2).   該訊息必須在ClientKeyExchange傳送完後立即傳送。

(3).   該訊息採用客戶端證書中的私鑰資訊進行加密。

訊息構成：

(1).   把該訊息之前的所有訊息作為引數，用私鑰對其進行簽名得出一份資料，該資料即為訊息體。

訊息作用：通過簽名方式，驗證客戶端身份。

Step 11：伺服器用伺服器私鑰解密ClientKeyExchange訊息得 “預主密碼”。伺服器和客戶端用相同的演算法計算“主密碼”。主密碼計算是根據預主密碼、ClientHello中的隨機數、ServerHello中的隨機數得到的。計算好主密碼後雙方各向對方傳送一個ChangeCipherSpec訊息：

訊息特點：

(1).   該訊息必須在所有握手訊息傳送完之後，在Finished訊息傳送之前傳送。

(2).   該訊息必須在接收完所有握手訊息之後，在接收Finished訊息之前收到。

訊息構成：

(1).   確認訊息。

訊息作用：確認採用剛才協商好的壓縮演算法、加密演算法、主密碼等來傳輸後繼資料。

Step12：任意一方收到ChangeCipherSpec訊息後告訴自己的Record Layer由讀等待狀態轉為讀狀態，並採用新方式來傳遞資料。並往另外一端往傳送Finished訊息。

訊息特點：

(1).   該訊息是收到ChangeCipherSpec後立即傳送的。

(2).    該訊息是首次採用剛才協商好的壓縮演算法、加密演算法、主密碼等來傳輸的資料。

訊息構成：

(1).   把前面大部分的握手訊息作為引數，用相同的演算法計算得到的一個值。

訊息作用：完成壓縮演算法、加密演算法等的協商，開始轉入應用層資料傳輸。   

Step13：雙方驗證收到的訊息，驗證通過則開始應用層資料傳輸，否則斷開。

TSL通訊時分為單向認證和雙向認證。單向認證時只需要伺服器端擁有證書（公鑰是證書的一部分）和私鑰，其中證書公開，私鑰自己保管；雙向加密時需要伺服器和客戶端都提供證書和私鑰，證書都公開，私鑰都自己保管。這兩個對證書、私鑰對無必然聯絡，實際程式設計時把它們作為兩對獨立的證書、私鑰對來處理。

單向認證時，伺服器端不會驗證客戶證書。故伺服器無須傳送CertificateRequest訊息請求客戶端證書，客戶端無須發與證書相關的ClientCertificate和CertificateVerify訊息。

4.5.2. TSL協議中的訊息驗證

通訊過程中必須嚴格按上述說明來發送和接收訊息。接收方接收訊息後一旦發現：(1)訊息遺漏，(2) 訊息次序不對，(3) 訊息格式（如加密格式）有誤，(4) 訊息內容有誤，(5) 自身致命錯誤等，接收方立即通過Alert Protocol往傳送方傳送ErrorAlert訊息，告訴對方終止此次會話。如果是能容忍的錯誤，則不發任何訊息，以免對方主動斷開會話。

若干重要驗證說明：

1.        客戶端驗證伺服器的Certificate訊息。主要驗證內容為：

(1).    伺服器證書使用日期是否有效。

(2).    發行伺服器證書的CA是否可靠。

(3).    發行者的公鑰能否解開伺服器證書上的“發行者數字簽名”。

(4).    伺服器證書上的名稱（如域名）是否和伺服器實際名稱匹配等（PHP中可以選擇是否驗證該選項）。

(Tenfy: 這裡可以看出,客戶端驗證服務的時候,只需要驗證對應伺服器證書的有效性即可,無需驗證對應伺服器是否擁有跟該證書一致的私鑰)

2.        伺服器驗證客戶端的CertificateVerify訊息。主要驗證內容為：

(1).    用客戶端公鑰能否解開客戶端私鑰加密的訊息。

(Tenfy:伺服器驗證客戶端時候，還需要驗證是否擁有跟證書對應的私鑰)

3.        伺服器驗證客戶端的ClientCertificate訊息。主要驗證內容為：

(1).    客戶的證書使用日期是否有效。

(2).    為客戶提供證書的CA 是否可靠。

(3).    發行CA 的公鑰能否正確解開客戶證書的發行CA的數字簽名。

(4).    檢查客戶的證書是否在證書廢止列表（CRL）中。

附：常見的證書格式

1.1. PEM 

Openssl使用PEM(RFC 1421－1424)文件格式。PEM全稱是PrivacyEnhanced Mail，該標準定義了加密一個準備要傳送郵件的標準。它的基本流程是這樣的：

1、資訊轉換為ASCII碼或其它編碼方式；

2、使用對稱演算法加密轉換了的郵件資訊；

3、使用BASE64對加密後的郵件資訊進行編碼；

4、使用一些頭定義對資訊進行封裝，這些頭資訊格式如下（不一定都需要，可選的）：

Proc-Type,4:ENCRYPTED

DEK-Info:cipher-name, ivec

其中，第一個頭資訊標註了該檔案是否進行了加密，該頭資訊可能的值包括ENCRYPTED(資訊已經加密和簽名)、MIC-ONLY(資訊經過數字簽名但沒有加密)、MIC-CLEAR(資訊經過數字簽名但是沒有加密、也沒有進行編碼，可使用非PEM格式閱讀)以及CLEAR(資訊沒有簽名和加密並且沒有進行編碼，該項好象是openssl自身的擴充套件，但是並沒有真正實現)；；第二個頭資訊標註了加密的演算法以及使用的ivec參量，ivec其實在這兒提供的應該是一個隨機產生的資料序列，與塊加密演算法中要使用到的初始化變數（IV）不一樣。

5、在這些資訊的前面加上如下形式頭標註資訊：

-----BEGINPRIVACY-ENHANCED MESSAGE-----

在這些資訊的後面加上如下形式尾標註資訊：

-----ENDPRIVACY-ENHANCED MESSAGE-----

上面是openssl的PEM檔案的基本結構，需要注意的是，Openssl並沒有實現PEM的全部標準，它只是對openssl中需要使用的一些選項做了實現，詳細的PEM格式，請參考RFC1421－1424。

The Public-KeyCryptography Standards (PKCS)是由美國RSA資料安全公司及其合作伙伴制定的一組公鑰密碼學標準，其中包括證書申請、證書更新、證書作廢表釋出、擴充套件證書內容以及數字簽名、數字信封的格式等方面的一系列相關協議。

1.2. PFX 

PFX（Personal Information Exchange）證書檔案是採用PKCS(The Public-KeyCryptography Standards)標準生成的證書。PKCS是由美國RSA資料安全公司及其合作伙伴制定的一組公鑰密碼學標準，其中包括證書申請、證書更新、證書作廢表釋出、擴充套件證書內容以及數字簽名、數字信封的格式等方面的一系列相關協議。

PFX檔案通常包含一個證書和與之對應的私鑰，現階段證書採用PKCS #12 標準[14]。這類檔案是高度敏感的，在匯出金鑰對時，Windows 提供用密碼加密 .pfx 檔案；而在匯入金鑰對時，您必須再次提供此密碼方可匯入。

1.3. CER 

副檔名為 .cer 的檔案採用 X.509v3 格式ASN.1 ，並由CA簽名。這些檔案中包含著一個公鑰和額外的資訊。這些檔案一般用來提供給業務合作伙伴，以便他們能夠使用公鑰加密資料。

1.4. Java Key Store

Java Key Store（JKS）是Java語言中給出的一種密碼保護的檔案，可儲存金鑰和證書。JKS檔案好比一個倉庫，為防範別人隨便亂拿，倉庫可以設定一把鎖，即JKS檔案的密碼（storepass）。倉庫裡可存放多種金鑰，如公鑰、私鑰和金鑰對（由配對公鑰和私鑰組成）。每個金鑰都有一個名字，稱為別名（alias）。倉庫裡的公鑰只要你能進入倉庫你就可以隨便檢視拿走，私鑰則是有密碼的（keypass），只允許有許可權的人檢視拿走。所以從JKS檔案中讀取公鑰只需要知道JKS檔案（倉庫）的密碼即可，但讀取私鑰時則還必須有私鑰的密碼[1]。