HTTPS为什么安全 分析 HTTPS 连接建立全过程
本文將分兩個專題去理解HTTPS。
專題一：HTTPS為什么安全
1、http為什么不安全？
http協(xié)議屬于明文傳輸協(xié)議，交互過程以及數(shù)據(jù)傳輸都沒有進行加密，通信雙方也沒有進行任何認證，通信過程非常容易遭遇劫持、監(jiān)聽、篡改，嚴重情況下，會造成惡意的流量劫持等問題，甚至造成個人隱私泄露（比如銀行卡卡號和密碼泄露）等嚴重的安全問題。
可以把http通信比喻成寄送信件一樣，A給B寄信，信件在寄送過程中，會經過很多的郵遞員之手，他們可以拆開信讀取里面的內容（因為http是明文傳輸?shù)?#xff09;。A的信件里面的任何內容（包括各類賬號和密碼）都會被輕易竊取。除此之外，郵遞員們還可以偽造或者修改信件的內容，導致B接收到的信件內容是假的。
比如常見的，在http通信過程中，“中間人”將廣告鏈接嵌入到服務器發(fā)給用戶的http報文里，導致用戶界面出現(xiàn)很多不良鏈接；?或者是修改用戶的請求頭URL，導致用戶的請求被劫持到另外一個網站，用戶的請求永遠到不了真正的服務器。這些都會導致用戶得不到正確的服務，甚至是損失慘重。
2、https如何保證安全？
要解決http帶來的問題，就要引入加密以及身份驗證機制。
如果Server（以后簡稱服務器）給Client（以后簡稱?客戶端）的消息是密文的，只有服務器和客戶端才能讀懂，就可以保證數(shù)據(jù)的保密性。同時，在交換數(shù)據(jù)之前，驗證一下對方的合法身份，就可以保證通信雙方的安全。那么，問題來了，服務器把數(shù)據(jù)加密后，客戶端如何讀懂這些數(shù)據(jù)呢？這時服務器必須要把加密的密鑰（對稱密鑰，后面會詳細說明）告訴客戶端，客戶端才能利用對稱密鑰解開密文的內容。但是，服務器如果將這個對稱密鑰以明文的方式給客戶端，還是會被中間人截獲，中間人也會知道對稱密鑰，依然無法保證通信的保密性。但是，如果服務器以密文的方式將對稱密鑰發(fā)給客戶端，客戶端又如何解開這個密文，得到其中的對稱密鑰呢？
說到這里，大家是不是有點兒糊涂了？一會兒密鑰，一會兒對稱密鑰，都有點兒被搞暈的節(jié)奏。在這里，提前給大家普及一下，這里的密鑰，指的是非對稱加解密的密鑰，是用于TLS握手階段的；?對稱密鑰，指的是對稱加解密的密鑰，是用于后續(xù)傳輸數(shù)據(jù)加解密的。下面將詳細說明。
這時，我們引入了非對稱加解密的概念。在非對稱加解密算法里，公鑰加密的數(shù)據(jù)，有且只有唯一的私鑰才能夠解密，所以服務器只要把公鑰發(fā)給客戶端，客戶端就可以用這個公鑰來加密進行數(shù)據(jù)傳輸?shù)膶ΨQ密鑰?？蛻舳死霉€將對稱密鑰發(fā)給服務器時，即使中間人截取了信息，也無法解密，因為私鑰只部署在服務器，其他任何人都沒有私鑰，因此，只有服務器才能夠解密。服務器拿到客戶端的信息并用私鑰解密之后，就可以拿到加解密數(shù)據(jù)用的對稱密鑰，通過這個對稱密鑰來進行后續(xù)通信的數(shù)據(jù)加解密。除此之外，非對稱加密可以很好的管理對稱密鑰，保證每次數(shù)據(jù)加密的對稱密鑰都是不相同的，這樣子的話，即使客戶端病毒拉取到通信緩存信息，也無法竊取正常通信內容。
上述通信過程，可以畫成以下交互圖：
但是這樣似乎還不夠，如果通信過程中，在三次握手或者客戶端發(fā)起HTTP請求過程中，客戶端的請求被中間人劫持，那么中間人就可以偽裝成“假冒客戶端”和服務器通信；中間人又可以偽裝成“假冒服務器”和客戶端通信。接下來，我們詳細闡述中間人獲取對稱密鑰的過程：
中間人在收到服務器發(fā)送給客戶端的公鑰（這里是“正確的公鑰”）后，并沒有發(fā)給客戶端，而是中間人將自己的公鑰（這里中間人也會有一對公鑰和私鑰，這里稱呼為“偽造公鑰”）發(fā)給客戶端。之后，客戶端把對稱密鑰用這個“偽造公鑰”加密后，發(fā)送過程中經過了中間人，中間人就可以用自己的私鑰解密數(shù)據(jù)并拿到對稱密鑰，此時中間人再把對稱密鑰用“正確的公鑰”加密發(fā)回給服務器。此時，客戶端、中間人、服務器都擁有了一樣的對稱密鑰，后續(xù)客戶端和服務器的所有加密數(shù)據(jù)，中間人都可以通過對稱密鑰解密出來。
中間人獲取對稱密鑰的過程如下：
為了解決此問題，我們引入了數(shù)字證書的概念。服務器首先生成公私鑰，將公鑰提供給相關機構（CA），CA將公鑰放入數(shù)字證書并將數(shù)字證書頒布給服務器，此時服務器就不是簡單的把公鑰給客戶端，而是給客戶端一個數(shù)字證書，數(shù)字證書中加入了一些數(shù)字簽名的機制，保證了數(shù)字證書一定是服務器給客戶端的。中間人發(fā)送的偽造證書，不能夠獲得CA的認證，此時，客戶端和服務器就知道通信被劫持了。加入了CA數(shù)字簽名認證的SSL會話過程如下所示：
所以綜合以上三點：非對稱加密算法（公鑰和私鑰）交換對稱密鑰+數(shù)字證書驗證身份（驗證公鑰是否是偽造的）+利用對稱密鑰加解密后續(xù)傳輸?shù)臄?shù)據(jù)=安全
3、https協(xié)議簡介
為什么是簡單地介紹https協(xié)議呢？因為https涉及的東西實在太多了，尤其是其中的加解密算法，十分復雜，作者本身對這些算法也研究不完，只是懂其中的一些皮毛而已。這部分僅僅是簡單介紹一些關于https的最基本原理，為后面分析https的建立過程以及https優(yōu)化等內容打下理論基礎。
3.1?對稱加密算法
對稱加密是指：加密和解密使用相同密鑰的算法。它要求發(fā)送方和接收方在安全通信之前，商定一個對稱密鑰。對稱算法的安全性完全依賴于密鑰，密鑰泄漏就意味著任何人都可以對他們發(fā)送或接收的消息解密，所以密鑰的保密性對通信至關重要。
3.1.1?對稱加密又分為兩種模式：流加密和分組加密
流加密是將消息作為字節(jié)流對待，并且使用數(shù)學函數(shù)分別作用在每一個字節(jié)位上。使用流加密時，每加密一次，相同的明文位會轉換成不同的密文位。流加密使用了密鑰流生成器，它生成的字節(jié)流與明文字節(jié)流進行異或，從而生成密文。
分組加密是將消息劃分為若干個分組，這些分組隨后會通過數(shù)學函數(shù)進行處理，每次一個分組。假設使用64位的分組密碼，此時如果消息長度為640位，就會被劃分成10個64位的分組（如果最后一個分組長度不到64，則用0補齊之后加到64位），每個分組都用一系列數(shù)學公式進行處理，最后得到10個加密文本分組。然后，將這條密文消息發(fā)送給對端。對端必須擁有相同的分組密碼，以相反的順序對10個密文分組使用前面的算法解密，最終得到明文消息。比較常用的分組加密算法有DES、3DES、AES。其中DES是比較老的加密算法，現(xiàn)在已經被證明不安全。而3DES是一個過渡的加密算法，相當于在DES基礎上進行三重運算來提高安全性，但其本質上還是和DES算法一致。而AES是DES算法的替代算法，是現(xiàn)在最安全的對稱加密算法之一。
3.1.2?對稱加密算法的優(yōu)缺點：
優(yōu)點：計算量小、加密速度快、加密效率高。
缺點：
（1）交易雙方都使用同樣密鑰，安全性得不到保證；
（2）每次使用對稱加密算法時，都需要使用其他人不知道的惟一密鑰，這會使得發(fā)收信息雙方所擁有的鑰匙數(shù)量呈幾何級數(shù)增長，密鑰管理成為負擔。
3.2?非對稱加密算法
在非對稱密鑰交換算法出現(xiàn)以前，對稱加密的最主要缺陷就是不知道如何在通信雙方之間傳輸對稱密鑰，而又不讓中間人竊取。非對稱密鑰交換算法誕生之后，專門針對對稱密鑰傳輸做加解密，使得對稱密鑰的交互傳輸變得非常安全了。
非對稱密鑰交換算法本身非常復雜，密鑰交換過程涉及到隨機數(shù)生成，模指數(shù)運算，空白補齊，加密，簽名等等一系列極其復雜的過程，作者本人也沒有研究完全透徹。常見的密鑰交換算法有RSA，ECDHE，DH，DHE等算法。涉及到比較復雜的數(shù)學問題。其中，最經典也是最常用的是RSA算法。
RSA：誕生于1977年，經過了長時間的破解測試，算法安全性很高，最重要的是，算法實現(xiàn)非常簡單。缺點就是需要比較大的質數(shù)（目前常用的是2048位）來保證安全強度，極其消耗CPU運算資源。RSA是目前唯一一個既能用于密鑰交換又能用于證書簽名的算法，RSA?是最經典，同時也是最常用的是非對稱加解密算法。
3.2.1?非對稱加密相比對稱加密更加安全，但也存在兩個致命的缺點：
（1）CPU計算資源消耗非常大。一次完全TLS握手，密鑰交換時的非對稱解密計算量占整個握手過程的90%以上。而對稱加密的計算量只相當于非對稱加密的0.1%。如果后續(xù)的應用層數(shù)據(jù)傳輸過程也使用非對稱加解密，那么CPU性能開銷太龐大，服務器是根本無法承受的。賽門特克給出的實驗數(shù)據(jù)顯示，加解密同等數(shù)量的文件，非對稱算法消耗的CPU資源是對稱算法的1000倍以上。
（2）非對稱加密算法對加密內容的長度有限制，不能超過公鑰長度。比如現(xiàn)在常用的公鑰長度是2048位，意味著待加密內容不能超過256個字節(jié)。
所以非對稱加解密（極端消耗CPU資源）目前只能用來作對稱密鑰交換或者CA簽名，不適合用來做應用層內容傳輸?shù)募咏饷堋?/span>
3.3?身份認證
https協(xié)議中身份認證的部分是由CA數(shù)字證書完成的，證書由公鑰、證書主體、數(shù)字簽名等內容組成。在客戶端發(fā)起SSL請求后，服務端會將數(shù)字證書發(fā)給客戶端，客戶端會對證書進行驗證（驗證這張證書是否是偽造的？也就是公鑰是否是偽造的），如果證書不是偽造的，客戶端就獲取用于對稱密鑰交換的非對稱密鑰（獲取公鑰）。
3.3.1?數(shù)字證書有三個作用：
1、身份授權。確保瀏覽器訪問的網站是經過CA驗證的可信任的網站。
2、分發(fā)公鑰。每個數(shù)字證書都包含了注冊者生成的公鑰（驗證確保是合法的，非偽造的公鑰）。在SSL握手時會通過certificate消息傳輸給客戶端。
3、驗證證書合法性?？蛻舳私邮盏綌?shù)字證書后，會對證書合法性進行驗證。只有驗證通過后的證書，才能夠進行后續(xù)通信過程。
3.3.2?申請一個受信任的CA數(shù)字證書通常有如下流程：
（1）公司（實體）的服務器生成公鑰和私鑰，以及CA數(shù)字證書請求。
（2）RA（證書注冊及審核機構）檢查實體的合法性（在注冊系統(tǒng)里面是否注冊過的正規(guī)公司）。
（3）CA（證書簽發(fā)機構）簽發(fā)證書，發(fā)送給申請者實體。
（4）證書更新到repository（負責數(shù)字證書及CRL內容存儲和分發(fā)），實體終端后續(xù)從repository更新證書，查詢證書狀態(tài)等。
3.4?數(shù)字證書驗證
申請者拿到CA的證書并部署在網站服務器端，那瀏覽器發(fā)起握手并接收到證書后，如何確認這個證書就是CA簽發(fā)的呢？怎樣避免第三方偽造這個證書？答案就是數(shù)字簽名（digital?signature）。數(shù)字簽名是證書的防偽標簽，目前使用最廣泛的SHA-RSA（SHA用于哈希算法，RSA用于非對稱加密算法）。數(shù)字簽名的制作和驗證過程如下：
1、數(shù)字簽名的簽發(fā)。首先是使用哈希函數(shù)對待簽名內容進行安全哈希，生成消息摘要，然后使用CA自己的私鑰對消息摘要進行加密。
2、數(shù)字簽名的校驗。使用CA的公鑰解密簽名，然后使用相同的簽名函數(shù)對簽名證書內容進行簽名，并和服務端數(shù)字簽名里的簽名內容進行比較，如果相同就認為校驗成功。
需要注意的是：
（1）數(shù)字簽名簽發(fā)和校驗使用的非對稱密鑰是CA自己的公鑰和私鑰，跟證書申請者（提交證書申請的公司實體）提交的公鑰沒有任何關系。
（2）數(shù)字簽名的簽發(fā)過程跟公鑰加密的過程剛好相反，即是用私鑰加密，公鑰解密。（一對公鑰和私鑰，公鑰加密的內容只有私鑰能夠解密；反過來，私鑰加密的內容，也就有公鑰才能夠解密）
（3）現(xiàn)在大的CA都會有證書鏈，證書鏈的好處：首先是安全，保持CA的私鑰離線使用。第二個好處是方便部署和撤銷。這里為啥要撤銷呢？因為，如果CA數(shù)字證書出現(xiàn)問題（被篡改或者污染），只需要撤銷相應級別的證書，根證書依然是安全的。
（4）根CA證書都是自簽名，即用自己的公鑰和私鑰完成了簽名的制作和驗證。而證書鏈上的證書簽名都是使用上一級證書的非對稱密鑰進行簽名和驗證的。
（5）怎樣獲取根CA和多級CA的密鑰對？還有，既然是自簽名和自認證，那么它們是否安全可信？這里的答案是：當然可信，因為這些廠商跟瀏覽器和操作系統(tǒng)都有合作，它們的根公鑰都默認裝到了瀏覽器或者操作系統(tǒng)環(huán)境里。
3.5?數(shù)據(jù)完整性驗證
數(shù)據(jù)傳輸過程中的完整性使用MAC算法來保證。為了避免網絡中傳輸?shù)臄?shù)據(jù)被非法篡改，或者數(shù)據(jù)比特被污染，SSL利用基于MD5或SHA的MAC算法來保證消息的完整性（由于MD5在實際應用中存在沖突的可能性比較大，所以盡量別采用MD5來驗證內容一致性）。?MAC算法是在密鑰參與下的數(shù)據(jù)摘要算法，能將密鑰和任意長度的數(shù)據(jù)轉換為固定長度的數(shù)據(jù)。發(fā)送者在密鑰的作用下，利用MAC算法計算出消息的MAC值，并將其添加在需要發(fā)送的消息之后，并發(fā)送給接收者。接收者利用同樣的密鑰和MAC算法計算出消息的MAC值，并與接收到的MAC值比較。如果二者相同，則報文沒有改變；否則，報文在傳輸過程中被修改或者污染，接收者將丟棄該報文。?SHA也不能使用SHA0和SHA1，山東大學的王小云教授（很牛的一個女教授，大家有興趣可以上網搜索一下她的事跡）在2005年就宣布破解了?SHA-1完整版算法，并獲得了業(yè)內專家的認可。微軟和google都已經宣布16年及17年之后不再支持sha1簽名證書。
專題二：實際抓包分析
本文對百度搜索進行了兩次抓包，第一次抓包之前清理了瀏覽器的所有緩存；第二次抓包是在第一次抓包后的半分鐘內。
百度在2015年已經完成了百度搜索的全站https，這在國內https發(fā)展中具有重大的意義（目前BAT三大家中，只有百度宣稱自己完成了全站HTTPS）。所以這篇文章就以www.baidu.com為例進行分析。
同時，作者采用的是chrome瀏覽器，chrome支持SNI?（server?Name?Indication）?特性，對于HTTPS性能優(yōu)化有很大的用處。
注：SNI是為了解決一個服務器使用多個域名和證書的SSL/TLS擴展。一句話簡述它的工作原理就是：在和服務器建立SSL連接之前，先發(fā)送要訪問的域名（hostname），這樣服務器根據(jù)這個域名返回一個合適的證書。目前，大多數(shù)操作系統(tǒng)和瀏覽器都已經很好地支持SNI擴展，OpenSSL?0.9.8已經內置這一功能，新版的nginx和apache也支持SNI擴展特性。
本文抓包訪問的URL為：http://www.baidu.com/??
（如果是https://www.baidu.com/，則以下結果不一樣！）
抓包結果：
可以看到，百度采用以下策略：
（1）對于高版本瀏覽器，如果支持?https，且加解密算法在TLS1.0?以上的，都將所有?http請求重定向到?https請求
（2）對于https請求，則不變。
【詳細解析過程】
1、TCP三次握手
可以看到，我的電腦訪問的是http://www.baidu.com/，在初次建立三次握手的時候，?客戶端是去連接?8080端口的（我所在小區(qū)網絡總出口做了一層總代理，因此，客戶端實際和代理機做的三次握手，代理機再幫客戶端去連接百度服務器）
2、tunnel建立
由于小區(qū)網關設置了代理訪問，因此，在進行https訪問的時候，客戶端需要和代理機做"HTTPS?CONNECT?tunnel"?連接（關于"HTTPS?CONNECT?tunnel"連接，可以理解為：雖然后續(xù)的https請求都是代理機和百度服務器進行公私鑰連接和對稱密鑰交換，以及數(shù)據(jù)通信；但是，有了隧道連接之后，可以認為客戶端也在直接和百度服務器進行通信。）
fiddler抓包結果：
3、client?hello
3.1?隨機數(shù)
在客戶端問候中，有四個字節(jié)以Unix時間格式記錄了客戶端的協(xié)調世界時間（UTC）。協(xié)調世界時間是從1970年1月1日開始到當前時刻所經歷的秒數(shù)。在這個例子中，0x2516b84b就是協(xié)調世界時間。在他后面有28字節(jié)的隨機數(shù)（random_C），在后面的過程中我們會用到這個隨機數(shù)。
3.2?SID（Session ID）
如果出于某種原因，對話中斷，就需要重新握手。為了避免重新握手而造成的訪問效率低下，這時候引入了session?ID的概念，?session?ID的思想很簡單，就是每一次對話都有一個編號（session?ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且服務器有這個編號的記錄，雙方就可以重新使用已有的“對稱密鑰”，而不必重新生成一把。
因為我們抓包的時候，是幾個小時內第一次訪問https://www.baodu.com?，因此，這里并沒有Session?ID.（稍會兒我們會看到隔了半分鐘，第二次抓包就有這個Session?ID）??
session?ID是目前所有瀏覽器都支持的方法，但是它的缺點在于session?ID往往只保留在一臺服務器上。所以，如果客戶端的請求發(fā)到另一臺服務器（這是很有可能的，對于同一個域名，當流量很大的時候，往往后臺有幾十臺RS機在提供服務），就無法恢復對話。session?ticket就是為了解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支持。
3.3?密文族（Cipher?Suites）
RFC2246中建議了很多中組合，一般寫法是"密鑰交換算法-對稱加密算法-哈希算法，以“TLS_RSA_WITH_AES_256_CBC_SHA”為例：
（a）TLS為協(xié)議，RSA為密鑰交換的算法；
（b）AES_256_CBC是對稱加密算法（其中256是密鑰長度，CBC是分組方式）；
（c）SHA是哈希的算法。
瀏覽器支持的加密算法一般會比較多，而服務端會根據(jù)自身的業(yè)務情況選擇比較適合的加密組合發(fā)給客戶端。（比如綜合安全性以及速度、性能等因素）
3.4?Server_name擴展（一般瀏覽器也支持?SNI擴展）
當我們去訪問一個站點時，一定是先通過DNS解析出站點對應的ip地址，通過ip地址來訪問站點，由于很多時候一個ip地址是給很多的站點公用，因此如果沒有server_name這個字段，server是無法給與客戶端相應的數(shù)字證書的，Server_name擴展則允許服務器對瀏覽器的請求授予相對應的證書。
服務器回復
（包括Server?Hello，Certificate，Certificate?Status）
服務器在收到client?hello后，會回復三個數(shù)據(jù)包，下面分別看一下：
4、Server?Hello
4.1、我們得到了服務器的以Unix時間格式記錄的UTC和28字節(jié)的隨機數(shù)?（random_S）。
4.2、Seesion?ID，服務端對于session?ID一般會有三種選擇??（稍會兒我們會看到隔了半分鐘，第二次抓包就有這個Session?ID）：
（1）恢復的session?ID：我們之前在client?hello里面已經提到，如果client?hello里面的session?ID在服務端有緩存，服務端會嘗試恢復這個session；
（2）新的session?ID：這里又分兩種情況，第一種是client?hello里面的session?ID是空值，此時服務端會給客戶端一個新的session?ID，第二種是client?hello里面的session?ID此服務器并沒有找到對應的緩存，此時也會回一個新的session?ID給客戶端；
（3）NULL：服務端不希望此session被恢復，因此session?ID為空。
4.3、我們記得在client?hello里面，客戶端給出了多種加密族?Cipher，而在客戶端所提供的加密族中，服務端挑選了“TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”
（a）TLS為協(xié)議，RSA為密鑰交換的算法；
（b）AES_256_CBC是對稱加密算法（其中256是密鑰長度，CBC是分組方式）；
（c）SHA是哈希的算法。
這就意味著服務端會使用ECDHE-RSA算法進行密鑰交換，通過AES_128_GCM對稱加密算法來加密數(shù)據(jù)，利用SHA256哈希算法來確保數(shù)據(jù)完整性。
5、Certificate
在前面的https原理研究中，我們知道為了安全的將公鑰發(fā)給客戶端，服務端會把公鑰放入數(shù)字證書中并發(fā)給客戶端（數(shù)字證書可以自簽發(fā)，但是一般為了保證安全會有一個專門的CA機構簽發(fā)），所以這個報文就是數(shù)字證書，4097?bytes就是證書的長度。
我們打開這個證書，可以看到證書的具體信息，這個具體信息通過抓包報文的方式不是太直觀，可以在瀏覽器上直接看。（點擊chrome瀏覽器左上方的綠色鎖型按鈕）?
6、Server?Hello?Done
我們抓的包是將?Server?Hello?Done??和?server?key?exchage?合并的包：
7、客戶端驗證證書真?zhèn)涡?/span>
客戶端驗證證書的合法性，如果驗證通過才會進行后續(xù)通信，否則根據(jù)錯誤情況不同做出提示和操作，合法性驗證包括如下：
（1）證書鏈的可信性trusted?certificate?path，方法如前文所述；
（2）證書是否吊銷revocation，有兩類方式離線CRL與在線OCSP，不同的客戶端行為會不同；
（3）有效期expiry?date，證書是否在有效時間范圍；
（4）域名domain，核查證書域名是否與當前的訪問域名匹配，匹配規(guī)則后續(xù)分析；?
8、秘鑰交換
這個過程非常復雜，大概總結一下：
（1）首先，客戶端利用CA數(shù)字證書實現(xiàn)身份認證，利用非對稱加密協(xié)商對稱密鑰。
（2）客戶端會向服務器傳輸一個“pubkey”隨機數(shù)，服務器收到之后，利用特定算法生成另外一個“pubkey”隨機數(shù)，客戶端利用這兩個“pubkey”隨機數(shù)生成一個?pre-master?隨機數(shù)。
（3）客戶端利用自己在?client?hello?里面?zhèn)鬏數(shù)碾S機數(shù)?random_C，以及收到的?server?hello?里面的隨機數(shù)?random_S，外加?pre-master?隨機數(shù)，利用對稱密鑰生成算法生成?對稱密鑰enc_key：enc_key=Fuc(random_C,?random_S,?Pre-Master)
9、生成session?ticket
如果出于某種原因，對話中斷，就需要重新握手。為了避免重新握手而造成的訪問效率低下，這時候引入了session?ID的概念，?session?ID（以及session?ticke）的思想很簡單，就是每一次對話都有一個編號（session?ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且服務器有這個編號的記錄，雙方就可以重新使用已有的“對話密鑰”，而不必重新生成一把。
因為我們抓包的時候，是幾個小時內第一次訪問?https://www.baodu.com?首頁，因此，這里并沒有?Session?ID.（稍會兒我們會看到隔了半分鐘，第二次抓包就有這個Session?ID）?
session?ID是目前所有瀏覽器都支持的方法，但是它的缺點在于session?ID往往只保留在一臺服務器上。所以，如果客戶端的請求發(fā)到另一臺服務器，就無法恢復對話。session?ticket就是為了解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支持。
后續(xù)建立新的https會話，就可以利用?session?ID?或者?session?Tickets?，?對稱秘鑰可以再次使用，從而免去了?https?公私鑰交換、CA認證等等過程，極大地縮短?https?會話連接時間。
10、利用對稱秘鑰傳輸數(shù)據(jù)
三、半分鐘后，再次訪問百度：
有這些大的不同：
由于服務器和瀏覽器緩存了?Session?ID?和?Session?Tickets，不需要再進行?公鑰證書傳遞，CA認證，生成?對稱密鑰等過程，直接利用半分鐘前的對稱密鑰加解密數(shù)據(jù)進行會話。
1、Client?Hello
2、Server?Hello
總結
以上是生活随笔為你收集整理的HTTPS为什么安全 分析 HTTPS 连接建立全过程的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 关于1-n中缺失的1个数字算法的优化
- 下一篇： 过年不让放炮，我用Python实现了10