如何進(jìn)行SSL/TLS原理分析

本篇文章給大家分享的是有關(guān)如何進(jìn)行SSL/TLS原理分析，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

1. SSL/TLS概覽

1.1 整體結(jié)構(gòu)

SSL是一個(gè)介于HTTP協(xié)議與TCP之間的一個(gè)可選層，其位置大致如下:

• SSL：（Secure Socket Layer，安全套接字層），為Netscape所研發(fā)，用以保障在Internet上數(shù)據(jù)傳輸之安全，利用數(shù)據(jù)加密(Encryption)技術(shù)，可確保數(shù)據(jù)在網(wǎng)絡(luò)上之傳輸過程中不會(huì)被截取。當(dāng)前版本為3.0。它已被廣泛地用于Web瀏覽器與服務(wù)器之間的身份認(rèn)證和加密數(shù)據(jù)傳輸。
  SSL協(xié)議位于TCP/IP協(xié)議與各種應(yīng)用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持。SSL協(xié)議可分為兩層： SSL記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。 SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上，用于在實(shí)際的數(shù)據(jù)傳輸開始前，通訊雙方進(jìn)行身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。

• TLS：(Transport Layer Security，傳輸層安全協(xié)議)，用于兩個(gè)應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。
  TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務(wù)組）制定的一種新的協(xié)議，它建立在SSL 3.0協(xié)議規(guī)范之上，是SSL 3.0的后續(xù)版本，可以理解為SSL 3.1，它是寫入了 RFC 的。該協(xié)議由兩層組成： TLS 記錄協(xié)議（TLS Record）和 TLS 握手協(xié)議（TLS Handshake）。較低的層為 TLS 記錄協(xié)議，位于某個(gè)可靠的傳輸協(xié)議（例如 TCP）上面。

SSL/TLS協(xié)議提供的服務(wù)主要有：

1. 認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器；

2. 加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊??；

3. 維護(hù)數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過程中不被改變。

1.2 TLS與SSL的差異

1. 版本號：TLS記錄格式與SSL記錄格式相同，但版本號的值不同，TLS的版本1.0使用的版本號為SSLv3.1。

2. 報(bào)文鑒別碼：SSLv3.0和TLS的MAC算法及MAC計(jì)算的范圍不同。TLS使用了RFC-2104定義的HMAC算法。SSLv3.0使用了相似的算法，兩者差別在于SSLv3.0中，填充字節(jié)與密鑰之間采用的是連接運(yùn)算，而HMAC算法采用的是異或運(yùn)算。但是兩者的安全程度是相同的。

3. 偽隨機(jī)函數(shù)：TLS使用了稱為PRF的偽隨機(jī)函數(shù)來將密鑰擴(kuò)展成數(shù)據(jù)塊，是更安全的方式。

4. 報(bào)警代碼：TLS支持幾乎所有的SSLv3.0報(bào)警代碼，而且TLS還補(bǔ)充定義了很多報(bào)警代碼，如解密失?。╠ecryption_failed）、記錄溢出（record_overflow）、未知CA（unknown_ca）、拒絕訪問（access_denied）等。

5. 密文族和客戶證書：SSLv3.0和TLS存在少量差別，即TLS不支持Fortezza密鑰交換、加密算法和客戶證書。

6. certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息計(jì)算MD5和SHA-1散列碼時(shí)，計(jì)算的輸入有少許差別，但安全性相當(dāng)。

7. 加密計(jì)算：TLS與SSLv3.0在計(jì)算主密值（master secret）時(shí)采用的方式不同。

8. 填充：用戶數(shù)據(jù)加密之前需要增加的填充字節(jié)。在SSL中，填充后的數(shù)據(jù)長度要達(dá)到密文塊長度的最小整數(shù)倍。而在TLS中，填充后的數(shù)據(jù)長度可以是密文塊長度的任意整數(shù)倍（但填充的最大長度為255字節(jié)），這種方式可以防止基于對報(bào)文長度進(jìn)行分析的攻擊。

TLS的主要增強(qiáng)內(nèi)容

TLS的主要目標(biāo)是使SSL更安全，并使協(xié)議的規(guī)范更精確和完善。TLS 在SSL v3.0 的基礎(chǔ)上，提供了以下增強(qiáng)內(nèi)容：

1. 更安全的MAC算法

2. 更嚴(yán)密的警報(bào)

3. “灰色區(qū)域”規(guī)范的更明確的定義

TLS對于安全性的改進(jìn)

1. 對于消息認(rèn)證使用密鑰散列法：TLS 使用“消息認(rèn)證代碼的密鑰散列法”（HMAC），當(dāng)記錄在開放的網(wǎng)絡(luò)（如因特網(wǎng)）上傳送時(shí)，該代碼確保記錄不會(huì)被變更。SSLv3.0還提供鍵控消息認(rèn)證，但HMAC比SSLv3.0使用的（消息認(rèn)證代碼）MAC 功能更安全。

2. 增強(qiáng)的偽隨機(jī)功能（PRF）：PRF生成密鑰數(shù)據(jù)。在TLS中，HMAC定義PRF。PRF使用兩種散列算法保證其安全性。如果任一算法暴露了，只要第二種算法未暴露，則數(shù)據(jù)仍然是安全的。

3. 改進(jìn)的已完成消息驗(yàn)證：TLS和SSLv3.0都對兩個(gè)端點(diǎn)提供已完成的消息，該消息認(rèn)證交換的消息沒有被變更。然而，TLS將此已完成消息基于PRF和HMAC值之上，這也比SSLv3.0更安全。

4. 一致證書處理：與SSLv3.0不同，TLS試圖指定必須在TLS之間實(shí)現(xiàn)交換的證書類型。

5. 特定警報(bào)消息：TLS提供更多的特定和附加警報(bào)，以指示任一會(huì)話端點(diǎn)檢測到的問題。TLS還對何時(shí)應(yīng)該發(fā)送某些警報(bào)進(jìn)行記錄。

2. 密鑰協(xié)商過程——TLS握手

SSL協(xié)議分為兩部分：Handshake Protocol和Record Protocol。其中Handshake Protocol用來協(xié)商密鑰，協(xié)議的大部分內(nèi)容就是通信雙方如何利用它來安全的協(xié)商出一份密鑰。 Record Protocol則定義了傳輸?shù)母袷健?/p>

由于非對稱加密的速度比較慢，所以它一般用于密鑰交換，雙方通過公鑰算法協(xié)商出一份密鑰，然后通過對稱加密來通信，當(dāng)然，為了保證數(shù)據(jù)的完整性，在加密前要先經(jīng)過HMAC的處理。

SSL缺省只進(jìn)行server端的認(rèn)證，客戶端的認(rèn)證是可選的。以下是其流程圖（摘自TLS協(xié)議）。

2.1 客戶端發(fā)出請求（ClientHello）

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

綜上，在這一步，客戶端主要向服務(wù)器提供以下信息：

1. 支持的協(xié)議版本，比如TLS 1.0版

2. 一個(gè)客戶端生成的隨機(jī)數(shù)，稍后用于生成”對話密鑰”

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

4. 支持的壓縮方法

2.2 服務(wù)器回應(yīng)（SeverHello)

上圖中，從Server Hello到Server Done，有些服務(wù)端的實(shí)現(xiàn)是每條單獨(dú)發(fā)送，有服務(wù)端實(shí)現(xiàn)是合并到一起發(fā)送。Sever Hello和Server Done都是只有頭沒有內(nèi)容的數(shù)據(jù)。

服務(wù)端在接收到客戶端的Client Hello之后，服務(wù)端需要將自己的證書發(fā)送給客戶端。這個(gè)證書是對于服務(wù)端的一種認(rèn)證。例如，客戶端收到了一個(gè)來自于稱自己是www.alipay.com的數(shù)據(jù)，但是如何證明對方是合法的alipay支付寶呢？這就是證書的作用，支付寶的證書可以證明它是alipay，而不是財(cái)付通。證書是需要申請，并由專門的數(shù)字證書認(rèn)證機(jī)構(gòu)(CA)通過非常嚴(yán)格的審核之后頒發(fā)的電子證書。頒發(fā)證書的同時(shí)會(huì)產(chǎn)生一個(gè)私鑰和公鑰。私鑰由服務(wù)端自己保存，不可泄漏。公鑰則是附帶在證書的信息中，可以公開的。證書本身也附帶一個(gè)證書電子簽名，這個(gè)簽名用來驗(yàn)證證書的完整性和真實(shí)性，可以防止證書被串改。另外，證書還有個(gè)有效期。

在服務(wù)端向客戶端發(fā)送的證書中沒有提供足夠的信息（證書公鑰）的時(shí)候，還可以向客戶端發(fā)送一個(gè) Server Key Exchange，

此外，對于非常重要的保密數(shù)據(jù)，服務(wù)端還需要對客戶端進(jìn)行驗(yàn)證，以保證數(shù)據(jù)傳送給了安全的合法的客戶端。服務(wù)端可以向客戶端發(fā)出 Cerficate Request 消息，要求客戶端發(fā)送證書對客戶端的合法性進(jìn)行驗(yàn)證。比如，金融機(jī)構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)，就會(huì)向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。

跟客戶端一樣，服務(wù)端也需要產(chǎn)生一個(gè)隨機(jī)數(shù)發(fā)送給客戶端?？蛻舳撕头?wù)端都需要使用這兩個(gè)隨機(jī)數(shù)來產(chǎn)生Master Secret。

最后服務(wù)端會(huì)發(fā)送一個(gè)Server Hello Done消息給客戶端，表示Server Hello消息結(jié)束了。

綜上，在這一步，服務(wù)器的回應(yīng)包含以下內(nèi)容：

1. 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信

2. 一個(gè)服務(wù)器生成的隨機(jī)數(shù)，稍后用于生成”對話密鑰”

3. 確認(rèn)使用的加密方法，比如RSA公鑰加密

4. 服務(wù)器證書

2.3 客戶端回應(yīng)（Certificate Verify）

Client Key Exchange

如果服務(wù)端需要對客戶端進(jìn)行驗(yàn)證，在客戶端收到服務(wù)端的 Server Hello 消息之后，首先需要向服務(wù)端發(fā)送客戶端的證書，讓服務(wù)端來驗(yàn)證客戶端的合法性。

Certificate Verify
接著，客戶端需要對服務(wù)端的證書進(jìn)行檢查，如果證書不是可信機(jī)構(gòu)頒布、或者證書中的域名與實(shí)際域名不一致、或者證書已經(jīng)過期，就會(huì)向訪問者顯示一個(gè)警告，由其選擇是否還要繼續(xù)通信。如果證書沒有問題，客戶端就會(huì)從服務(wù)器證書中取出服務(wù)器的公鑰。然后，向服務(wù)器發(fā)送下面三項(xiàng)信息：

1. 一個(gè)隨機(jī)數(shù)。該隨機(jī)數(shù)用服務(wù)器公鑰加密，防止被竊聽

2. 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送

3. 客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來供服務(wù)器校驗(yàn)

上面第一項(xiàng)的隨機(jī)數(shù)，是整個(gè)握手階段出現(xiàn)的第三個(gè)隨機(jī)數(shù)，它是客戶端使用一些加密算法(例如：RSA, Diffie-Hellman)產(chǎn)生一個(gè)48個(gè)字節(jié)的Key，這個(gè)Key叫 PreMaster Secret，很多材料上也被稱作 PreMaster Key。

ChangeCipherSpec
ChangeCipherSpec是一個(gè)獨(dú)立的協(xié)議，體現(xiàn)在數(shù)據(jù)包中就是一個(gè)字節(jié)的數(shù)據(jù)，用于告知服務(wù)端，客戶端已經(jīng)切換到之前協(xié)商好的加密套件（Cipher Suite）的狀態(tài)，準(zhǔn)備使用之前協(xié)商好的加密套件加密數(shù)據(jù)并傳輸了。

在ChangecipherSpec傳輸完畢之后，客戶端會(huì)使用之前協(xié)商好的加密套件和Session Secret加密一段 Finish 的數(shù)據(jù)傳送給服務(wù)端，此數(shù)據(jù)是為了在正式傳輸應(yīng)用數(shù)據(jù)之前對剛剛握手建立起來的加解密通道進(jìn)行驗(yàn)證。

2.4 服務(wù)器的最后回應(yīng)（Server Finish）

服務(wù)端在接收到客戶端傳過來的 PreMaster 加密數(shù)據(jù)之后，使用私鑰對這段加密數(shù)據(jù)進(jìn)行解密，并對數(shù)據(jù)進(jìn)行驗(yàn)證，也會(huì)使用跟客戶端同樣的方式生成 Session Secret，一切準(zhǔn)備好之后，會(huì)給客戶端發(fā)送一個(gè) ChangeCipherSpec，告知客戶端已經(jīng)切換到協(xié)商過的加密套件狀態(tài)，準(zhǔn)備使用加密套件和 Session Secret加密數(shù)據(jù)了。之后，服務(wù)端也會(huì)使用 Session Secret 加密一段 Finish 消息發(fā)送給客戶端，以驗(yàn)證之前通過握手建立起來的加解密通道是否成功。

根據(jù)之前的握手信息，如果客戶端和服務(wù)端都能對Finish信息進(jìn)行正常加解密且消息正確的被驗(yàn)證，則說明握手通道已經(jīng)建立成功，接下來，雙方可以使用上面產(chǎn)生的Session Secret對數(shù)據(jù)進(jìn)行加密傳輸了。

2.5 幾個(gè)secret

Secret Keys
上面的分析和講解主要是為了突出握手的過程，所以PreMaster secret，Master secret，session secret都是一代而過，但是對于Https，SSL/TLS深入的理解和掌握，這些Secret Keys是非常重要的部分。所以，準(zhǔn)備把這些Secret Keys抽出來單獨(dú)分析和講解。

我們先來看看這些Secret Keys的生成過程以及作用流程圖：

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

PreMaster secret前兩個(gè)字節(jié)是TLS的版本號，這是一個(gè)比較重要的用來核對握手?jǐn)?shù)據(jù)的版本號，因?yàn)樵贑lient Hello階段，客戶端會(huì)發(fā)送一份加密套件列表和當(dāng)前支持的SSL/TLS的版本號給服務(wù)端，而且是使用明文傳送的，如果握手的數(shù)據(jù)包被破解之后，攻擊者很有可能串改數(shù)據(jù)包，選擇一個(gè)安全性較低的加密套件和版本給服務(wù)端，從而對數(shù)據(jù)進(jìn)行破解。所以，服務(wù)端需要對密文中解密出來對的PreMaster版本號跟之前Client Hello階段的版本號進(jìn)行對比，如果版本號變低，則說明被串改，則立即停止發(fā)送任何消息。

關(guān)于PreMaster Secret(Key)的計(jì)算請參考 Https SSL/TLS PreMaster/Master Secret(Key)計(jì)算。

Master secret
上面已經(jīng)提到，由于服務(wù)端和客戶端都有一份相同的PreMaster secret和隨機(jī)數(shù)，這個(gè)隨機(jī)數(shù)將作為后面產(chǎn)生Master secret的種子，結(jié)合PreMaster secret，客戶端和服務(wù)端將計(jì)算出同樣的Master secret。

Master secret是有系列的hash值組成的，它將作為數(shù)據(jù)加解密相關(guān)的secret的 Key Material 的一部分。Key Material最終解析出來的數(shù)據(jù)如下：

其中，write MAC key，就是session secret或者說是session key。Client write MAC key是客戶端發(fā)數(shù)據(jù)的session secret，Server write MAC secret是服務(wù)端發(fā)送數(shù)據(jù)的session key。MAC(Message Authentication Code)，是一個(gè)數(shù)字簽名，用來驗(yàn)證數(shù)據(jù)的完整性，可以檢測到數(shù)據(jù)是否被串改。

關(guān)于Session Secret(Key)的計(jì)算請參考 Https SSL/TLS Session Secret(Key)計(jì)算。

2.6 應(yīng)用數(shù)據(jù)傳輸

在所有的握手階段都完成之后，就可以開始傳送應(yīng)用數(shù)據(jù)了。應(yīng)用數(shù)據(jù)在傳輸之前，首先要附加上MAC secret，然后再對這個(gè)數(shù)據(jù)包使用write encryption key進(jìn)行加密。在服務(wù)端收到密文之后，使用Client write encryption key進(jìn)行解密，客戶端收到服務(wù)端的數(shù)據(jù)之后使用Server write encryption key進(jìn)行解密，然后使用各自的write MAC key對數(shù)據(jù)的完整性包括是否被串改進(jìn)行驗(yàn)證。

2.7 總結(jié)

SSL客戶端（也是TCP的客戶端）在TCP鏈接建立之后，發(fā)出一個(gè)ClientHello來發(fā)起握手，這個(gè)消息里面包含了自己可實(shí)現(xiàn)的算法列表和其它一些需要的消息，SSL的服務(wù)器端會(huì)回應(yīng)一個(gè)ServerHello，這里面確定了這次通信所需要的算法，然后發(fā)過去自己的證書（里面包含了身份和自己的公鑰）。Client在收到這個(gè)消息后會(huì)生成一個(gè)秘密消息，用SSL服務(wù)器的公鑰加密后傳過去，SSL服務(wù)器端用自己的私鑰解密后，會(huì)話密鑰協(xié)商成功，雙方可以用同一份會(huì)話密鑰來通信了。

3. 附：密鑰協(xié)商的形象化比喻

如果上面的說明不夠清晰，這里我們用個(gè)形象的比喻，我們假設(shè)A與B通信，A是SSL客戶端，B是SSL服務(wù)器端，加密后的消息放在方括號[]里，以突出明文消息的區(qū)別。雙方的處理動(dòng)作的說明用圓括號（）括起。

A：我想和你安全的通話，我這里的對稱加密算法有DES,RC5,密鑰交換算法有RSA和DH，摘要算法有MD5和SHA。

B：我們用DES－RSA－SHA這對組合好了。
這是我的證書，里面有我的名字和公鑰，你拿去驗(yàn)證一下我的身份（把證書發(fā)給A）。
目前沒有別的可說的了。

A：（查看證書上B的名字是否無誤，并通過手頭早已有的CA的證書驗(yàn)證了B的證書的真實(shí)性，如果其中一項(xiàng)有誤，發(fā)出警告并斷開連接，這一步保證了B的公鑰的真實(shí)性）
（產(chǎn)生一份秘密消息，這份秘密消息處理后將用作加密密鑰，加密初始化向量（IV）和hmac的密鑰。將這份秘密消息-協(xié)議中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的消息。由于用了B的公鑰，保證了第三方無法竊聽）
我生成了一份秘密消息，并用你的公鑰加密了，給你（把ClientKeyExchange發(fā)給B）
注意，下面我就要用加密的辦法給你發(fā)消息了！
（將秘密消息進(jìn)行處理，生成加密密鑰，加密初始化向量和hmac的密鑰）
[我說完了]

B：（用自己的私鑰將ClientKeyExchange中的秘密消息解密出來，然后將秘密消息進(jìn)行處理，生成加密密鑰，加密初始化向量和hmac的密鑰，這時(shí)雙方已經(jīng)安全的協(xié)商出一套加密辦法了）
注意，我也要開始用加密的辦法給你發(fā)消息了！
[我說完了]

A: [我的秘密是…]

B: [其它人不會(huì)聽到的…]

4. SSL安全性

SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的討論， 目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/）可以通過man in the middle攻擊來截獲https的消息。

從上面的原理可知，SSL的結(jié)構(gòu)是嚴(yán)謹(jǐn)?shù)?，問題一般出現(xiàn)在實(shí)際不嚴(yán)謹(jǐn)?shù)膽?yīng)用中。常見的攻擊就是middle in the middle攻擊，它是指在A和B通信的同時(shí)，有第三方C處于信道的中間，可以完全聽到A與B通信的消息，并可攔截，替換和添加這些消息。

1. SSL可以允許多種密鑰交換算法，而有些算法，如DH，沒有證書的概念，這樣A便無法驗(yàn)證B的公鑰和身份的真實(shí)性，從而C可以輕易的冒充，用自己的密鑰與雙方通信，從而竊聽到別人談話的內(nèi)容。
   而為了防止middle in the middle攻擊，應(yīng)該采用有證書的密鑰交換算法。

2. 有了證書以后，如果C用自己的證書替換掉原有的證書之后，A的瀏覽器會(huì)彈出一個(gè)警告框進(jìn)行警告，但又有多少人會(huì)注意這個(gè)警告呢？

3. 由于美國密碼出口的限制，IE，netscape等瀏覽器所支持的加密強(qiáng)度是很弱的，如果只采用瀏覽器自帶的加密功能的話，理論上存在被破解可能。

5. 代理

下面探討一下SSL的代理是怎樣工作的
當(dāng)在瀏覽器里設(shè)置了https的代理，而且里輸入了https://www.example.com之后，瀏覽器會(huì)與proxy建立tcp鏈接，然后向其發(fā)出這么一段消息：

CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443

然后proxy會(huì)向webserver端建立tcp連接,之后，這個(gè)代理便完全成了個(gè)內(nèi)容轉(zhuǎn)發(fā)裝置。瀏覽器與web server會(huì)建立一個(gè)安全通道，因此這個(gè)安全通道是端到端的，盡管所有的信息流過了proxy,但其內(nèi)容proxy是無法解密和改動(dòng)的（當(dāng)然要由證書的支持，否則這個(gè)地方便是個(gè)man in the middle攻擊的好場所，見上面的安全部分）。

CA證書以及如何使用OpenSSL自簽署，見文章OpenSSL自簽署證書 。

以上就是如何進(jìn)行SSL/TLS原理分析，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。