HTTPS百科：
HTTP是明文傳輸的協議，數據很容易被竊聽和篡改，並且攻擊者很容易冒充客戶端和服務端，HTTPS可以解決這兩個的安全問題。HTTS仍是HTTP協議，只是在HTTP與TCP之間添加了用於加密數據的TSL/SSL協議。很多其它應用層的協議也采用在傳輸層之上添加TSL/SSL協議來保證安全，如FTPS、IMAPS。
加密和解密使用的是同壹個密鑰。加密和解密的雙發都需要持有同壹個密鑰。常見對稱加密算法：AES、DES、3DES。
加密和解密使用的是不同的密鑰，加密時使用的密鑰稱為公鑰匙，解密是使用的密鑰稱為私鑰。使用公鑰加密的密文只能用私鑰解開。公鑰可以發布出去使用，但私鑰壹定不能泄漏。常見的非對稱加密算法：RSA、背包算法、ECC。
數字簽名用於校驗數據是否被篡改，即數據是否和原數據是否壹致。
數字簽名包含簽名和驗證兩個運算。數字簽名具有不可抵賴性，簽名驗證正確後就不能否認。
數字簽名壹般包含壹個自己知道的私鑰和壹個公開的公鑰，與傳統的加密不同的是簽名時使用私鑰，驗證簽名是使用公鑰。
1994年Netscape提出了SSL協議並制訂了SSL協議的原始規範，即SSL1.0。但由於SSL1.0使用的是弱加密算法而受到密碼學界的質疑，所以SSL1.0並沒有公***發布。
SSL1.0之後Netscape對SLL協議規範進行了重大改近，並在1995年發布 SSL2.0協議 。雖然SSL2.0版本被認為是壹個相當強大且健壯的協議，但仍存在壹些易受攻擊的漏洞，所以並沒有得到廣泛的使用。
由於SSL2.0的安全問題，Netscape聯合哈佛的Paul Kocher等人重新設計了SSL協議，並在1996年發布，即SSL3.0版本，該版本較2.0版本有較大的差別。 SSL 3.0協議 獲得了互聯網廣泛認可和支持。
隨著互聯網的飛速發展，網絡安全越來越重要，業界非常迫切的需要壹個標準的安全協議，於是IETE接手了SSL協議，並將其更名為 TSL（Transport Layer Security Protocol，安全傳輸層協議 ，並在1999年發布了TSL1.0版本。
不過TSL1.0於SSL3.0差別並不大（TLS 1.0 內部的協議版本號其實是3.1）。
雖然TSL是SSL的升級，但壹些稱呼上還存在混淆，所以大家通常將二者統稱為SSL/TLS協議。
TSL1.1 於2006年發布，主要是修復了壹些漏洞。
TSL1.2於2008年發布，1.2版本主要移除了壹些老舊的加密套件，並引入了 AEAD 加密模式。1.2版本是目前應用最廣泛的版本。
TSL1.3 於2018年發布。1.3版本在2014年提出，經4年的反復修改直到第28個草案才於2018年正式納入標準。
1.3版本相較1.2版本有很大的改動，即增強了安全性也也大大提升了訪問速度。主要有以下改動：
在公網通訊時想要保證通信信道的安全，目前來看只有將通信的數據進行加密後可防止竊聽、冒充和篡改。
防止竊聽：
數據加密後傳輸的就是加密後的密文，這些密文即使被竊聽了但在沒有解密的密鑰的情況下是得不到真正的內容的。
防冒充和篡改：
通訊的數據加密後傳輸，在沒有加密用的秘鑰的情況下時無法構造出合法的數據包的，也就無法冒充或篡改數據。
將通信數據加密後傳輸可以解決很多的安全問題，但要實現通信的加密最為關鍵的點在於通信的雙發用於加密的密鑰怎麽協商才能保證密鑰不被泄漏和篡改那？密鑰協商是HTTPS中最大的難點。
通信時使用對稱加密，並且在客戶端請求時直接將對稱加密的密鑰返回給客戶端。
但在安全的信道建立起來之前任何傳輸仍是明文的，使用明文風發密鑰毫無安全性可言，並且由對稱加密使用同壹個密鑰，所以第三方在竊聽到密鑰後即可以竊聽和篡改數據也可以冒充客戶端和服務端。 所以直接分發對稱加密的密鑰顯然行不通。
為方便說明這裏只看客戶端單向向服務端發送數據的情況，服務端向客戶端發送數據與其類似。
通信時使用非對稱加密，在客戶端請求時將公鑰放回給客戶端。
但返回公鑰時仍然是明文傳輸的，所以公鑰還是很容易就會被泄漏，泄漏了公鑰後，雖然第三方無在沒有密鑰的情況下是沒法竊聽數據或直接冒充服務端，但由於泄漏了公鑰第三方還是可以冒充客戶端或者進行‘中間人’攻擊。
所以單純使用非對稱加密也是行不通的。
'中間人’攻擊：
只要通信時使用的密鑰不泄漏，那麽在通信時完全沒必要使用非對稱加密，畢竟對稱加密的效率更高。所以可以在通信正式開始前使用非對稱加密來協商出通信時使用的對稱加密的密鑰，步驟如下：
雖然對稱加密與非對稱加密結合可以使我們或得兩種的優點，但這樣還是無法避免‘中間人’攻擊。
DH密鑰協商算法不會直接交互密鑰，而是交互用於生產密鑰的參數，DH算法基於當前‘無法’對大數進行質數分解來保證即使參數泄漏了，第三方也無法通過參數推導出密鑰。
DH算法密鑰協商步驟：
通過以上步驟客戶端和服務端就協商出了密鑰s，並且整個過程中沒有傳輸過s。為了防止被破解a和b通常非常大，p 是壹個至少 300 位的質數，g壹般很小通常是3或者5.
但DH算法的缺點也很明顯，DH無法防止冒充，還是會受到中間人攻擊。
數字證書（digital certificate），又稱公開密鑰認證（Public key certificate）或身份證書（identity certificate），用來下發公鑰匙和證明公鑰擁有者的身份。
證書由第三機構頒發用來驗證服務提供方的合法性，使用時服務提供方將證書給到客戶端，客戶端通過特定的機制驗證書的合法性，從而信任提供證書的服務端和證書中的公鑰。
數字證書以文件的形式存在，證書文件中包含了公鑰信息、擁有者身份信息（主體）、以及數字證書認證機構（發行者）對數字證書自身的數字簽名，證書的數字簽名用來保證證書沒有被篡改。
壹般我們向CA申請證書時不用我們我們提供公鑰和私鑰，CA會給我們分配壹個密鑰對，並將公鑰寫到證書中，然後將證書和私鑰給我們。
證書有統壹的標準，其合法性（證書是否過期、數字簽名是否有效、頒發的機構是否可信）通過壹定的程序按標準來進行驗證，如瀏覽器會保證HTTPS證書是否是合法的，Linux下openSSL庫提供了證書驗證功能。
核對證書後若證書可信，就可以使用證書中的公鑰對數據進行加密與證書的擁有者進行通信。
HTTPS的證書在擴展字段中包含了域名相關的信息，所以HTTPS的證書在申請的時候CA會嚴格的校驗申請的機構或個人是否真的擁有這個域名。
數字證書認證機構（英語：Certificate Authority，縮寫為CA）。證書標準是公開的任何人都可以去制作證書，但自己制作的證書是不受信任的，只有權威的CA機構頒發的證書才被信任。
權威的CA證書審核和部署流程嚴苛而繁雜，所以權威的根證書的有效期壹般在幾十年內。
也只有權威的CA的根證書會被各大操作系統支持，將其預制與操作系統內。
證書壹般遵循X.509規範，主要包含以下內容：
CA生成的證書包含以上內容和壹些擴展字段外，還包含CA使用自己的私鑰對這些內容進行加密後的密文。在驗證證書時使用CA的根證書對秘文進行驗證，從而判斷證書是否是合法的。
權威結構使用根證書來簽發二級CA證書，二級CA證書可以給其它服務簽發證書。但不是所有證書都可以繼續簽發新的證書，證書使用基礎約束擴展來限制證書的簽發，我們普通申請到證書基礎約束擴展都是False的。查看根證書的基本約束可以看到證書頒發機構為‘是’。
根證書並不直接簽發服務的證書，只要基於以下兩點：
上壹級證書對下壹級證書進行簽名，簽名值包含在證書中，可以使用上壹級證書中的公鑰來驗證下壹級證書的簽名值。根證書的簽名是自己簽的，並且驗證簽名的公鑰包含在根證書中。
完整的證書連的關系應該有服務器放回，但有的並沒有返回，對於沒有放回完整證書連的證書，證書中的擴展字段CA 密鑰標識符( Authority Key Identifier)記錄了證書的上壹個證書，通過該字段獲取到上壹級中間證書，再從中間證書的該字段中繼續向上查找，直到根證書。
服務端最好可以返回證書連，這樣可以避免瀏覽器自己去查找，提示握手速度。服務器返回的證書鏈並不包含根證書，根證書預至與操作系統內部。
在linux中openssl庫會集成根證書。openssl的根證書的存放路徑通過‘openssl version -a’查看。
校驗證書時先根據證書鏈逐級校驗證書的簽名，簽名校驗的最關鍵的在根證書。根證書預至於操作系統中，CA要將自己的證書預至與各個系統中是非常困難的，所以預支與系統中的根證書是可信的。
回顧壹下對於HTTPS的證書來說申請的時候CA會嚴苛的驗證，保證這個域名是屬於申請這個證書的機構的。這樣攻擊者或許可以偽造壹個改域名的證書，但偽造的證書的根證書在系統中並不會存在，所以偽造的證書是不會被信任的。這樣通過證書鏈的校驗就可以有效的防止服務端被‘冒充’。
經過上面證書數字簽名驗證只是驗證了證書確實是合法的證書，後還要驗證證書的有效性，有效性驗證主要包括以下字段：
驗證合法的證書也可能由於種種原因被吊銷，如證書的私鑰泄漏了、證書錯發了等，為了驗證證書是否有效引入了證書吊銷機制。
OSCP是證書提供方提供的證書驗證接口，用戶通過調用OSCP接口驗證證書是否被吊銷了。
但OCSP服務可能因為策略或服務故障導致無法訪問，這時壹般瀏覽器會選擇信任證書，畢竟證書被吊銷的情況只是極少數。也有部分CA將OCSP失敗後的策略寫到證書的擴展字段中，用用戶根據擴展字段去做處理。
OSCP方式有自己明顯的缺陷，為了驗證證書而請求OSCP的同時也將自己在什麽時候訪問了什麽服務也告訴了CA，CA利用我們的訪問數據作惡咋辦，還有OCSP的接口很慢的話不就拖慢了我們服務的相應數獨。為了解決這兩個問題各大CA廠商聯手推出了CRL方案。
CRL方案是將被吊銷的證書列表定期拉去到本機，壹般是幾天拉取壹次。在校驗證書時去本機列表中查找。
CA會在證書的擴展字段中寫入CRL更新的地址：
CRL也有自己明顯的確定，首先CRL是定期拉取的不能保證實時生效，然後CRL的列表壹般很大可能達到數M。
CRLSet是chrome自建自用的解決方案。google覺得CRL更新太慢了，每個CA都有自己的CRL並且CRL內容也太多了。於是自己搞了壹個CRLSet，將各大CA被吊銷的高風險證書添加到CRLSet中，chrome在校驗證書時可以去自己CRLSet中校驗。
CRLSet只有各個CA吊銷的證書的部分，大概包含所有吊銷證書的2%。
CRLSet的更新相對快壹些，最慢幾個小時就會從各個CA中更新壹次，CRLSet可以用在需要緊急吊銷證書的情況下讓吊銷快速生效。
CRLSet提供了 /agl/crlset-tools 工具來拉取和校驗證書是否在CRLSet中。
可以在 chrome://components/ 中更新chrome的CRLSet
客戶端向服務端發送hello請求，裏面包含了客戶端SSL/TSL的版本、支持的加密套件和壹個隨機數Random1
服務端收到客戶端的hello後，根據客服端支持的加密套件和自己支持的加密套件選擇出後面使用的加密和散列套件並返回給客戶端，同時返回的還有服務端生產的壹個隨機數 Random2
服務端向客戶端返回自己的證書，客戶端收到證書後通過校驗證書來信任服務端，並從證書中獲取到證書中的公鑰。
服務端在返回證書後會立即向客戶端發送該請求。不過該請求不是必須的，只有選擇的加密套件需要額外的參數是才會發送該請求交互參數。
如果密鑰協議商算法是DH算法，那麽DH的參數就在該請求中返回給客戶端，DH算法有以下幾種：DHE_DSS、DHE_RSA、ECDHE_ECDSAECDHE_RSA
dh算法會返回dh的參數p、g、dh的公鑰和公鑰的簽名，公鑰即g^b mod p，b為服務端的隨機數
這裏g就是0X03，p就是0X0017。
服務端在發送完上述信息後，就會立馬發送Server Hello Done，來告知客戶端服務端的相關信息已經發送完畢，就等客戶端開始做密鑰協商了。
客戶端在收到該消息後就開始驗證證書，協商密鑰等工作。
在接受到服務器的Server Hello Done信息之後，客戶端會計數出預備主密鑰，並將其返回給服務端。
如果使用的是RSA/ECDSA算法，那麽發送的就是預備主密鑰。
如果使用的是DH算法，那麽發送的就是通過之前的參數計數出來的公鑰匙，即B（ g^b mod p）服務端在收到B後通過 B ^ a mod p得到第三個隨機數。而客戶端已經通過s = A b mod 得到了s。
到了這裏服務端和客戶端已經得到了三個隨機數，通過之前協商好的加密算法使用這個三個隨機數就得到壹個對稱加密的密鑰，後面通信時就使用該密鑰。
該請求用於通知對方已經計數出通信用的密鑰，接下來的通信都使用該密鑰進行。服務端和客戶端都會發出該請求，壹般是服務端先發出。
在完成上述步驟以後，雙發都會發送壹個Finished請求給對方，Finished的數據是通過協商好的密鑰加密的，以此來驗證之前協商好的密鑰、協議版本是否是有效的。
參考資料：