https加密套件版本

⑴ 加速ssl https 程序怎麼優化

主要響應速度，提升自己的加密套件版本，伺服器apache盡量使用最新，使用國內的伺服器就可以了。

⑵ 詳解https是如何確保安全的

（多文字預警）

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL

下面就是https的整個架構，現在的https基本都使用TLS了，因為更加安全，所以下圖中的SSL應該換為SSL/TLS。

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

對稱加密(也叫私鑰加密)指加密和解密使用相同密鑰的加密演算法。有時又叫傳統密碼演算法，就是加密密鑰能夠從解密密鑰中推算出來，同時解密密鑰也可以從加密密鑰中推算出來。而在大多數的對稱演算法中，加密密鑰和解密密鑰是相同的，所以也稱這種加密演算法為秘密密鑰演算法或單密鑰演算法。
常見的對稱加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA

與對稱加密演算法不同，非對稱加密演算法需要兩個密鑰：公開密鑰（publickey）和私有密鑰（privatekey）；並且加密密鑰和解密密鑰是成對出現的。非對稱加密演算法在加密和解密過程使用了不同的密鑰，非對稱加密也稱為公鑰加密，在密鑰對中，其中一個密鑰是對外公開的，所有人都可以獲取到，稱為公鑰，其中一個密鑰是不公開的稱為私鑰。

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

數字簽名技術就是對「非對稱密鑰加解密」和「數字摘要「兩項技術的應用，它將摘要信息用發送者的私鑰加密，與原文一起傳送給接收者。接收者只有用發送者的公鑰才能解密被加密的摘要信息，然後用HASH函數對收到的原文產生一個摘要信息，與解密的摘要信息對比。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數字簽名能夠驗證信息的完整性。
數字簽名的過程如下：
明文 --> hash運算 --> 摘要 --> 私鑰加密 --> 數字簽名

數字簽名有兩種功效：
一、能確定消息確實是由發送方簽名並發出來的，因為別人假冒不了發送方的簽名。
二、數字簽名能確定消息的完整性。

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

用戶首先產生自己的密鑰對，並將公共密鑰及部分個人身份信息傳送給認證中心。認證中心在核實身份後，將執行一些必要的步驟，以確信請求確實由用戶發送而來，然後，認證中心將發給用戶一個數字證書，該證書內包含用戶的個人信息和他的公鑰信息，同時還附有認證中心的簽名信息(根證書私鑰簽名)。用戶就可以使用自己的數字證書進行相關的各種活動。數字證書由獨立的證書發行機構發布，數字證書各不相同，每種證書可提供不同級別的可信度。

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

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

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

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

用於兩個應用程序之間提供保密性和數據完整性。
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握手整個過程如下圖所示，下面會詳細介紹每一步的具體內容：

由於客戶端(如瀏覽器)對一些加解密演算法的支持程度不一樣，但是在TLS協議傳輸過程中必須使用同一套加解密演算法才能保證數據能夠正常的加解密。在TLS握手階段，客戶端首先要告知服務端，自己支持哪些加密演算法，所以客戶端需要將本地支持的加密套件(Cipher Suite)的列表傳送給服務端。除此之外，客戶端還要產生一個隨機數，這個隨機數一方面需要在客戶端保存，另一方面需要傳送給服務端，客戶端的隨機數需要跟服務端產生的隨機數結合起來產生後面要講到的 Master Secret 。

客戶端需要提供如下信息：

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

服務端需要提供的信息：

客戶端首先會對伺服器下發的證書進行驗證，驗證通過之後，則會繼續下面的操作，客戶端再次產生一個隨機數（第三個隨機數），然後使用伺服器證書中的公鑰進行加密，以及放一個ChangeCipherSpec消息即編碼改變的消息，還有整個前面所有消息的hash值，進行伺服器驗證，然後用新秘鑰加密一段數據一並發送到伺服器，確保正式通信前無誤。
客戶端使用前面的兩個隨機數以及剛剛新生成的新隨機數，使用與伺服器確定的加密演算法，生成一個Session Secret。

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

後續客戶端與伺服器間通信
確定秘鑰之後，伺服器與客戶端之間就會通過商定的秘鑰加密消息了，進行通訊了。整個握手過程也就基本完成了。

對於非常重要的保密數據，服務端還需要對客戶端進行驗證，以保證數據傳送給了安全的合法的客戶端。服務端可以向客戶端發出 Cerficate Request 消息，要求客戶端發送證書對客戶端的合法性進行驗證。比如，金融機構往往只允許認證客戶連入自己的網路，就會向正式客戶提供USB密鑰，裡面就包含了一張客戶端證書。

PreMaster secret前兩個位元組是TLS的版本號，這是一個比較重要的用來核對握手數據的版本號，因為在Client Hello階段，客戶端會發送一份加密套件列表和當前支持的SSL/TLS的版本號給服務端，而且是使用明文傳送的，如果握手的數據包被破解之後，攻擊者很有可能串改數據包，選擇一個安全性較低的加密套件和版本給服務端，從而對數據進行破解。所以，服務端需要對密文中解密出來對的PreMaster版本號跟之前Client Hello階段的版本號進行對比，如果版本號變低，則說明被串改，則立即停止發送任何消息。

有兩種方法可以恢復原來的session：一種叫做session ID，另一種叫做session ticket。

session ID
session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且伺服器有這個編號的記錄，雙方就可以重新使用已有的」對話密鑰」，而不必重新生成一把。

session ticket
客戶端發送一個伺服器在上一次對話中發送過來的session ticket。這個session ticket是加密的，只有伺服器才能解密，其中包括本次對話的主要信息，比如對話密鑰和加密方法。當伺服器收到session ticket以後，解密後就不必重新生成對話密鑰了。

總結
https實際就是在TCP層與http層之間加入了SSL/TLS來為上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書，等技術進行客戶端與伺服器的數據加密傳輸，最終達到保證整個通信的安全性。

收錄自| 原文地址

⑶ https詳解

TCP三次握手；
TLS/SSL的連接；
HTTP的請求和響應；

前提介紹（證書校驗）
服務端傳遞一個證書，客戶端是怎麼來驗證其中是沒有問題的
1.證書大致包含了哪些數據？
證書的申請者，證書的頒發者，證書的有效期，證書的公鑰，證書的指紋，證書的指紋演算法，證書的數字簽名

2.如何驗證證書是否是完整的？
1.首先根據該證書的頒發者找到對應的頒發者的公鑰對該證書的數字簽名進行解密，然後得到一個證書的指紋和證書的指紋演算法；
2根據證書的指紋演算法對整個證書進行加密得到指紋；
3對比兩個指紋，如果一致說明證書是完整的；

3如何驗證證書是否是被全部替換？
在請求網路的時候，可以對比下請求的Url和證書的Url，如果不一致的話，說明證書被全部替換，一致的話說明是正確的證書；

Tcp的三次握手之前的文檔已經介紹了，現在來介紹下TLS/SSL的連接過程；

1.客戶端->服務端 （安全協議和版本（SSL和TSL）， 客戶端支持的所有的加密套件列表，client Random）；
2服務端->客戶端 （安全協議和版本（SSL和TSL），服務端選中的加密套件， server Random， 證書， 秘鑰交換服務端的參數）
客戶端會去驗證該證書的有效性
3.客戶端->服務端 （秘鑰交換客戶端的參數）
這個時候雙方都含有了四個數據（client Random， server Random ， 秘鑰交換客戶端參數和服務端參數）；
根據後面兩個參數等到預主秘鑰（Pre-master secret）；
最後三個參數生成用以加密會話的會話秘鑰；
4.客戶端->服務端 （告訴後台去採用會話秘鑰去加密）；
5.客戶端->服務端（使用會話秘鑰對之前的的全部報文進行加密，然後傳遞到服務端）
6.服務端->客戶端（使用會話秘鑰加密解密，然後結束這段握手，進行之後的htpp請求和響應）

⑷ HTTPS的前世今生和原理詳解

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提供了 https://github.com/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的數據是通過協商好的密鑰加密的，以此來驗證之前協商好的密鑰、協議版本是否是有效的。

參考資料：

⑸ 如何查看本機能夠支持的https加密演算法套件

HTTPS加密演算法，來自於簽發機構的SSL證書CSR文件，也就是說簽發完畢的證書加密演算法，就一定定向了，您可以打開這個網站，就說明就是支持，演算法：sha256 加密位數：2048，是證書常見的標准，你可以打開網路知道，就說明支持的。

⑹ 溫故而知新之HTTPS

對於HTTPS其實很早之前就有過學習，但對其一直是一知半解，知道的並不深入全面，因此用了些時間，好好地閱讀了極客時間關於HTTPS的一些專欄，並總結一下嘗試著用自己的話來描述一下。

HTTP最初的目的：傳輸超文本文件，因此一直是明文傳輸文件，而且不安全。由於是明文傳輸，所以就很容易被中間人所截取，一切通信的內容也被這個中間人所掌握。這也就是常說的中間人攻擊。

那如何定義通信過程是安全的呢：機密性，完整性，身份驗證以及不可否認：

機密性：簡單來說就是數據是加密過的，除了參與通信之外的人都是都是看不了的。

完整性：數據在通信的過程中是完整的，沒加經過篡改的。

身份認證：通信雙方可以驗證對方的真實身份

不可否認：不能否認已經發生過的行為

因為是明文傳輸，所以在一些對安全要求高的場景就不能很好的滿足需求，因此在原有的基礎上引入了加密方案，在TCP和HTTP之間加入了一個安全層SSL/TLS

SSL全名叫Secure Sockets Layer中文名叫 安全套接層，在 OSI 模型中儲運第五層會話層的位置。這玩意兒是由網景公司所發明，並在其發展到 V3 的時候被 IETF 改名為 TLC（Transport Layer Security），並對其進行標准化。而 TLS 發展到現在也經歷了三個版本，最新的版本是2018年所制定的，牢牢的將密碼學的發展與當今互聯網的現狀相結合，持續提高安全與性能，因此也成為信息安全領域的權威標准。

而它的職責也很簡單：

當瀏覽器客戶端和服務端在使用 TLS 進行通信時，需要選擇一組合理的加密演算法來實現安全通信，而這些演算法的組合通常被稱為：加密套件。它的命名是很規范的，基本形式就是：密鑰交換演算法 + 簽名演算法 + 對稱加密演算法 + 摘要演算法。其中，簽名演算法可以進行身份驗證，摘要演算法可以保證數據的完整性，而對稱加密演算法則可以保證數據的機密性。（值得注意的是，在2019年不安全的 TLS 1.0 和 1.1 默認被禁用（ Safari TP 91 、Google Chrome 72+、Firefox Nightly）

前面我們提到，HTTP協議在進行傳輸的時候是通過明文進行傳輸的，因此不安全。那麼如果需要保證傳輸信息的機密性，最簡單的方法不外於將其進行加密，這樣第三方的人在拿到這些信息的時候，也就不能獲取信息裡面的內容了。因此這就引入了加密的第一個概念：對稱加密。

對稱加密其實很簡單：加密和解密都使用的是相同的密鑰，是對稱的，這里的密鑰就是用於解開加密信息的鑰匙。

簡單來說就是客戶端會給服務端發送它支持的加密的方法的列表，以及一個隨機數，然後伺服器端在接受到這些東西後，會從客戶端所支持的加密方法列表中選取一種，然後同時生成一個隨機數給客戶端，這樣兩端就都確定了加密方法和隨機數，也就可以通過這些信息來生成對應的密鑰了。這樣做的話即使黑客在獲取到瀏覽器與伺服器所傳輸的信息，得到的也只是一串亂碼，而他也沒有相應的密鑰，也就保證了信息傳輸的機密性。

TLS中所提供的對稱加密演算法有很多，其中最常用的當屬 AES（Advanced Encryption Standard）既高級加密標准，密鑰的長度可以是128，192，256，是當今用的最為廣泛的對稱加密演算法。當然除了上面這個AES之外，我們國家也存在這自己的一套對稱加密演算法：SM1 和 SM4。其中SM1演算法不公開，屬於國家機密，而 SM4 則是公開的，可以自行使用，這兩個演算法的最大的優勢就在於：國家支持！

對稱加密還有一個分組的概念，他可以讓演算法用固定的長度的密鑰加密任意長度的明文，從而將密鑰轉化為密文。最新的分組模式叫做AEAD，在加密的同時還增加了認證的功能。

對稱加密就是通過上面的這些東西，來完成一個簡單卻安全的加密方式的。

對稱加密看起來的確是解決了我們所說的安全要素中的機密性的要求，但它仍然存在一個致命的漏洞就是：密鑰交互的方式仍然是明文的。也正是為了解決密鑰安全的問題，我們就需要使用非堆成加密的方法，那什麼是非堆成加密呢？非對稱加密簡單來說就是有兩把私鑰，一把是公鑰，可以公開給任何人使用，一把是私鑰，需要嚴格保密。這就形成了一個非對稱性。具體舉個栗子來講就是：有 A、B 兩把密鑰，如果你用 A 密鑰來加密，那麼只能使用 B 密鑰來解密；反過來，如果你要 B 密鑰來加密，那麼只能用 A 密鑰來解密。

非對稱加密除了可以對信息進行加密外，很多非對稱加密演算法還有簽名的功能，這樣就可以提供身份認證，保證通信雙方可以確定對面的身份。

而從實現上來講，所有的非對稱加密演算法，都是基於各種數學難題來設計實現的，這些難題的特點在於：正向計算很簡單，反向推倒是無解的。其中比較經典的非對稱加密演算法包括：RSA，ECC以及SM2。

RSA 是所使用的數學難題是：兩個大的質數相乘的結果很容易計算，但根據這個結果去做質因分解得到原先的兩個質數，則需要很大的計算量。就比如這個：

https://lists.gforge.inria.fr/pipermail/cado-nfs-discuss/2019-December/001139.html 。

前段時間美國一群大佬宣布，240哥十進制的整數分解成功，找到了它的兩個大質數因子，不過這個成本也是很大的。

ECC和 SM2 都是是基於橢圓曲線的數學難題設計的。普遍的觀點認為，橢圓曲線的難度高於大質數難題，160 位密鑰的 ECC 加密強度，相當於 1088 位密鑰的 RSA。因為密鑰短，所以相應的計算量、消耗的內存和帶寬也就少，加密解密的性能就上去了，因此對於互聯網行業來講吸引力也是相當大的。而SM2除了加密強度和國際標准和ECC差不多以外，還屬於國家所支持的非對稱加密演算法。

需要注意的是，非對稱加密的安全性上雖然可以滿足我們的需求，但它卻存在這一個比較大的問題就是L：性能。由於非對稱加密在所需要的演算法運算非常復雜，因此在性能上得不到很好的保證。也正是由於這個原因，現在的TLS主要採用的是一種叫混合加密的方式來進行加密。

混合加密其實很簡單，就是使用非對稱加密的方式，解決密鑰交換的問題，然後用隨機數產生對稱演算法使用的會話密鑰，在對其使用公鑰加密，並傳送給通信對象。通信對象拿到密文後用私鑰解開並取出會話密鑰。這樣就是實現了堆成密鑰的安全交換了，後續就可以使用這個對稱密鑰來進行對稱加密。

在前面我們有提到過安全的幾大要素，其中機密性我們可以通過上面的對稱加密 + 非對稱加密來解決。而在完整性方面，我們則需要使用摘要演算法來解決。

簡單理解，我們可以將摘要演算法理解為一種特殊的壓縮演算法，他可以將任意長度的數據壓縮成固定長度且獨一無二的摘要字元串，且這個加密的過程也是單向的，加密後的數據無法解密，不能從摘要中反向推出原文。

https://time.geekbang.org/column/article/176569

https://time.geekbang.org/column/intro/189 ——安全篇

⑺ 詳解https是如何確保系統安全的

• https協議需要到CA申請證書。

• http是超文本傳輸協議，信息是明文傳輸；https 則是具有安全性的ssl加密傳輸協議。

• http和https使用的是完全不同的連接方式，用的埠也不一樣，前者是80，後者是443。

• http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全。

http默認使用80埠，https默認使用443埠

下面就是https的整個架構，現在的https基本都使用TLS了，因為更加安全，所以下圖中的SSL應該換為SSL/TLS。

客戶端首次發出請求

由於客戶端(如瀏覽器)對一些加解密演算法的支持程度不一樣，但是在TLS協議傳輸過程中必須使用同一套加解密演算法才能保證數據能夠正常的加解密。在TLS握手階段，客戶端首先要告知服務端，自己支持哪些加密演算法，所以客戶端需要將本地支持的加密套件(Cipher Suite)的列表傳送給服務端。除此之外，客戶端還要產生一個隨機數，這個隨機數一方面需要在客戶端保存，另一方面需要傳送給服務端，客戶端的隨機數需要跟服務端產生的隨機數結合起來產生後面要講到的 Master Secret 。

客戶端需要提供如下信息：

• 支持的協議版本，比如TLS 1.0版

• 一個客戶端生成的隨機數，稍後用於生成」對話密鑰」

• 支持的加密方法，比如RSA公鑰加密

• 支持的壓縮方法

服務端首次回應

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

服務端需要提供的信息：

• 協議的版本

• 加密的演算法

• 隨機數

• 伺服器證書

客戶端再次回應

客戶端首先會對伺服器下發的證書進行驗證，驗證通過之後，則會繼續下面的操作，客戶端再次產生一個隨機數（第三個隨機數），然後使用伺服器證書中的公鑰進行加密，以及放一個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來為上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書，等技術進行客戶端與伺服器的數據加密傳輸，最終達到保證整個通信的安全性。

⑻ https加密是什麼意思呢

HTTPS （全稱：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全為目標的HTTP通道，在HTTP的基礎上通過傳輸加密和身份認證保證了傳輸過程的安全性 。HTTPS在HTTP的基礎下加入SSL層，HTTPS 的安全基礎是SSL，因此加密的詳細內容就需要SSL。 HTTPS 存在不同於 HTTP 的默認埠及一個加密/身份驗證層（在HTTP與 TCP 之間）。

⑼ https交互過程

在這里整理一下最近這兩天整理的https的相關知識。

大家都知道要使用https，需要在網站的伺服器上配置https證書（一般是nginx，或者tomcat），證書可以使用自己生成，也可以向專門的https證書提供商進行購買。這兩種的區別是自己生成的證書是不被瀏覽器信任的,所以當訪問的時候回提示不安全的網站，需要點擊信任之後才能繼續訪問

自己生成的

而購買的https證書會提示安全

DV,OV

EV

這是因為瀏覽器中預置了一些https證書提供商的證書，在瀏覽器獲取到伺服器的https證書進行驗證的時候就知道這個https證書是可信的；而自己生成的證書，瀏覽器獲取到之後無法進行驗證是否可信，所以就給出不安全的提示。

下面對具體的一些知識點進行介紹

1. 什麼是https

https簡單的說就是安全版的http，因為http協議的數據都是明文進行傳輸的，所以對於一些敏感信息的傳輸就很不安全，為了安全傳輸敏感數據，網景公司設計了SSL（Secure Socket Layer），在http的基礎上添加了一個安全傳輸層，對所有的數據都加密後再進行傳輸，客戶端和伺服器端收到加密數據後按照之前約定好的秘鑰解密。

2. 加密和解密

Https的發展和密碼學的發展是分不開的。大家應該知道加密方式可以大體分為對稱加密和非對稱加密（反正我就知道這兩種）

對稱加密，就是加密和解密都是用同一個秘鑰，這種方式優點就是速度快，缺點就是在管理和分配秘鑰的時候不安全。

非對稱加密演算法，非對稱加密有一個秘鑰對，叫做公鑰和私鑰，私鑰自己持有，公鑰可以公開的發送給使用的人。使用公鑰進行加密的信息，只有和其配對的私鑰可以解開。目前常見的非對稱加密演算法是RSA，非對稱的加密演算法的優點是安全，因為他不需要把私鑰暴露出去。

在正式的使用場景中一般都是對稱加密和非對稱加密結合使用，使用非對稱加密完成秘鑰的傳遞，然後使用對稱秘鑰進行數據加密和解密

3. https證書的申請流程

1 在伺服器上生成CSR文件（證書申請文件，內容包括證書公鑰、使用的Hash演算法、申請的域名、公司名稱、職位等信息）

可以使用命令在伺服器上生成；也可以使用線上的工具進行生成，線上的工具會把公鑰加入到CSR文件中，並同時生成私鑰。

CSR文件內容

2 把CSR文件和其他可能的證件上傳到CA認證機構，CA機構收到證書申請之後，使用申請中的Hash演算法，對部分內容進行摘要，然後使用CA機構自己的私鑰對這段摘要信息進行簽名，

CA機構進行簽名

3 然後CA機構把簽名過的證書通過郵件形式發送到申請者手中。

4 申請者收到證書之後部署到自己的web伺服器中。下面會在寫一篇關於部署的文章

當然這是不通過CA代理機構進行申請的流程，現在網上有好多CA的代理機構，像騰訊雲，阿里雲都可以申請https證書，流程都差不多。

阿里雲申請證書流程

4. 客戶端（瀏覽器）和伺服器端交互流程

客戶端服務端交互

client Hello,客戶端（通常是瀏覽器）先向伺服器發出加密通信的請求

（1） 支持的協議版本，比如TLS 1.0版。

（2） 一個客戶端生成的隨機數 random1，稍後用於生成"對話密鑰"。

（3） 支持的加密方法，比如RSA公鑰加密。

（4） 支持的壓縮方法。

伺服器收到請求,然後響應 (server Hello)

（1） 確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與伺服器支持的版本不一致，伺服器關閉加密通信。

（2） 一個伺服器生成的隨機數random2，稍後用於生成"對話密鑰"。

（3） 確認使用的加密方法，比如RSA公鑰加密。

（4） 伺服器證書。

證書內容

證書內容

客戶端收到證書之後會首先會進行驗證

驗證流程

我們知道CA機構在簽發證書的時候，都會使用自己的私鑰對證書進行簽名

證書里的簽名演算法欄位 sha256RSA 表示，CA機構使用sha256對證書進行摘要，然後使用RSA演算法對摘要進行私鑰簽名，而我們也知道RSA演算法中，使用私鑰簽名之後，只有公鑰才能進行驗簽。

如果我們使用的是購買的證書，那麼很有可能，頒發這個證書的CA機構的公鑰已經預置在操作系統中。這樣瀏覽器就可以使用CA機構的公鑰對伺服器的證書進行驗簽。確定這個證書是不是由正規的CA機構頒發的。驗簽之後得到CA機構使用sha256得到的證書摘要，然後客戶端再使用sha256對證書內容進行一次摘要，如果得到的值和驗簽之後得到的摘要值相同，則表示證書沒有被修改過。

如果驗證通過，就會顯示上面的安全字樣，如果伺服器購買的證書是更高級的EV類型，就會顯示出購買證書的時候提供的企業名稱。如果沒有驗證通過，就會顯示不安全的提示。

生成隨機數

驗證通過之後，客戶端會生成一個隨機數pre-master secret，然後使用證書中的公鑰進行加密，然後傳遞給伺服器端

PreMaster secret

PreMaster Secret是在客戶端使用RSA或者Diffie-Hellman等加密演算法生成的。它將用來跟服務端和客戶端在Hello階段產生的隨機數結合在一起生成 Master Secret。在客戶端使用服務端的公鑰對PreMaster Secret進行加密之後傳送給服務端，服務端將使用私鑰進行解密得到PreMaster secret。也就是說服務端和客戶端都有一份相同的PreMaster secret和隨機數。

PreMaster secret前兩個位元組是TLS的版本號，這是一個比較重要的用來核對握手數據的版本號，因為在Client Hello階段，客戶端會發送一份加密套件列表和當前支持的SSL/TLS的版本號給服務端，而且是使用明文傳送的，如果握手的數據包被破解之後，攻擊者很有可能串改數據包，選擇一個安全性較低的加密套件和版本給服務端，從而對數據進行破解。所以，服務端需要對密文中解密出來對的PreMaster版本號跟之前Client Hello階段的版本號進行對比，如果版本號變低，則說明被串改，則立即停止發送任何消息。

pre-master secret

伺服器收到使用公鑰加密的內容，在伺服器端使用私鑰解密之後獲得隨機數pre-master secret，然後根據radom1、radom2、pre-master secret通過一定的演算法得出session Key和MAC演算法秘鑰，作為後面交互過程中使用對稱秘鑰。同時客戶端也會使用radom1、radom2、pre-master secret，和同樣的演算法生成session Key和MAC演算法的秘鑰。

生成session Key的過程中會用到PRF(Pseudorandom Function偽隨機方法)來生成一個key_block,然後再使用key_block,生成後面使用的秘鑰。

key_block = PRF(SecurityParameters.master_secret,"key expansion",SecurityParameters.server_random +SecurityParameters.client_random);

PRF是在規范中約定的偽隨機函數

在信息交互過程中用到的秘鑰有6個分別是。客戶端和伺服器端分別使用相同的演算法生成。

秘鑰名稱秘鑰作用

client_write_MAC_key[SecurityParameters.mac_key_length]客戶端發送數據使用的摘要MAC演算法

server_write_MAC_key[SecurityParameters.mac_key_length]服務端發送數據使用摘要MAC演算法

client_write_key[SecurityParameters.enc_key_length]客戶端數據加密，服務端解密

server_write_key[SecurityParameters.enc_key_length]服務端加密，客戶端解密

client_write_IV[SecurityParameters.fixed_iv_length]初始化向量，運用於分組對稱加密

server_write_IV[SecurityParameters.fixed_iv_length]初始化向量，運用於分組對稱加密

然後再後續的交互中就使用session Key和MAC演算法的秘鑰對傳輸的內容進行加密和解密。

具體的步驟是先使用MAC秘鑰對內容進行摘要，然後把摘要放在內容的後面使用sessionKey再進行加密。對於客戶端發送的數據，伺服器端收到之後，需要先使用client_write_key進行解密，然後使用client_write_MAC_key對數據完整性進行驗證。伺服器端發送的數據，客戶端會使用server_write_key和server_write_MAC_key進行相同的操作。

鏈接：https://www.jianshu.com/p/b0b6b88fe9fe

⑽ 如何查看本機能夠支持的https加密演算法套件

WIN 2008 R2 IIS 7 以上版本
CentOS 6+ OpenSSL 1.0.1c+
Apache 2.4 +
Nginx 1.0.6+
JDK1.7
tomcat7.0.56+
(以上版本都可以）