對稱加密
對稱加密(也叫私密金鑰加密)指加密和解密使用相同金鑰的加密演算法。有時又叫傳統密碼演算法，就是加密金鑰能夠從解密金鑰中推算出來，同時解密金鑰也可以從加密金鑰中推算出來。而在大多數的對稱演算法中，加密金鑰和解密金鑰是相同的，所以也稱這種加密演算法為秘密金鑰演算法或單金鑰演算法。
常見的對稱加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA
非對稱加密
與對稱加密演算法不同，非對稱加密演算法需要兩個金鑰：公開金鑰（publickey）和私有金鑰（privatekey）；並且加密金鑰和解密金鑰是成對出現的。非對稱加密演算法在加密和解密過程使用了不同的金鑰，非對稱加密也稱為公開金鑰加密，在金鑰對中，其中一個金鑰是對外公開的，所有人都可以獲取到，稱為公開金鑰，其中一個金鑰是不公開的稱為私密金鑰。
非對稱加密演算法對加密內容的長度有限制，不能超過公開金鑰長度。比如現在常用的公開金鑰長度是 2048 位元，意味著待加密內容不能超過 256 個位元組。
摘要演算法
數位摘要是採用單項Hash函數將需要加密的明文“摘要”成一串固定長度（128位）的密文，這一串密文又稱為數位指紋，它有固定的長度，而且不同的明文摘要成密文，其結果總是不同的，而同樣的明文其摘要必定一致。“數位摘要“是https能確保資料完整性和防篡改的根本原因。
數位簽章
數位簽章技術就是對“非對稱金鑰加解密”和“數位摘要“兩項技術的應用，它將摘要資訊用發送者的私密金鑰加密，與原文一起傳送給接收者。接收者只有用發送者的公開金鑰才能解密被加密的摘要資訊，然後用HASH函數對收到的原文產生一個摘要資訊，與解密的摘要資訊對比。如果相同，則說明收到的資訊是完整的，在傳輸過程中沒有被修改，否則說明資訊被修改過，因此數位簽章能夠驗證資訊的完整性。
數位簽章的過程如下：
明文 --> hash運算 --> 摘要 --> 私密金鑰加密 --> 數位簽章
數位簽章有兩種功效：
一、能確定消息確實是由發送方簽名併發出來的，因為別人假冒不了發送方的簽名。
二、數位簽章能確定消息的完整性。
注意：
數位簽章只能驗證資料的完整性，資料本身是否加密不屬於數位簽章的控制範圍
數位憑證
為什麼要有數位憑證？
對於請求方來說，它怎麼能確定它所得到的公開金鑰一定是從目標主機那裡發佈的，而且沒有被篡改過呢？亦或者請求的目標主機本本身就從事竊取使用者資訊的不正當行為呢？這時候，我們需要有一個權威的值得信賴的協力廠商機構(一般是由政府審核並授權的機構)來統一對外發放主機機構的公開金鑰，只要請求方這種機構獲取公開金鑰，就避免了上述問題的發生。
數位憑證的頒發過程
用戶首先產生自己的金鑰對，並將公共金鑰及部分個人身份資訊傳送給認證中心。認證中心在核實身份後，將執行一些必要的步驟，以確信請求確實由用戶發送而來，然後，認證中心將發給用戶一個數位憑證，該證書內包含使用者的個人資訊和他的公開金鑰資訊，同時還附有認證中心的簽名資訊(根證書私密金鑰簽名)。用戶就可以使用自己的數位憑證進行相關的各種活動。數位憑證由獨立的證書發行機構發佈，數位憑證各不相同，每種證書可提供不同級別的可信度。
證書包含哪些內容
o 憑證授權的名稱
o 證書本身的數位簽章
o 證書持有者公開金鑰
o 證書簽名用到的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 與 TLS
SSL (Secure Socket Layer，安全通訊端層)
SSL為Netscape所研發，用以保障在Internet上資料傳輸之安全，利用資料加密(Encryption)技術，可確保資料在網路上之傳輸過程中不會被截取，當前為3.0版本。
SSL協議可分為兩層： SSL記錄協定（SSL Record Protocol）：它建立在可靠的傳輸協定（如TCP）之上，為高層協定提供資料封裝、壓縮、加密等基本功能的支援。 SSL握手協議（SSL Handshake Protocol）：它建立在SSL記錄協定之上，用於在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密金鑰等。
TLS (Transport Layer Security，傳輸層安全協議)
用於兩個應用程式之間提供保密性和資料完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務組）制定的一種新的協議，它建立在SSL 3.0協定規範之上，是SSL 3.0的後續版本，可以理解為SSL 3.1，它是寫入了 RFC 的。該協議由兩層組成： TLS 記錄協定（TLS Record）和 TLS 握手協議（TLS Handshake）。較低的層為 TLS 記錄協定，位於某個可靠的傳輸協議（例如 TCP）上面。
SSL/TLS協議作用：
o 認證使用者和伺服器，確保資料發送到正確的客戶機和伺服器；
o 加密資料以防止資料中途被竊取；
o 維護資料的完整性，確保資料在傳輸過程中不被改變。
TLS比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、TLS的握手過程
SSL與TLS握手整個過程如下圖所示，下面會詳細介紹每一步的具體內容：
用戶端首次發出請求
由於用戶端(如流覽器)對一些加解密演算法的支援程度不一樣，但是在TLS協定傳輸過程中必須使用同一套加解密演算法才能保證資料能夠正常的加解密。在TLS握手階段，用戶端首先要告知伺服端，自己支援哪些加密演算法，所以用戶端需要將本地支援的加密套件(Cipher Suite)的清單傳送給伺服端。除此之外，用戶端還要產生一個亂數，這個亂數一方面需要在用戶端保存，另一方面需要傳送給伺服端，用戶端的亂數需要跟伺服端產生的亂數結合起來產生後面要講到的 Master Secret 。
用戶端需要提供如下資訊：
o 支援的協定版本，比如TLS 1.0版
o 一個用戶端生成的亂數，稍後用於生成”對話金鑰”
o 支援的加密方法，比如RSA公開金鑰加密
o 支援的壓縮方法
伺服端首次回應
伺服端在接收到用戶端的Client Hello之後，伺服端需要確定加密協定的版本，以及加密的演算法，然後也生成一個亂數，以及將自己的證書發送給用戶端一併發送給用戶端，這裡的亂數是整個過程的第二個亂數。
伺服端需要提供的資訊：
o 協議的版本
o 加密的演算法
o 亂數
o 伺服器憑證
用戶端再次回應
用戶端首先會對伺服器下發的證書進行驗證，驗證通過之後，則會繼續下面的操作，用戶端再次產生一個亂數（第三個亂數），然後使用伺服器憑證中的公開金鑰進行加密，以及放一個ChangeCipherSpec消息即編碼改變的消息，還有整個前面所有消息的hash值，進行伺服器驗證，然後用新秘鑰加密一段資料一併發送到伺服器，確保正式通信前無誤。
用戶端使用前面的兩個亂數以及剛剛新生成的新亂數，使用與伺服器確定的加密演算法，生成一個Session Secret。
ChangeCipherSpec
ChangeCipherSpec是一個獨立的協定，體現在資料包中就是一個位元組的資料，用於告知伺服端，用戶端已經切換到之前協商好的加密套件（Cipher Suite）的狀態，準備使用之前協商好的加密套件加密資料並傳輸了。
伺服器再次回應
伺服端在接收到用戶端傳過來的第三個亂數的 加密資料之後，使用私密金鑰對這段加密資料進行解密，並對資料進行驗證，也會使用跟用戶端同樣的方式生成秘鑰，一切準備好之後，也會給用戶端發送一個 ChangeCipherSpec，告知用戶端已經切換到協商過的加密套件狀態，準備使用加密套件和 Session Secret加密資料了。之後，伺服端也會使用 Session Secret 加密一段 Finish 消息發送給用戶端，以驗證之前通過握手建立起來的加解密通道是否成功。
後續用戶端與伺服器間通信
確定秘鑰之後，伺服器與用戶端之間就會通過商定的秘鑰加密消息了，進行通訊了。整個握手過程也就基本完成了。
值得特別提出的是：
SSL協定在握手階段使用的是非對稱加密，在傳輸階段使用的是對稱加密，也就是說在SSL上傳送的資料是使用對稱式金鑰密碼編譯的！因為非對稱加密的速度緩慢，耗費資源。其實當用戶端和主機使用非對稱加密方式建立連接後，用戶端和主機已經決定好了在傳輸過程使用的對稱加密演算法和關鍵的對稱加密金鑰，由於這個過程本身是安全可靠的，也即對稱加密金鑰是不可能被竊取盜用的，因此，保證了在傳輸過程中對資料進行對稱加密也是安全可靠的，因為除了用戶端和主機之外，不可能有協力廠商竊取並解密出對稱加密金鑰！如果有人竊聽通信，他可以知道雙方選擇的加密方法，以及三個亂數中的兩個。整個通話的安全，只取決於第三個亂數（Premaster secret）能不能被破解。
其他補充
對於非常重要的保密資料，伺服端還需要對用戶端進行驗證，以保證資料傳送給了安全的合法的用戶端。伺服端可以向用戶端發出 Cerficate Request 消息，要求用戶端發送證書對用戶端的合法性進行驗證。比如，金融機構往往只允許認證客戶連入自己的網路，就會向正式客戶提供USB金鑰，裡面就包含了一張用戶端證書。
PreMaster secret前兩個位元組是TLS的版本號，這是一個比較重要的用來核對握手資料的版本號，因為在Client Hello階段，用戶端會發送一份加密套件列表和當前支援的SSL/TLS的版本號給伺服端，而且是使用明文傳送的，如果握手的資料包被破解之後，攻擊者很有可能串改資料包，選擇一個安全性較低的加密套件和版本給伺服端，從而對資料進行破解。所以，伺服端需要對密文中解密出來對的PreMaster版本號跟之前Client Hello階段的版本號進行對比，如果版本號變低，則說明被串改，則立即停止發送任何消息。
session的恢復
有兩種方法可以恢復原來的session：一種叫做session ID，另一種叫做session ticket。
session ID
session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要用戶端給出這個編號，且伺服器有這個編號的記錄，雙方就可以重新使用已有的”對話金鑰”，而不必重新生成一把。
session ID是目前所有流覽器都支持的方法，但是它的缺點在於session ID往往只保留在一台伺服器上。所以，如果用戶端的請求發到另一台伺服器，就無法恢復對話
session ticket
用戶端發送一個伺服器在上一次對話中發送過來的session ticket。這個session ticket是加密的，只有伺服器才能解密，其中包括本次對話的主要資訊，比如對話金鑰和加密方法。當伺服器收到session ticket以後，解密後就不必重新生成對話金鑰了。
目前只有Firefox和Chrome流覽器支持。
總結
https實際就是在TCP層與http層之間加入了SSL/TLS來為上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書，等技術進行用戶端與伺服器的資料加密傳輸，最終達到保證整個通信的安全性。