中間方攻擊
在密鑰協商階段，通信雙方都需要向對方提供密鑰，拿DH密鑰協商舉例，客戶端需要把自己的公鑰發送給服務器端，服務器端把DH參數和服務器公鑰發送給客戶端，最終雙方都持有對方的公鑰拿來加密用，自己的私鑰用來解密。RSA密鑰協商也差不多，不過兩種協商算法都有可能會遭到中間方攻擊，導致密碼套件泄露，來看個例子，在RSA密鑰協商中，中間方是如何“獲取”通信雙方的密碼套件的。
- RSA密鑰協商，首先客戶端向服務器端發送連接請求，希望服務器端迴應併發送本次通信的RSA公鑰。
- 中間方把客戶端的連接請求截獲，然後把自己的連接請求發送給服務器端，服務器端生成密鑰對後，響應發送RSA公鑰給中間方。
- 中間方保留服務器端公鑰後，自己生成一個RSA密鑰對，並把公鑰發送給客戶端，也就是把真正的服務器端公鑰替換掉了。
- 客戶端收到中間方的公鑰後，誤以爲是服務器端公鑰，繼續進行密鑰協商，通過隨機數生成器生成了一個預備主密鑰，並使用了中間方公鑰對其進行機密，發送給服務器端。
- 中間方繼續截獲客戶端發送的預備主密鑰，用自己的私鑰解密出預備主密鑰後，再自己生成一個預備主密鑰，用第一次或得到服務器端公鑰加密，發送給服務器端。
- 服務器端接收到中間方發來的預備主密鑰，並用自己的私鑰解密，發現能正確解出預備主密鑰，誤以爲密鑰協商完成。
- 此時，客戶端持有的是中間方公鑰，服務器端持有的是中間方的預備主密鑰，中間方卻擁有服務器公鑰和客戶端生成的真正的預備主密鑰，接下來中間方就可以隨意僞造信息，同時不讓通信雙方發現，來看看它是怎麼實現。
- 由於客戶端持有的是中間方公鑰，客戶端使用它來加密信息，併發送給服務器，中間方截獲密文後，因爲擁有客戶端生成的預備主密鑰，可以知道客戶端使用的加密算法，例如AES，解密出明文，最後再自己加密發送給服務器端。
- 由於服務器端持有的是中間方的預備主密鑰，解密出的明文可能是被中間修改過的，到這一步，中間方攻擊完成，通信雙方的對話泄露了，同時存在消息被篡改的風險。
發生中間方攻擊的原因，是通信雙方沒有去驗證對方的身份，接受了信息後就誤認爲是由對方發出的，殊不知自己發送的迴應消息早已被截獲，導致信息泄露。例如客戶端訪問某一個服務器，接收到一個服務器公鑰，但是客戶端並不去確認這個服務器公鑰是否屬於自己要訪問的服務器的，所以爲了解決上述的中間方攻擊問題，需要在通信時對對方做身份驗證，身份驗證除了數字簽名外，再HTTPS中還有PKI中的CA證書。
CA證書
PKI公鑰基礎設施
PKI公鑰基礎設施，基於公開密鑰算法解決網絡安全的問題，但是它不是TLS/SSL協議的一部分，是一個標準，裏面包含軟件硬件，法律流程等，在基於這個標準下發展出的安全技術都統稱爲PKI，例如CA證書授權也是PKI的一部分。PKI的組成部分有很多的，例如密鑰管理，證書管理和策略管理等，CA是其中核心的一部分。PKI的作用就是爲通信雙方提供身份認證，通過證書進行公鑰管理，使用數字簽名技術，由可信賴的第三方組織進行證書管理，包括創建證書，存儲，更新證書等。瀏覽器對第三方組織是信任的，由此來完成身份認證。
組成部分
PKI大致由以下部分組成：
- CA機構，負責創建，發放和管理證書的機構。服務器若想申請證書，通常先自己生成一個密鑰對，然後根據密鑰對生成CSR證書請求文件，併發送給CA機構。CA機構對服務器實體身份進行驗證後，使用CA機構的密鑰對來給服務器實體證書進行簽名發放。
- RA機構，數字證書註冊機構，是CA機構的一部分，負責驗證證書申請者的身份。
- 證書驗證軟件，如瀏覽器，瀏覽器訪問網站時會驗證該網站的證書，瀏覽器必須是信任CA機構的，這樣才能完成驗證，就像我們的身份證一樣，所有的機構組織都會信任，這樣才能對我們進行身份驗證。
- CA證書倉庫，負責保存所有的CA機構發放的證書，包括過期的和被插銷的證書。
- 申請證書的實體，例如某一需要申請證書的網站。
X.509和ASN.1標準
X.509標準是對證書的規範化，大部分Web應用使用HTTPS協議，都是使用的該標準的證書。X.509協議規範了證書的簽發，校驗，以及證書的結構，服務器向CA機構申請證書的流程和簽發證書的流程，校驗證書包括域名，有效期等。ASN.1標準則是用來描述證書的，使用僞代碼形式，描述X.509標準證書的數據結構，簡單看看證書結構裏都包含了哪些信息：
證書結構
Certificate ::= SEQUENCE {
tbsCertificate TBSCertifivate,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
TBSCertificate ::= SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions [3] Extensions OPTIONAL
-- If present, version MUST be v2 or v3 --
}
第一個version顧名思義就是版本號了，由v1，v2和v3三個版本，目前最通用的是v3版本，version數據結構是一個枚舉類型，version [0]就是默認的v1版本，[1]和[2]分別是v2和v3。serialNumber是證書的編號，是唯一標識該證書的。signature就是該證書使用的簽名算法，瀏覽器在驗證證書時先要知道證書使用的簽名算法。issuer標識CA機構名，由三部分組成，國家C，組織O和子組織CN組成。validity是證書的有效期，Validity結構體中的兩個參數notBefore和notAfter標識着證書的有效期在這個時間段範圍內。
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time
}
subject標識服務器名，使用的Name類型和issuer，CA機構名的Name類型是一樣的，C標識國家，O標識組織，不過CN在這裏標識的不是子組織名而是服務器的域名。
subjectPublicKeyInfo標識的是服務器公鑰，是十分重要的部分，該結構體中包含了兩部分，公鑰和使用的公開密鑰算法：
subjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
issuerUniqueID標識CA機構編號，subjectUniqueID標識服務器端編號，它們都是唯一的。最後的extension標識證書擴展，使用證書擴展可以爲證書添加新的屬性。
CSR證書請求文件
證書申請大致流程
最後再把CSR證書請求文件整理下，如果一個服務器想要申請證書，大致流程，首先服務器端要自己生成一個密鑰對，公開密鑰或者RSA密鑰對，然後服務器端生成一個CSR證書請求文件，裏面包含了服務器網站域名，公鑰等信息，將其發送給CA機構。CA機構在覈實過服務器身份後，用自己密鑰對的私鑰對CSR文件進行簽名，得到的簽名值加載CSR文件後面，得到證書文件，當然證書文件中還包括CA機構的名稱，使用的算法等信息。最後CA機構再把證書文件發回給服務器，之後，瀏覽器訪問該服務器，服務器端就會把證書文件和自己的服務器公鑰發送給客戶端進行驗證。瀏覽器由於本身內置了CA機構的根證書，根證書裏包含了CA機構的公鑰，用於驗證簽名用，待驗證成功確定證書是由CA機構簽發之後，瀏覽器驗證服務器端的身份，從CA證書中提取出服務器公鑰和域名，確認域名沒錯後，再驗證服務器公鑰和客戶端自己在建立服務器連接時得到的服務器公鑰是否一致，一致，則驗證身份成功，在建立連接階段得到的服務器公鑰確實是該域名的服務器的。
CSR文件結構
CSR證書請求文件裏包含了服務器公鑰，域名，CA機構簽名值，還有CA機構的名稱，使用的算法等。看看ASN.1標準下的CSR文件描述：
CertificationRequest ::= SEQUENCE {
certificationRequestInfo CertificationRequestInfo,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
certificationRequestInfo表示的是請求信息，signatureAlgorithm顧名思義是簽名算法，signature是簽名值。服務器在發送CSR文件前會先對CSR文件進行簽名，把服務器端的一些信息放到裏面去：
CertificationRequestInfo ::= SEQUENCE {
version INTEGER { v1(0) } (v1, v2, v3),
subject Name,
subjectPKInfo SubjectPublicKeyInfo,
attributes [0] Attributes
}
version版本號，subject是服務器名稱，其中包含CN域名，subjectPKInfo就是服務器公鑰，attributes是可選信息，存放服務器的其他信息。
最後，服務器使用私鑰對CSR文件進行簽名，生成最終的CSR文件，發送給CA機構，實現證書申請。
