'網絡安全之OpenSSL加密傳輸'

OpenSSL 網絡安全 電腦 算法 GnuPG 通信 Devops部落 2019-08-13
"

概述:

兩個計算機在互聯網上通信時,它們之間發送的信息如果不經過特殊的處理,即加密機制,很容易被其他人給獲取到,如果是普通的信息,那倒是無所謂,但是如果涉及到個人的私密信息,那這樣豈不是很糟糕,本篇來說一下這個安全和加密機制。


加密算法和協議:

對稱加密:數據加密(保密性)(3DES,AES)
公鑰加密:身份認證、密鑰交換、數據加密(不常用,比對稱加密要慢3個數量級)(RSA,DSA)
單項加密:數據完整性(MD5,SHA)
密鑰交換:RSA、DH(迪菲-赫爾曼)、ECDH(橢圓曲線DH)、ECDHE(臨時橢圓曲線DH)

一 、對稱加密:加密和解密使用同一個密鑰

 DES:Data Encryption Standard,56bits
3DES:
AES:Advanced (128, 192, 256bits)
Blowfish,Twofish
IDEA,RC6,CAST5

特性:

1、加密、解密使用同一個密鑰,效率高

2、將原始數據分割成固定大小的塊,逐個進行加密

缺陷:

1、密鑰過多

2、密鑰分發

3、數據來源無法確認


二 、非對稱加密算法:即公鑰加密

公鑰加密:密鑰是成對出現

 公鑰:公開給所有人;public key
私鑰:自己留存,必須保證其私密性;secret key

特點:

用公鑰加密數據,只能使用與之配對的私鑰解密;反之亦然

功能:

1 數字簽名:主要在於讓接收方確認發送方身份

2 對稱密鑰交換:發送方用對方的公鑰加密一個對稱密鑰後發送給對方

3數據加密:適合加密較小數據

缺點:

密鑰長,加密解密效率低下

算法:

RSA(加密,數字簽名),DSA(數字簽名),ELGamal

具體實現:

基於一對公鑰/密鑰對:
用密鑰對中的一個加密,另一個解密
接收者
生成公鑰/密鑰對:P和S
公開公鑰P,保密密鑰S
發送者
使用接收者的公鑰來加密消息M
將P(M)發送給接收者
接收者
使用密鑰S來解密:M=S(P(M))

三、單項加密:將任意數據縮小成固定大小的“指紋”

特點:

1 任意長度輸入

2 固定長度輸出

3 若修改數據,指紋也會改變(“不會產生衝突”)

4 無法從指紋中重新生成數據(“單向”)

功能:

數據完整性

常見算式:

md5: 128bits、sha1: 160bits、sha224

sha256、sha384、sha512

常用工具:

md5sum | sha1sum [ --check ] file

openssl、gpg

rpm -V


密鑰交換:IKE(Internet Key Exchange )

公鑰加密:

DH (Deffie-Hellman):

DH:
1、A: a,p協商生成公開的整數a,大素數p
B: a,p
2、A:生成隱私數據:x (x<p ),計算得出a^x%p,發送給B
B:生成隱私數據:y,計算得出a^y%p,發送給A
3、A:計算得出(a^y%p)^x = a^xy%p,生成為密鑰
B:計算得出(a^x%p)^y = a^xy%p, 生成為密鑰
此時,A和B便生成了一個相同的密鑰,注意這個密鑰交換協議算法只能用於密鑰的交換,而不能用於消息的加密處理,當雙方確定要用的密鑰後,要使用其他的對稱加密操作實際加密和解密數據

注意:

以上所說的加密算法和協議雖然能夠實現兩個兩個計算機之間的加密通信,可是保證不了其他計算機的干預消息。

例如:A和B是互聯網上的兩臺主機,A擁有自己的私鑰,B擁有自己的私鑰,此時如若A要給B發送消息,但是第一次它並不知道誰是B,如果此時有另一臺機器C告訴A說我就是B,然後把自己的公鑰發送給A,A此時還以為和它通信的真的是B,然而卻是A和C在通信。
那麼問題來了,如何確定B的身份呢?如果此時有一個雙方都信任的第三方機構,由它來確認B的身份,那麼問題就可以解決了,隨之而來的是誰來確定這個第三方機構的身份呢,如果是一個假的機構呢?所以還需要這個機構的上級來確定它,知道到了頂層。當然這個頂層是我們所有人在心底都默認知道和了解的。

說了這麼多,這個所謂的第三方機構就叫做CA,當CA每確認一臺機器的時候,就會給它頒發一個證書,具體如下:


CA和證書

PKI: Public Key Infrastructure
簽證機構:CA(Certificate Authority)
註冊機構:RA
證書吊銷列表:CRL
證書存取庫:
X.509:定義了證書的結構以及認證協議標準
版本號
序列號
簽名算法
頒發者
有效期限
主體名稱
主體公鑰
CRL分發點
擴展信息
發行者簽名
證書類型:
證書授權機構的證書
服務器
用戶證書
獲取證書兩種方法:
使用證書授權機構
生成簽名請求(csr)
將csr發送給CA
從CA處接收簽名
自簽名的證書
自已簽發自己的公鑰

證書籤發過程:如下圖所示

"

概述:

兩個計算機在互聯網上通信時,它們之間發送的信息如果不經過特殊的處理,即加密機制,很容易被其他人給獲取到,如果是普通的信息,那倒是無所謂,但是如果涉及到個人的私密信息,那這樣豈不是很糟糕,本篇來說一下這個安全和加密機制。


加密算法和協議:

對稱加密:數據加密(保密性)(3DES,AES)
公鑰加密:身份認證、密鑰交換、數據加密(不常用,比對稱加密要慢3個數量級)(RSA,DSA)
單項加密:數據完整性(MD5,SHA)
密鑰交換:RSA、DH(迪菲-赫爾曼)、ECDH(橢圓曲線DH)、ECDHE(臨時橢圓曲線DH)

一 、對稱加密:加密和解密使用同一個密鑰

 DES:Data Encryption Standard,56bits
3DES:
AES:Advanced (128, 192, 256bits)
Blowfish,Twofish
IDEA,RC6,CAST5

特性:

1、加密、解密使用同一個密鑰,效率高

2、將原始數據分割成固定大小的塊,逐個進行加密

缺陷:

1、密鑰過多

2、密鑰分發

3、數據來源無法確認


二 、非對稱加密算法:即公鑰加密

公鑰加密:密鑰是成對出現

 公鑰:公開給所有人;public key
私鑰:自己留存,必須保證其私密性;secret key

特點:

用公鑰加密數據,只能使用與之配對的私鑰解密;反之亦然

功能:

1 數字簽名:主要在於讓接收方確認發送方身份

2 對稱密鑰交換:發送方用對方的公鑰加密一個對稱密鑰後發送給對方

3數據加密:適合加密較小數據

缺點:

密鑰長,加密解密效率低下

算法:

RSA(加密,數字簽名),DSA(數字簽名),ELGamal

具體實現:

基於一對公鑰/密鑰對:
用密鑰對中的一個加密,另一個解密
接收者
生成公鑰/密鑰對:P和S
公開公鑰P,保密密鑰S
發送者
使用接收者的公鑰來加密消息M
將P(M)發送給接收者
接收者
使用密鑰S來解密:M=S(P(M))

三、單項加密:將任意數據縮小成固定大小的“指紋”

特點:

1 任意長度輸入

2 固定長度輸出

3 若修改數據,指紋也會改變(“不會產生衝突”)

4 無法從指紋中重新生成數據(“單向”)

功能:

數據完整性

常見算式:

md5: 128bits、sha1: 160bits、sha224

sha256、sha384、sha512

常用工具:

md5sum | sha1sum [ --check ] file

openssl、gpg

rpm -V


密鑰交換:IKE(Internet Key Exchange )

公鑰加密:

DH (Deffie-Hellman):

DH:
1、A: a,p協商生成公開的整數a,大素數p
B: a,p
2、A:生成隱私數據:x (x<p ),計算得出a^x%p,發送給B
B:生成隱私數據:y,計算得出a^y%p,發送給A
3、A:計算得出(a^y%p)^x = a^xy%p,生成為密鑰
B:計算得出(a^x%p)^y = a^xy%p, 生成為密鑰
此時,A和B便生成了一個相同的密鑰,注意這個密鑰交換協議算法只能用於密鑰的交換,而不能用於消息的加密處理,當雙方確定要用的密鑰後,要使用其他的對稱加密操作實際加密和解密數據

注意:

以上所說的加密算法和協議雖然能夠實現兩個兩個計算機之間的加密通信,可是保證不了其他計算機的干預消息。

例如:A和B是互聯網上的兩臺主機,A擁有自己的私鑰,B擁有自己的私鑰,此時如若A要給B發送消息,但是第一次它並不知道誰是B,如果此時有另一臺機器C告訴A說我就是B,然後把自己的公鑰發送給A,A此時還以為和它通信的真的是B,然而卻是A和C在通信。
那麼問題來了,如何確定B的身份呢?如果此時有一個雙方都信任的第三方機構,由它來確認B的身份,那麼問題就可以解決了,隨之而來的是誰來確定這個第三方機構的身份呢,如果是一個假的機構呢?所以還需要這個機構的上級來確定它,知道到了頂層。當然這個頂層是我們所有人在心底都默認知道和了解的。

說了這麼多,這個所謂的第三方機構就叫做CA,當CA每確認一臺機器的時候,就會給它頒發一個證書,具體如下:


CA和證書

PKI: Public Key Infrastructure
簽證機構:CA(Certificate Authority)
註冊機構:RA
證書吊銷列表:CRL
證書存取庫:
X.509:定義了證書的結構以及認證協議標準
版本號
序列號
簽名算法
頒發者
有效期限
主體名稱
主體公鑰
CRL分發點
擴展信息
發行者簽名
證書類型:
證書授權機構的證書
服務器
用戶證書
獲取證書兩種方法:
使用證書授權機構
生成簽名請求(csr)
將csr發送給CA
從CA處接收簽名
自簽名的證書
自已簽發自己的公鑰

證書籤發過程:如下圖所示

網絡安全之OpenSSL加密傳輸

  • 1、A將自己的公鑰發送給CA
  • 2、CA在確定A的身份後,會將證書頒發給A,其中過程如下

1)CA會將應有內容整合到證書上,證書的內容結構如上。
2)然後將此內容使用單向加密算法生成特徵碼(用於驗證證書完整性)
3)最後,CA會使用自己的私鑰來對此特徵嗎進行加密,生成數字簽名(用來驗證是否為CA簽署的證書),然後發給A
  • 3)B的過程與A相同

當B驗證A的身份時,就是通過證書來驗證的,步驟如下

  • 1 使用CA的公鑰來解密數字簽名,如果成功,則驗證了CA身份
  • 2 利用相同的單項加密算法來計算證書內容結構的特徵碼,與原來的特徵碼相比較,如果相同,則保證了證書的完整性
  • 3 從證書內容中取出A的公鑰

加密通信過程詳解


"

概述:

兩個計算機在互聯網上通信時,它們之間發送的信息如果不經過特殊的處理,即加密機制,很容易被其他人給獲取到,如果是普通的信息,那倒是無所謂,但是如果涉及到個人的私密信息,那這樣豈不是很糟糕,本篇來說一下這個安全和加密機制。


加密算法和協議:

對稱加密:數據加密(保密性)(3DES,AES)
公鑰加密:身份認證、密鑰交換、數據加密(不常用,比對稱加密要慢3個數量級)(RSA,DSA)
單項加密:數據完整性(MD5,SHA)
密鑰交換:RSA、DH(迪菲-赫爾曼)、ECDH(橢圓曲線DH)、ECDHE(臨時橢圓曲線DH)

一 、對稱加密:加密和解密使用同一個密鑰

 DES:Data Encryption Standard,56bits
3DES:
AES:Advanced (128, 192, 256bits)
Blowfish,Twofish
IDEA,RC6,CAST5

特性:

1、加密、解密使用同一個密鑰,效率高

2、將原始數據分割成固定大小的塊,逐個進行加密

缺陷:

1、密鑰過多

2、密鑰分發

3、數據來源無法確認


二 、非對稱加密算法:即公鑰加密

公鑰加密:密鑰是成對出現

 公鑰:公開給所有人;public key
私鑰:自己留存,必須保證其私密性;secret key

特點:

用公鑰加密數據,只能使用與之配對的私鑰解密;反之亦然

功能:

1 數字簽名:主要在於讓接收方確認發送方身份

2 對稱密鑰交換:發送方用對方的公鑰加密一個對稱密鑰後發送給對方

3數據加密:適合加密較小數據

缺點:

密鑰長,加密解密效率低下

算法:

RSA(加密,數字簽名),DSA(數字簽名),ELGamal

具體實現:

基於一對公鑰/密鑰對:
用密鑰對中的一個加密,另一個解密
接收者
生成公鑰/密鑰對:P和S
公開公鑰P,保密密鑰S
發送者
使用接收者的公鑰來加密消息M
將P(M)發送給接收者
接收者
使用密鑰S來解密:M=S(P(M))

三、單項加密:將任意數據縮小成固定大小的“指紋”

特點:

1 任意長度輸入

2 固定長度輸出

3 若修改數據,指紋也會改變(“不會產生衝突”)

4 無法從指紋中重新生成數據(“單向”)

功能:

數據完整性

常見算式:

md5: 128bits、sha1: 160bits、sha224

sha256、sha384、sha512

常用工具:

md5sum | sha1sum [ --check ] file

openssl、gpg

rpm -V


密鑰交換:IKE(Internet Key Exchange )

公鑰加密:

DH (Deffie-Hellman):

DH:
1、A: a,p協商生成公開的整數a,大素數p
B: a,p
2、A:生成隱私數據:x (x<p ),計算得出a^x%p,發送給B
B:生成隱私數據:y,計算得出a^y%p,發送給A
3、A:計算得出(a^y%p)^x = a^xy%p,生成為密鑰
B:計算得出(a^x%p)^y = a^xy%p, 生成為密鑰
此時,A和B便生成了一個相同的密鑰,注意這個密鑰交換協議算法只能用於密鑰的交換,而不能用於消息的加密處理,當雙方確定要用的密鑰後,要使用其他的對稱加密操作實際加密和解密數據

注意:

以上所說的加密算法和協議雖然能夠實現兩個兩個計算機之間的加密通信,可是保證不了其他計算機的干預消息。

例如:A和B是互聯網上的兩臺主機,A擁有自己的私鑰,B擁有自己的私鑰,此時如若A要給B發送消息,但是第一次它並不知道誰是B,如果此時有另一臺機器C告訴A說我就是B,然後把自己的公鑰發送給A,A此時還以為和它通信的真的是B,然而卻是A和C在通信。
那麼問題來了,如何確定B的身份呢?如果此時有一個雙方都信任的第三方機構,由它來確認B的身份,那麼問題就可以解決了,隨之而來的是誰來確定這個第三方機構的身份呢,如果是一個假的機構呢?所以還需要這個機構的上級來確定它,知道到了頂層。當然這個頂層是我們所有人在心底都默認知道和了解的。

說了這麼多,這個所謂的第三方機構就叫做CA,當CA每確認一臺機器的時候,就會給它頒發一個證書,具體如下:


CA和證書

PKI: Public Key Infrastructure
簽證機構:CA(Certificate Authority)
註冊機構:RA
證書吊銷列表:CRL
證書存取庫:
X.509:定義了證書的結構以及認證協議標準
版本號
序列號
簽名算法
頒發者
有效期限
主體名稱
主體公鑰
CRL分發點
擴展信息
發行者簽名
證書類型:
證書授權機構的證書
服務器
用戶證書
獲取證書兩種方法:
使用證書授權機構
生成簽名請求(csr)
將csr發送給CA
從CA處接收簽名
自簽名的證書
自已簽發自己的公鑰

證書籤發過程:如下圖所示

網絡安全之OpenSSL加密傳輸

  • 1、A將自己的公鑰發送給CA
  • 2、CA在確定A的身份後,會將證書頒發給A,其中過程如下

1)CA會將應有內容整合到證書上,證書的內容結構如上。
2)然後將此內容使用單向加密算法生成特徵碼(用於驗證證書完整性)
3)最後,CA會使用自己的私鑰來對此特徵嗎進行加密,生成數字簽名(用來驗證是否為CA簽署的證書),然後發給A
  • 3)B的過程與A相同

當B驗證A的身份時,就是通過證書來驗證的,步驟如下

  • 1 使用CA的公鑰來解密數字簽名,如果成功,則驗證了CA身份
  • 2 利用相同的單項加密算法來計算證書內容結構的特徵碼,與原來的特徵碼相比較,如果相同,則保證了證書的完整性
  • 3 從證書內容中取出A的公鑰

加密通信過程詳解


網絡安全之OpenSSL加密傳輸

第一階段:ClientHello:客戶端向服務器端發起加密通信的請求

1 向服務器發送自己支持的協議版本,比如tls1.2
2 客戶端生成一個隨機數,稍後用戶生成”會話密鑰“
3 自己支持的各種加密算法,比如AES,RSA等 支持的壓縮算法;

第二階段:ServerHello(迴應)

1 確認使用的加密通信協議版本,比如tls1.2;(如果版本不一樣,則拒絕通信)
2 服務器端生成一個隨機數,主要在稍後用戶生成”會話密鑰“
3 確認使用的加密方法
4 發送服務器證書
5 索要客戶端證書(不過一般服務器端都不會驗證客戶端)

第三階段:

1 驗證服務器證書,確認無誤後,取出其公鑰;(驗證發證機構、證書籤名、證書完整性、證書持有者、證書有效期、吊銷列表)
2 發送一下信息給服務器端
3 一個隨機數:用於服務器公鑰加密
4 編碼變更通知:表示隨後的信息都將用雙方商定的加密方法和密鑰發送
5 客戶端握手結束通知

第四階段:

1 收到客戶端發來的第三個隨機數-pre-master-kty後,計算生成本次會話用到的會話密鑰
2 向客戶端發送如下消息
3 編碼變更通知:與上相同
4 服務器端握手結束通知

此時雙方已經彼此確認了對方的身份,並且建立一條安全的通道,接下來就可以傳輸信息了。此過程如下圖所示:

"

概述:

兩個計算機在互聯網上通信時,它們之間發送的信息如果不經過特殊的處理,即加密機制,很容易被其他人給獲取到,如果是普通的信息,那倒是無所謂,但是如果涉及到個人的私密信息,那這樣豈不是很糟糕,本篇來說一下這個安全和加密機制。


加密算法和協議:

對稱加密:數據加密(保密性)(3DES,AES)
公鑰加密:身份認證、密鑰交換、數據加密(不常用,比對稱加密要慢3個數量級)(RSA,DSA)
單項加密:數據完整性(MD5,SHA)
密鑰交換:RSA、DH(迪菲-赫爾曼)、ECDH(橢圓曲線DH)、ECDHE(臨時橢圓曲線DH)

一 、對稱加密:加密和解密使用同一個密鑰

 DES:Data Encryption Standard,56bits
3DES:
AES:Advanced (128, 192, 256bits)
Blowfish,Twofish
IDEA,RC6,CAST5

特性:

1、加密、解密使用同一個密鑰,效率高

2、將原始數據分割成固定大小的塊,逐個進行加密

缺陷:

1、密鑰過多

2、密鑰分發

3、數據來源無法確認


二 、非對稱加密算法:即公鑰加密

公鑰加密:密鑰是成對出現

 公鑰:公開給所有人;public key
私鑰:自己留存,必須保證其私密性;secret key

特點:

用公鑰加密數據,只能使用與之配對的私鑰解密;反之亦然

功能:

1 數字簽名:主要在於讓接收方確認發送方身份

2 對稱密鑰交換:發送方用對方的公鑰加密一個對稱密鑰後發送給對方

3數據加密:適合加密較小數據

缺點:

密鑰長,加密解密效率低下

算法:

RSA(加密,數字簽名),DSA(數字簽名),ELGamal

具體實現:

基於一對公鑰/密鑰對:
用密鑰對中的一個加密,另一個解密
接收者
生成公鑰/密鑰對:P和S
公開公鑰P,保密密鑰S
發送者
使用接收者的公鑰來加密消息M
將P(M)發送給接收者
接收者
使用密鑰S來解密:M=S(P(M))

三、單項加密:將任意數據縮小成固定大小的“指紋”

特點:

1 任意長度輸入

2 固定長度輸出

3 若修改數據,指紋也會改變(“不會產生衝突”)

4 無法從指紋中重新生成數據(“單向”)

功能:

數據完整性

常見算式:

md5: 128bits、sha1: 160bits、sha224

sha256、sha384、sha512

常用工具:

md5sum | sha1sum [ --check ] file

openssl、gpg

rpm -V


密鑰交換:IKE(Internet Key Exchange )

公鑰加密:

DH (Deffie-Hellman):

DH:
1、A: a,p協商生成公開的整數a,大素數p
B: a,p
2、A:生成隱私數據:x (x<p ),計算得出a^x%p,發送給B
B:生成隱私數據:y,計算得出a^y%p,發送給A
3、A:計算得出(a^y%p)^x = a^xy%p,生成為密鑰
B:計算得出(a^x%p)^y = a^xy%p, 生成為密鑰
此時,A和B便生成了一個相同的密鑰,注意這個密鑰交換協議算法只能用於密鑰的交換,而不能用於消息的加密處理,當雙方確定要用的密鑰後,要使用其他的對稱加密操作實際加密和解密數據

注意:

以上所說的加密算法和協議雖然能夠實現兩個兩個計算機之間的加密通信,可是保證不了其他計算機的干預消息。

例如:A和B是互聯網上的兩臺主機,A擁有自己的私鑰,B擁有自己的私鑰,此時如若A要給B發送消息,但是第一次它並不知道誰是B,如果此時有另一臺機器C告訴A說我就是B,然後把自己的公鑰發送給A,A此時還以為和它通信的真的是B,然而卻是A和C在通信。
那麼問題來了,如何確定B的身份呢?如果此時有一個雙方都信任的第三方機構,由它來確認B的身份,那麼問題就可以解決了,隨之而來的是誰來確定這個第三方機構的身份呢,如果是一個假的機構呢?所以還需要這個機構的上級來確定它,知道到了頂層。當然這個頂層是我們所有人在心底都默認知道和了解的。

說了這麼多,這個所謂的第三方機構就叫做CA,當CA每確認一臺機器的時候,就會給它頒發一個證書,具體如下:


CA和證書

PKI: Public Key Infrastructure
簽證機構:CA(Certificate Authority)
註冊機構:RA
證書吊銷列表:CRL
證書存取庫:
X.509:定義了證書的結構以及認證協議標準
版本號
序列號
簽名算法
頒發者
有效期限
主體名稱
主體公鑰
CRL分發點
擴展信息
發行者簽名
證書類型:
證書授權機構的證書
服務器
用戶證書
獲取證書兩種方法:
使用證書授權機構
生成簽名請求(csr)
將csr發送給CA
從CA處接收簽名
自簽名的證書
自已簽發自己的公鑰

證書籤發過程:如下圖所示

網絡安全之OpenSSL加密傳輸

  • 1、A將自己的公鑰發送給CA
  • 2、CA在確定A的身份後,會將證書頒發給A,其中過程如下

1)CA會將應有內容整合到證書上,證書的內容結構如上。
2)然後將此內容使用單向加密算法生成特徵碼(用於驗證證書完整性)
3)最後,CA會使用自己的私鑰來對此特徵嗎進行加密,生成數字簽名(用來驗證是否為CA簽署的證書),然後發給A
  • 3)B的過程與A相同

當B驗證A的身份時,就是通過證書來驗證的,步驟如下

  • 1 使用CA的公鑰來解密數字簽名,如果成功,則驗證了CA身份
  • 2 利用相同的單項加密算法來計算證書內容結構的特徵碼,與原來的特徵碼相比較,如果相同,則保證了證書的完整性
  • 3 從證書內容中取出A的公鑰

加密通信過程詳解


網絡安全之OpenSSL加密傳輸

第一階段:ClientHello:客戶端向服務器端發起加密通信的請求

1 向服務器發送自己支持的協議版本,比如tls1.2
2 客戶端生成一個隨機數,稍後用戶生成”會話密鑰“
3 自己支持的各種加密算法,比如AES,RSA等 支持的壓縮算法;

第二階段:ServerHello(迴應)

1 確認使用的加密通信協議版本,比如tls1.2;(如果版本不一樣,則拒絕通信)
2 服務器端生成一個隨機數,主要在稍後用戶生成”會話密鑰“
3 確認使用的加密方法
4 發送服務器證書
5 索要客戶端證書(不過一般服務器端都不會驗證客戶端)

第三階段:

1 驗證服務器證書,確認無誤後,取出其公鑰;(驗證發證機構、證書籤名、證書完整性、證書持有者、證書有效期、吊銷列表)
2 發送一下信息給服務器端
3 一個隨機數:用於服務器公鑰加密
4 編碼變更通知:表示隨後的信息都將用雙方商定的加密方法和密鑰發送
5 客戶端握手結束通知

第四階段:

1 收到客戶端發來的第三個隨機數-pre-master-kty後,計算生成本次會話用到的會話密鑰
2 向客戶端發送如下消息
3 編碼變更通知:與上相同
4 服務器端握手結束通知

此時雙方已經彼此確認了對方的身份,並且建立一條安全的通道,接下來就可以傳輸信息了。此過程如下圖所示:

網絡安全之OpenSSL加密傳輸

(1)A-->B

1)使用單向加密算法計算要傳輸的數據的特徵碼(並沒有對原數據內容加密)
2)使用自己的私鑰來加密這段特徵碼生成數字簽名
3)使用對稱加密算法加密上面的所有數據(包括原數據,特徵碼,數字簽名),將生成的對稱加密的密碼附加在加密過的數據後面
4)使用B的公鑰來加密這段對稱加密的密碼,並將以上所有數據發送給B

(2)B收到A發送的數據後

1)使用B的要來解密對稱加密的密碼(如果可以解密,則保證接收放是B)
2)利用解密過的對稱加密密碼來解密這段數據
3)解密後通過利用A的公鑰來解密數字簽名(如果可以,則保證了數據是從A發的)
4)此時,呈現在B的有兩樣東西,一個是原數據,還有一個是特徵碼。且原數據是沒有加密的。此時B需要使用相同的單項加密算法對此時的原數據計算特徵碼,與A發送過來的特徵碼相比較,如果相等,則保證了原數據的完整性。

至此。信息的加密與解密過程完成。


總結:

在以上所述的過程中,個人認為有幾點需要強調:

1)單項加密並不加密原數據,只是為了計算原數據的特徵碼。用於數據的完整性校驗

2)對稱加密算法加密和解密都是用同一個密鑰。用於加密數據

3)公鑰加密加密的是特徵碼。用於生成數字簽名

4)證書的頒發和驗證過程和數據的傳輸過程是兩個過程

"

相關推薦

推薦中...