客戶端與服務器進行握手的方法、裝置及系統(tǒng)的制作方法
【專利摘要】本發(fā)明公開了一種客戶端與服務器進行握手的方法、裝置及系統(tǒng)，涉及互聯(lián)網(wǎng)技術領域，為解決私鑰部署安全性低的問題而發(fā)明。本發(fā)明的方法包括：客戶端通過緩存服務器向回源服務器發(fā)送握手請求信息，回源服務器根據(jù)自身管理的私鑰對證書信息進行加密，通過緩存服務器向客戶端發(fā)送加密后的證書信息，客戶端對證書信息進行驗證，并通過緩存服務器向回源服務器發(fā)送密鑰生成信息，回源服務器通過私鑰對密鑰生成信息進行解密，獲得對稱密鑰。本發(fā)明主要應用于內容分發(fā)網(wǎng)絡中。
【專利說明】
客戶端與服務器進行握手的方法、裝置及系統(tǒng)
技術領域
[0001]本發(fā)明涉及互聯(lián)網(wǎng)技術領域，尤其涉及一種客戶端與服務器進行握手的方法、裝置及系統(tǒng)。
【背景技術】
[0002]客戶端與服務器之間通常使用超文本傳輸協(xié)議(Hypertext Transfer Protocol，簡稱HTTP)進行通信，HTTP協(xié)議的特點是以明文形式進行數(shù)據(jù)傳輸。對于銀行的網(wǎng)銀系統(tǒng)或電商的支付系統(tǒng)而言，賬號、密碼等信息涉及用戶的金融安全，不宜使用明文形式進行傳輸。
[0003]為改善數(shù)據(jù)傳輸?shù)陌踩?，目前出現(xiàn)了一種新的傳輸協(xié)議，該協(xié)議全稱為超文本傳輸安全協(xié)議(Hypertext Transfer Protocol Secure，簡稱 HTTPS)?；?HTTPS 協(xié)議，客戶端與服務器之間傳輸?shù)乃袛?shù)據(jù)均會被加密，第三方在未獲得加密密鑰的情況下無法對加密數(shù)據(jù)進行破解。由于需要在客戶端和服務器兩側使用加密密鑰進行數(shù)據(jù)加密，因此在基于HTTPS協(xié)議進行通信之前，首先需要客戶端與服務器進行握手，通過證書認證及密鑰協(xié)商等流程是雙方獲得加密密鑰。實際應用中，握手過程涉及兩套密鑰，一套為非對稱密鑰，另一套為對稱密鑰。客戶端和服務器之間在握手過程中傳輸?shù)乃行畔?例如證書信息、對稱密鑰等)全部使用非對稱密鑰加密，服務器擁有自己的私鑰，用于對發(fā)出的信息進行加密或者對接收的信息進行解密；客戶端擁有與該私鑰對應的公鑰，用于對服務器通過私鑰加密的信息進行解密，或者對發(fā)出的信息進行加密，以使服務器使用私鑰解密。對稱密鑰是客戶端與服務器通過握手過程協(xié)商獲得的加密密鑰，用于后續(xù)傳輸HTTPS數(shù)據(jù)時加解密使用。
[0004]內容分發(fā)網(wǎng)絡(Content Distribut1n Network，簡稱CDN)是一種區(qū)別于傳統(tǒng)網(wǎng)絡的新型網(wǎng)絡架構，其特點是在客戶端和服務器之間增設了一跳緩存服務器。在增設緩存服務器后，原有的服務器被稱為回源服務器。當在CDN網(wǎng)絡中使用HTTPS協(xié)議時，現(xiàn)有技術一般通過緩存服務器代替回源服務器與客戶端進行握手，即由緩存服務器與客戶端進行證書認證及密鑰協(xié)商，因此需要將回源服務器的私鑰部署在緩存服務器中。通常，回源服務器隸屬于內容提供商，而緩存服務器則由內容分發(fā)者管理，將內容提供商的站點私鑰開放給第三方使用存在較大的安全風險，一旦第三方服務器被黑客攻擊導致站點私鑰泄露，那么將會給內容提供商造成無法估量的損失。

【發(fā)明內容】

[0005]本發(fā)明提供了一種客戶端與服務器進行握手的方法、裝置及系統(tǒng)，能夠解決私鑰部署安全性低的問題。
[0006]為解決上述問題，第一方面，本發(fā)明提供了一種客戶端與服務器進行握手的方法，所述方法包括:
[0007]緩存服務器向回源服務器轉發(fā)客戶端發(fā)送的握手請求信息，所述握手請求信息用于請求與回源服務器建立握手流程；
[0008]向客戶端轉發(fā)回源服務器發(fā)送的證書信息，所述證書信息由回源服務器根據(jù)私鑰進行加密；
[0009]在客戶端對證書信息進行驗證后，向回源服務器轉發(fā)客戶端發(fā)送的密鑰生成信息，以便回源服務器根據(jù)私鑰解密后獲得對稱密鑰。
[0010]第二方面，本發(fā)明還提供了一種客戶端與服務器進行握手的方法，所述方法包括:
[0011]回源服務器通過緩存服務器接收客戶端發(fā)送的握手請求信息，所述握手請求信息用于請求與回源服務器建立握手流程；
[0012]根據(jù)自身管理的私鑰對證書信息進行加密；
[0013]通過緩存服務器向客戶端發(fā)送加密后的證書信息，以便客戶端對證書信息進行驗證；
[0014]通過緩存服務器接收客戶端發(fā)送的密鑰生成信息；
[0015]根據(jù)私鑰對密鑰生成信息進行解密，獲得對稱密鑰。
[0016]第三方面，本發(fā)明還提供了一種客戶端與服務器進行握手的裝置，所述裝置位于緩存服務器一側，所述裝置包括:
[0017]第一轉發(fā)單元，用于向回源服務器轉發(fā)客戶端發(fā)送的握手請求信息，所述握手請求信息用于請求與回源服務器建立握手流程；
[0018]第二轉發(fā)單元，用于向客戶端轉發(fā)回源服務器發(fā)送的證書信息，所述證書信息由回源服務器根據(jù)私鑰進行加密；
[0019]第三轉發(fā)單元，用于在客戶端對證書信息進行驗證后，向回源服務器轉發(fā)客戶端發(fā)送的密鑰生成信息，以便回源服務器根據(jù)私鑰解密后獲得對稱密鑰。
[0020]第四方面，本發(fā)明還提供了一種客戶端與服務器進行握手的裝置，所述裝置位于回源服務器一側，所述裝置包括:
[0021]接收單元，用于通過緩存服務器接收客戶端發(fā)送的握手請求信息，所述握手請求信息用于請求與回源服務器建立握手流程；
[0022]處理單元，用于根據(jù)自身管理的私鑰對證書信息進行加密；
[0023]發(fā)送單元，用于通過緩存服務器向客戶端發(fā)送加密后的證書信息，以便客戶端對證書信息進行驗證；
[0024]所述接收單元還用于通過緩存服務器接收客戶端發(fā)送的密鑰生成信息；
[0025]所述處理單元還用于根據(jù)私鑰對密鑰生成信息進行解密，獲得對稱密鑰。
[0026]第五方面，本發(fā)明還提供了一種客戶端與服務器進行握手的系統(tǒng)，所述系統(tǒng)包括客戶端、緩存服務器及回源服務器，其中:
[0027]所述客戶端，用于通過所述緩存服務器向所述回源服務器發(fā)送握手請求信息，所述握手請求信息用于請求與所述回源服務器建立握手流程；
[0028]所述回源服務器，用于根據(jù)自身管理的私鑰對證書信息進行加密，通過所述緩存服務器向所述客戶端發(fā)送加密后的證書信息；
[0029]所述客戶端還用于對證書信息進行驗證，并通過所述緩存服務器向所述回源服務器發(fā)送密鑰生成信息；
[0030]所述回源服務器還用于通過私鑰對所述密鑰生成信息進行解密，獲得所述對稱密鑰。
[0031]本發(fā)明提供的客戶端與服務器進行握手的方法、裝置及系統(tǒng)，能夠由回源服務器直接與客戶端進行握手，緩存服務器僅對兩者交互的握手信息進行代理轉發(fā)。由于轉發(fā)不涉及對往來信息的加解密，因此緩存服務器無需使用回源服務器的私鑰。與現(xiàn)有技術中由緩存服務器與客戶端進行握手相比，本發(fā)明無需向緩存服務器開放回源服務器的私鑰，因此可以消除通過第三方泄露站點私鑰的隱患，由此提高私鑰部署的安全性。
【附圖說明】
[0032]為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作一簡單地介紹，顯而易見地，下面描述中的附圖是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。
[0033]圖1為本發(fā)明實施例提供的一種客戶端與服務器進行握手的方法流程圖；
[0034]圖2為本發(fā)明實施例提供的另一種客戶端與服務器進行握手的方法流程圖；
[0035]圖3為本發(fā)明實施例提供的又一種客戶端與服務器進行握手的方法流程圖；
[0036]圖4為本發(fā)明實施例提供的再一種客戶端與服務器進行握手的方法流程圖；
[0037]圖5為本發(fā)明實施例提供的一種客戶端與服務器進行握手的裝置的組成框圖；
[0038]圖6為本發(fā)明實施例提供的另一種客戶端與服務器進行握手的裝置的組成框圖；
[0039]圖7為本發(fā)明實施例提供的又一種客戶端與服務器進行握手的裝置的組成框圖；
[0040]圖8為本發(fā)明實施例提供的再一種客戶端與服務器進行握手的裝置的組成框圖；
[0041]圖9為本發(fā)明實施例提供的一種客戶端與服務器進行握手的系統(tǒng)的示意圖。
【具體實施方式】
[0042]為使本發(fā)明實施例的目的、技術方案和優(yōu)點更加清楚，下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。
[0043]本發(fā)明實施例提供了一種客戶端與服務器進行握手的方法，該方法應用于緩存服務器側。如圖1所示，該方法包括:
[0044]101、緩存服務器向回源服務器轉發(fā)客戶端發(fā)送的握手請求信息。
[0045]該握手請求信息由客戶端發(fā)出，用于請求與回源服務器建立握手流程。在⑶N網(wǎng)絡中，客戶端與回源服務器之間的一切信息交互全部通過緩存服務器轉發(fā)。本步驟中，客戶端向回源服務器發(fā)送的握手請求信息發(fā)送給緩存服務器。
[0046]緩存服務器接收到握手請求信息后，將該信息轉發(fā)給相應的回源服務器。所謂相應的回源服務器是指客戶端請求建立握手連接的回源服務器。
[0047]按照現(xiàn)有的安全套接層(Secure Sockets Layer，簡稱SSL)協(xié)議規(guī)定，在建立HTTPS連接之前，客戶端或服務器向對方發(fā)送任意信息，即表示向對方請求握手，因此本實施例中握手請求信息中可以攜帶任意數(shù)據(jù)，本實施例不對握手請求信息的內容進行限制。在本實施例的一種實現(xiàn)方式中，客戶端發(fā)送的握手請求信息可以是“Hello”。
[0048]本步驟中，客戶端無需對握手請求信息進行加密，這是由于:握手請求信息僅用于向對端表達希望進行握手的意愿，其信息內容不具有實際含義，更不涉及敏感信息，因此客戶端無需對其進行加密。
[0049]102、緩存服務器向客戶端轉發(fā)回源服務器發(fā)送的證書信息。
[0050]回源服務器接收到握手請求信息后向客戶端返回證書信息，該證書信息中攜帶有回源服務器在第三方證書管理部門注冊申請的數(shù)字證書。緩存服務器將回源服務器發(fā)送的證書信息轉發(fā)給客戶端，以便客戶端根據(jù)該證書信息對回源服務器的可靠性進行驗證。
[0051]本實施例中，回源服務器通過自身保存管理的私鑰對證書信息進行加密，客戶端使用對應該私鑰的公鑰對接收到的證書信息進行解密?；卦捶掌鞯墓€保存在第三方站點，網(wǎng)絡中的任何設備都可以向該第三方節(jié)點請求獲取該公鑰。客戶端可以根據(jù)回源服務器的域名向第三方站點請求相應的公鑰，也可以接收與證書信息一同發(fā)送的公鑰。對于后者方式，回源服務器需要將自己的公連同證書信息發(fā)送給客戶端。
[0052]103、在客戶端對證書信息進行驗證后，緩存服務器向回源服務器轉發(fā)客戶端發(fā)送的密鑰生成信息。
[0053]客戶端通過回源服務器的公鑰對證書信息進行解密，查看其中記錄的域名是否與客戶端請求的域名一致。如果兩者一致，則說明客戶端請求的域名是回源服務器的真實域名，客戶端信賴回源服務器，完成對證書信息的驗證。如果兩者不一致，客戶端不信任回源服務器，終止圖1中的后續(xù)步驟，握手連接失敗。
[0054]在通過驗證后，客戶端將秘鑰生成信息發(fā)送給緩存服務器，由緩存服務器將該信息轉發(fā)給回源服務器。秘鑰生成信息用于使回源服務器獲得與客戶端在后續(xù)通信過程中使用的加密密鑰，該加密密鑰是區(qū)別于前述私鑰、公鑰的另一個密鑰。由于客戶端和回源服務器在通信過程中使用相同的加密密鑰對HTTPS數(shù)據(jù)進行加密，因此這個加密密鑰又稱為對稱密鑰。
[0055]本步驟中，客戶端可以自己生成這個對稱密鑰，并將生成的對稱密鑰以密鑰生成信息的形式發(fā)送回源服務器。此外，客戶端也可以通過密鑰生成信息將生成對稱密鑰的必要信息(例如隨機數(shù))發(fā)送給回源服務器，由回源服務器根據(jù)該必要信息自己生成對稱密鑰。
[0056]本實施例中，客戶端可以使用回源服務器的公鑰對密鑰生成信息進行加密?；卦捶掌髟诮邮盏矫荑€生成信息后，通過自身保存管理的私鑰對密鑰生成信息進行解密，獲得對稱密鑰。
[0057]至此，客戶端與回源服務器之間完成了握手流程，建立了 HTTPS連接，此后兩者即可以使用對稱秘鑰對傳輸?shù)腍TTPS信息進行加解密了。
[0058]本實施例中，回源服務器的私鑰由回源服務器自己保存管理，與客戶端之間的握手流程也由回源服務器親自參與，而第三方的緩存服務器僅扮演數(shù)據(jù)轉發(fā)的角色，在握手過程中對雙方交互的握手信息進行傳遞。由于緩存服務器無需知道握手信息中的具體內容，不必使用回源服務器的私鑰對握手信息進行加解密，因此可以不將回源服務器的私鑰開放給緩存服務器，由此提高了私鑰部署的安全性。
[0059]本發(fā)明實施例還提供了一種客戶端與服務器進行握手的方法，該方法應用于回源服務器側。如圖2所示，該方法包括:
[0060]201、回源服務器通過緩存服務器接收客戶端發(fā)送的握手請求信息。
[0061]客戶端發(fā)送的握手請求信息經(jīng)由緩存服務器轉發(fā)給回源服務器，該握手請求信息與圖1步驟101中的握手請求信息相同。
[0062]202、回源服務器根據(jù)自身管理的私鑰對證書信息進行加密。
[0063]在接收到握手請求信息后，回源服務器獲取自身的證書信息，并使用私鑰對其加
LU O
[0064]本實施例中，回源服務器的私鑰保存在回源服務器本地，而不開放給緩存服務器。因此需要回源服務器使用私鑰對證書信息進行加密。
[0065]203、回源服務器通過緩存服務器向客戶端發(fā)送加密后的證書信息。
[0066]回源服務器將加密后的證書信息發(fā)送緩存服務器，由緩存服務器轉發(fā)給客戶端進行驗證。
[0067]如前所述，客戶端可以通過第三方站點或者回源服務器獲取對應該私鑰的公鑰?？蛻舳耸褂脤墓€對加密的證書信息進行解密，然后對證書信息進行驗證。當驗證通過時，客戶端生成秘鑰生成信息，并通過緩存服務器發(fā)送給回源服務器，而當驗證失敗時，不再執(zhí)行后續(xù)步驟，握手流程終止。
[0068]本實施例中，客戶端使用回源服務器的公鑰對密鑰生成信息進行加密，然后將加密后的密鑰生成信息發(fā)送給緩存服務器進行轉發(fā)。
[0069]204、回源服務器通過緩存服務器接收客戶端發(fā)送的密鑰生成信息。
[0070]205、回源服務器根據(jù)私鑰對密鑰生成信息進行解密，獲得對稱密鑰。
[0071]由于密鑰生成信息是通過與私鑰對應的公鑰加密的，因此可以通過私鑰解密?；卦捶掌髟谑褂盟借€對密鑰生成信息進行解密后，獲得對稱密鑰。
[0072]本實施例中，密鑰生成信息中可以直接攜帶客戶端生成的對稱密鑰，也可以僅攜帶生成加密密鑰的必要信息(例如隨機數(shù))，由回源服務器根據(jù)隨機數(shù)自行生成與客戶端側相同的對稱密鑰。
[0073]至此，客戶端與回源服務器之間完成了握手流程，建立了 HTTPS連接，此后兩者即可以使用對稱秘鑰對傳輸?shù)腍TTPS信息進行加解密了。
[0074]本實施例中，回源服務器的私鑰由回源服務器自己保存管理，與客戶端之間的握手流程也由回源服務器親自參與，而第三方的緩存服務器僅扮演數(shù)據(jù)轉發(fā)的角色，在握手過程中對雙方交互的握手信息進行傳遞。由于緩存服務器無需知道握手信息中的具體內容，不必使用回源服務器的私鑰對握手信息進行加解密，因此可以不將回源服務器的私鑰開放給緩存服務器，由此提高了私鑰部署的安全性。
[0075]進一步的，作為對圖1和圖2所示方法的細化，本發(fā)明實施例還提供了一種客戶端與服務器進行握手的方法，該方法依賴于客戶端、緩存服務器及回源服務器三者實現(xiàn)。如圖3所示，該方法包括:
[0076]301、緩存服務器根據(jù)握手請求信息中的域名向回源服務器轉發(fā)握手請求信息。
[0077]客戶端在向緩存服務器上報握手請求信息時，將回源服務器的域名一同發(fā)送給緩存服務器。緩存服務器將該域名發(fā)送給域名系統(tǒng)(Domain Name System，簡稱DNS)服務器進行解析，獲得回源服務器的網(wǎng)間協(xié)議(Internet Protocol，簡稱IP)地址，然后以該IP地址作為目的IP地址，將握手請求信息發(fā)送給回源服務器。
[0078]302、回源服務器根據(jù)自身管理的私鑰對證書信息進行加密。
[0079]證書信息可以包括下述具體內容:第三方電子簽證機關的信息、公鑰用戶信息、權威機構的簽字和證書有效期，其中，公鑰用戶信息具體可以是回源服務器的域名信息。本實施例中，證書的格式和驗證方法可以遵循X.509國際標準執(zhí)行。
[0080]本實施例中，對證書信息加密的目的有二:第一，防止非法第三方截獲并篡改證書信息，特別是對回源服務器域名的篡改，能夠直接導致客戶端驗證失敗，終止握手流程。第二，側面驗證客戶端側使用的公鑰是否與回源服務器使用的私鑰匹配。在非對稱加密算法中，一對匹配的公鑰和私鑰之間能夠相互進行數(shù)據(jù)加解密，即通過私鑰加密的數(shù)據(jù)可以使用公鑰解密，通過公鑰加密的數(shù)據(jù)也可以使用私鑰解密。但是相互加解密的前提是公私鑰是匹配的，不匹配的公私鑰之間無法成功解密。如果客戶端使用的公鑰能夠對回源服務器使用私鑰加密的證書信息進行解密，那么可以確定客戶端使用的公鑰與回源服務器使用的私鑰匹配。
[0081]303、緩存服務器將加密后的證書信息轉發(fā)給客戶端進行驗證。
[0082]按照現(xiàn)有協(xié)議規(guī)定，客戶端在通過域名定位到作為握手對象的服務器后，客戶端與服務器之間即建立了握手連接，服務器可以通過該連接直接向發(fā)起握手請求的客戶端返回數(shù)據(jù)，而無需對客戶端進行查找。本步驟中，回源服務器可以通過緩存服務器直接將證書信息發(fā)送給發(fā)起握手請求的客戶端。
[0083]304、客戶端使用公鑰對證書信息進行解密并驗證。
[0084]客戶端使用公鑰對證書信息進行解密，從中獲取經(jīng)由第三方認證機構認證的域名信息，然后與自身的請求的域名進行比對。當兩者一致時驗證通過。
[0085]305、在驗證通過后，客戶端生成第一隨機數(shù)，并使用公鑰對第一隨機數(shù)進行加密。
[0086]實際應用中，客戶端可以使用偽隨機數(shù)發(fā)生器生成第一隨機數(shù)。
[0087]本實施例中，客戶端向回源服務器提供生成對稱密鑰的必要信息，即提供步驟305中生成的第一隨機數(shù)。
[0088]306、緩存服務器將加密的第一隨機數(shù)轉發(fā)給回源服務器。
[0089]307、回源服務器生成第二隨機數(shù)，并根據(jù)第一隨機數(shù)和第二隨機數(shù)生成對稱密鑰。
[0090]回源服務器使用私鑰對接收到的第一隨機數(shù)進行解密，并生成一個第二隨機數(shù)，然后以第一隨機數(shù)和第二隨機數(shù)為基礎，通過預設算法生成對稱密鑰。實際應用中，回源服務器可以使用偽隨機數(shù)發(fā)生器生成第二隨機數(shù)。
[0091]308、回源服務器通過緩存服務器將第二隨機數(shù)發(fā)送給客戶端。
[0092]回源服務器通過私鑰對生成的第二隨機數(shù)進行加密，通過緩存服務器將其發(fā)送給客戶端?？蛻舳耸褂霉€對加密的第二隨機數(shù)進行解密，然后結合自身生成的第一隨機數(shù)，使用于回源服務器側相同的預設算法，生成相同的對稱密鑰。由此，客戶端和回源服務器兩側就分別獲得了根據(jù)第一隨機數(shù)和第二隨機數(shù)生成的對稱密鑰。由于兩側生成對稱密鑰的基礎都是第一隨機數(shù)和第二隨機數(shù)，而且使用了相同的預設算法，因此客戶端和回源服務器兩側生成的對稱密鑰是相同的。
[0093]進一步的，作為對圖1和圖2所示方法的細化，本發(fā)明實施例還提供了一種客戶端與服務器進行握手的方法，該方法依賴于客戶端、緩存服務器及回源服務器三者實現(xiàn)。如圖4所示，該方法包括:
[0094]401、緩存服務器根據(jù)握手請求信息中的域名向回源服務器轉發(fā)握手請求信息。
[0095]本步驟的實現(xiàn)方式與圖3步驟301的實現(xiàn)方式相同，此處不再贅述。
[0096]402、回源服務器根據(jù)自身管理的私鑰對證書信息進行加密。
[0097]本實施例中，由客戶端根據(jù)第一隨機數(shù)和第二隨機數(shù)生成對稱密鑰，然后發(fā)送給回源服務器使用。因此在本步驟中，回源服務器需要生成一個第二隨機數(shù)，并且將第二隨機數(shù)添加到證書信息中發(fā)送給客戶端。
[0098]403、緩存服務器將加密后的證書信息轉發(fā)給客戶端進行驗證。
[0099]404、客戶端使用公鑰對證書信息進行解密并驗證。
[0100]405、客戶端根據(jù)第一隨機數(shù)和第二隨機數(shù)生成對稱密鑰，并通過公鑰對對稱密鑰進行加密。
[0101]客戶端使用偽隨機數(shù)發(fā)生器生成一個第一隨機數(shù)，然后結合證書信息中的第二隨機數(shù)，通過預設算法生成對稱密鑰，并將對稱密鑰發(fā)送給回源服務器使用。
[0102]406、緩存服務器向回源服務器轉發(fā)客戶端生成對稱密鑰。
[0103]回源服務器使用私鑰解密獲得對稱密鑰，由此完成握手流程，客戶端與回源服務器兩側均獲得了相同的對稱密鑰。
[0104]進一步的，作為對上述方法的實現(xiàn)，本發(fā)明實施例還提供了一種客戶端與服務器進行握手的裝置。該裝置位于緩存服務器中，或者獨立于緩存服務器但是與緩存服務器之間建立有數(shù)據(jù)交互關系，用以對上述方法進行實現(xiàn)。如圖5所示，該裝置包括:
[0105]第一轉發(fā)單元51，用于向回源服務器轉發(fā)客戶端發(fā)送的握手請求信息，握手請求信息用于請求與回源服務器建立握手流程。
[0106]該握手請求信息由客戶端發(fā)出，用于請求與回源服務器建立握手流程。在⑶N網(wǎng)絡中，客戶端與回源服務器之間的一切信息交互全部通過緩存服務器轉發(fā)?？蛻舳讼蚧卦捶掌靼l(fā)送的握手請求信息發(fā)送給緩存服務器。緩存服務器接收到握手請求信息后，將該信息轉發(fā)給相應的回源服務器。所謂相應的回源服務器是指客戶端請求建立握手連接的回源服務器。
[0107]第二轉發(fā)單元52，用于向客戶端轉發(fā)回源服務器發(fā)送的證書信息，證書信息由回源服務器根據(jù)私鑰進行加密。
[0108]回源服務器接收到握手請求信息后向客戶端返回證書信息，該證書信息中攜帶有回源服務器在第三方證書管理部門注冊申請的數(shù)字證書。緩存服務器將回源服務器發(fā)送的證書信息轉發(fā)給客戶端，以便客戶端根據(jù)該證書信息對回源服務器的可靠性進行驗證。
[0109]本實施例中，回源服務器通過自身保存管理的私鑰對證書信息進行加密，客戶端使用對應該私鑰的公鑰對接收到的證書信息進行解密?；卦捶掌鞯墓€保存在第三方站點，網(wǎng)絡中的任何設備都可以向該第三方節(jié)點請求獲取該公鑰?？蛻舳丝梢愿鶕?jù)回源服務器的域名向第三方站點請求相應的公鑰，也可以接收與證書信息一同發(fā)送的公鑰。對于后者方式，回源服務器需要將自己的公連同證書信息發(fā)送給客戶端。
[0110]第三轉發(fā)單元53，用于在客戶端對證書信息進行驗證后，向回源服務器轉發(fā)客戶端發(fā)送的密鑰生成信息，以便回源服務器根據(jù)私鑰解密后獲得對稱密鑰。
[0111]客戶端通過回源服務器的公鑰對證書信息進行解密，查看其中記錄的域名是否與客戶端請求的域名一致。如果兩者一致，則說明客戶端請求的域名是回源服務器的真實域名，客戶端信賴回源服務器，完成對證書信息的驗證。如果兩者不一致，客戶端不信任回源服務器，握手連接失敗。
[0112]在通過驗證后，客戶端將秘鑰生成信息發(fā)送給緩存服務器，由緩存服務器將該信息轉發(fā)給回源服務器。秘鑰生成信息用于使回源服務器獲得與客戶端在后續(xù)通信過程中使用的加密密鑰，該加密密鑰是區(qū)別于前述私鑰、公鑰的另一個密鑰。由于客戶端和回源服務器在通信過程中使用相同的加密密鑰對HTTPS數(shù)據(jù)進行加密，因此這個加密密鑰又稱為對稱密鑰。
[0113]客戶端可以自己生成這個對稱密鑰，并將生成的對稱密鑰以密鑰生成信息的形式發(fā)送回源服務器。此外，客戶端也可以通過密鑰生成信息將生成對稱密鑰的必要信息(例如隨機數(shù))發(fā)送給回源服務器，由回源服務器根據(jù)該必要信息自己生成對稱密鑰。
[0114]本實施例中，客戶端可以使用回源服務器的公鑰對密鑰生成信息進行加密?；卦捶掌髟诮邮盏矫荑€生成信息后，通過自身保存管理的私鑰對密鑰生成信息進行解密，獲得對稱密鑰。
[0115]進一步的，第一轉發(fā)單元51用于根據(jù)握手請求信息中的域名向回源服務器轉發(fā)握手請求信息。
[0116]客戶端在向緩存服務器上報握手請求信息時，將回源服務器的域名一同發(fā)送給緩存服務器。緩存服務器將該域名發(fā)送給DNS服務器進行解析，獲得回源服務器的IP地址，然后以該IP地址作為目的IP地址，將握手請求信息發(fā)送給回源服務器。
[0117]進一步的，第三轉發(fā)單元53用于向回源服務器轉發(fā)客戶端生成的第一隨機數(shù)，以便回源服務器根據(jù)第一隨機數(shù)以及自身生成的第二隨機數(shù)，生成對稱密鑰；
[0118]進一步的，如圖6所示，該裝置還包括:
[0119]第四轉發(fā)單元54，用于向客戶端轉發(fā)回源服務器生成的第二隨機數(shù)，以便客戶端根據(jù)第一隨機數(shù)和第二隨機數(shù)生成與回源服務器相同的對稱密鑰。
[0120]實際應用中，客戶端可以使用偽隨機數(shù)發(fā)生器生成第一隨機數(shù)。回源服務器使用私鑰對接收到的第一隨機數(shù)進行解密，并生成一個第二隨機數(shù)，然后以第一隨機數(shù)和第二隨機數(shù)為基礎，通過預設算法生成對稱密鑰。實際應用中，回源服務器可以使用偽隨機數(shù)發(fā)生器生成第二隨機數(shù)。
[0121]回源服務器通過私鑰對生成的第二隨機數(shù)進行加密，通過緩存服務器將其發(fā)送給客戶端。客戶端使用公鑰對加密的第二隨機數(shù)進行解密，然后結合自身生成的第一隨機數(shù)，使用于回源服務器側相同的預設算法，生成相同的對稱密鑰。由此，客戶端和回源服務器兩側就分別獲得了根據(jù)第一隨機數(shù)和第二隨機數(shù)生成的對稱密鑰。由于兩側生成對稱密鑰的基礎都是第一隨機數(shù)和第二隨機數(shù)，而且使用了相同的預設算法，因此客戶端和回源服務器兩側生成的對稱密鑰是相同的。
[0122]進一步的，第二轉發(fā)單元52轉發(fā)的證書信息中攜帶有回源服務器生成的第二隨機數(shù)；
[0123]第三轉發(fā)單元53用于向回源服務器轉發(fā)客戶端生成的對稱密鑰，對稱密鑰為客戶端根據(jù)自身生成的第一隨時數(shù)以及接收的第二隨機數(shù)生成的對稱密鑰。
[0124]本實施例中，由客戶端根據(jù)第一隨機數(shù)和第二隨機數(shù)生成對稱密鑰，然后發(fā)送給回源服務器使用。因此回源服務器需要生成一個第二隨機數(shù)，并且將第二隨機數(shù)添加到證書信息中發(fā)送給客戶端?？蛻舳耸褂脗坞S機數(shù)發(fā)生器生成一個第一隨機數(shù)，然后結合證書信息中的第二隨機數(shù)，通過預設算法生成對稱密鑰，并將對稱密鑰發(fā)送給回源服務器使用?；卦捶掌魇褂盟借€解密獲得對稱密鑰，由此完成握手流程，客戶端與回源服務器兩側均獲得了相同的對稱密鑰。
[0125]進一步的，作為對上述方法的實現(xiàn)，本發(fā)明實施例還提供了一種客戶端與服務器進行握手的裝置。該裝置位于回源服務器中，或者獨立于回源服務器但是與回源服務器之間建立有數(shù)據(jù)交互關系，用以對上述方法進行實現(xiàn)。如圖7所示，該裝置包括:接收單元71、處理單元72及發(fā)送單元73。其中，
[0126]接收單元71，用于通過緩存服務器接收客戶端發(fā)送的握手請求信息，握手請求信息用于請求與回源服務器建立握手流程；
[0127]處理單元72，用于根據(jù)自身管理的私鑰對證書信息進行加密；
[0128]本實施例中，回源服務器的私鑰保存在回源服務器本地，而不開放給緩存服務器。因此需要回源服務器使用私鑰對證書信息進行加密。
[0129]發(fā)送單元73，用于通過緩存服務器向客戶端發(fā)送加密后的證書信息，以便客戶端對證書信息進行驗證；
[0130]如前所述，客戶端可以通過第三方站點或者回源服務器獲取對應該私鑰的公鑰?？蛻舳耸褂脤墓€對加密的證書信息進行解密，然后對證書信息進行驗證。當驗證通過時，客戶端生成秘鑰生成信息，并通過緩存服務器發(fā)送給回源服務器，而當驗證失敗時，握手流程終止。
[0131]本實施例中，客戶端使用回源服務器的公鑰對密鑰生成信息進行加密，然后將加密后的密鑰生成信息發(fā)送給緩存服務器進行轉發(fā)。
[0132]回源服務器將加密后的證書信息發(fā)送緩存服務器，由緩存服務器轉發(fā)給客戶端進行驗證。
[0133]接收單元71還用于通過緩存服務器接收客戶端發(fā)送的密鑰生成信息；
[0134]處理單元72還用于根據(jù)私鑰對密鑰生成信息進行解密，獲得對稱密鑰。
[0135]由于密鑰生成信息是通過與私鑰對應的公鑰加密的，因此可以通過私鑰解密?；卦捶掌髟谑褂盟借€對密鑰生成信息進行解密后，獲得對稱密鑰。
[0136]本實施例中，密鑰生成信息中可以直接攜帶客戶端生成的對稱密鑰，也可以僅攜帶生成加密密鑰的必要信息(例如隨機數(shù))，由回源服務器根據(jù)隨機數(shù)自行生成與客戶端側相同的對稱密鑰。
[0137]進一步的，接收單元71接收的密鑰生成信息為客戶端生成的第一隨機數(shù)；
[0138]如圖8所示，該裝置進一步包括:
[0139]生成單元74，用于根據(jù)第一隨機數(shù)和自身生成的第二隨機數(shù)生成對稱密鑰；
[0140]發(fā)送單元73，用于在獲得對稱密鑰之后，通過緩存服務器將第二隨機數(shù)發(fā)送給客戶端，以便客戶端根據(jù)第一隨機數(shù)和第二隨機數(shù)生成相同的對稱密鑰。
[0141]實際應用中，客戶端可以使用偽隨機數(shù)發(fā)生器生成第一隨機數(shù)?；卦捶掌魇褂盟借€對接收到的第一隨機數(shù)進行解密，并生成一個第二隨機數(shù)，然后以第一隨機數(shù)和第二隨機數(shù)為基礎，通過預設算法生成對稱密鑰。實際應用中，回源服務器可以使用偽隨機數(shù)發(fā)生器生成第二隨機數(shù)。
[0142]回源服務器通過私鑰對生成的第二隨機數(shù)進行加密，通過緩存服務器將其發(fā)送給客戶端。客戶端使用公鑰對加密的第二隨機數(shù)進行解密，然后結合自身生成的第一隨機數(shù)，使用于回源服務器側相同的預設算法，生成相同的對稱密鑰。由此，客戶端和回源服務器兩側就分別獲得了根據(jù)第一隨機數(shù)和第二隨機數(shù)生成的對稱密鑰。由于兩側生成對稱密鑰的基礎都是第一隨機數(shù)和第二隨機數(shù)，而且使用了相同的預設算法，因此客戶端和回源服務器兩側生成的對稱密鑰是相同的。
[0143]進一步的，發(fā)送單元73發(fā)送的證書信息中攜帶有回源服務器生成的第二隨機數(shù)；
[0144]接收單元71用于通過緩存服務器接收客戶端發(fā)送的對稱密鑰，對稱密鑰為客戶端根據(jù)自身生成的第一隨機數(shù)以及證書信息中的第二隨機數(shù)生成的對稱密鑰。
[0145]本實施例中，由客戶端根據(jù)第一隨機數(shù)和第二隨機數(shù)生成對稱密鑰，然后發(fā)送給回源服務器使用。因此回源服務器需要生成一個第二隨機數(shù)，并且將第二隨機數(shù)添加到證書信息中發(fā)送給客戶端?？蛻舳耸褂脗坞S機數(shù)發(fā)生器生成一個第一隨機數(shù)，然后結合證書信息中的第二隨機數(shù)，通過預設算法生成對稱密鑰，并將對稱密鑰發(fā)送給回源服務器使用。回源服務器使用私鑰解密獲得對稱密鑰，由此完成握手流程，客戶端與回源服務器兩側均獲得了相同的對稱密鑰。
[0146]進一步的，作為對上述方法的實現(xiàn)，本發(fā)明實施例還提供了一種客戶端與服務器進行握手的系統(tǒng)。如圖9所示，該系統(tǒng)包括客戶端91、緩存服務器92以及回源服務器93。其中，緩存服務器92包含如前圖5或圖6所示的裝置，或者獨立于該裝置但是與該裝置具有數(shù)據(jù)交互關系；回源服務器93包含如前圖7或圖8所示的裝置，或者獨立于該裝置但是與該裝置具有數(shù)據(jù)交互關系。
[0147]客戶端91，用于通過緩存服務器92向回源服務器93發(fā)送握手請求信息，握手請求信息用于請求與回源服務器93建立握手流程；
[0148]該握手請求信息由客戶端91發(fā)出，用于請求與回源服務器93建立握手流程。在⑶N網(wǎng)絡中，客戶端91與回源服務器93之間的一切信息交互全部通過緩存服務器92轉發(fā)?？蛻舳?1向回源服務器93發(fā)送的握手請求信息發(fā)送給緩存服務器92。緩存服務器92接收到握手請求信息后，將該信息轉發(fā)給相應的回源服務器93。所謂相應的回源服務器93是指客戶端91請求建立握手連接的回源服務器93。
[0149]回源服務器93，用于根據(jù)自身管理的私鑰對證書信息進行加密，通過緩存服務器92向客戶端91發(fā)送加密后的證書信息；
[0150]回源服務器93接收到握手請求信息后向客戶端91返回證書信息，該證書信息中攜帶有回源服務器93在第三方證書管理部門注冊申請的數(shù)字證書。緩存服務器92將回源服務器93發(fā)送的證書信息轉發(fā)給客戶端91，以便客戶端91根據(jù)該證書信息對回源服務器93的可靠性進行驗證。
[0151]客戶端91還用于對證書信息進行驗證，并通過緩存服務器92向回源服務器93發(fā)送密鑰生成信息；
[0152]回源服務器93還用于通過私鑰對密鑰生成信息進行解密，獲得對稱密鑰。
[0153]客戶端91通過回源服務器93的公鑰對證書信息進行解密，查看其中記錄的域名是否與客戶端91請求的域名一致。如果兩者一致，則說明客戶端91請求的域名是回源服務器93的真實域名，客戶端91信賴回源服務器93，完成對證書信息的驗證。如果兩者不一致，客戶端91不信任回源服務器93，握手連接失敗。
[0154]在通過驗證后，客戶端91將秘鑰生成信息發(fā)送給緩存服務器92，由緩存服務器92將該信息轉發(fā)給回源服務器93。秘鑰生成信息用于使回源服務器93獲得與客戶端91在后續(xù)通信過程中使用的加密密鑰，該加密密鑰是區(qū)別于前述私鑰、公鑰的另一個密鑰。由于客戶端91和回源服務器93在通信過程中使用相同的加密密鑰對HTTPS數(shù)據(jù)進行加密，因此這個加密密鑰又稱為對稱密鑰。
[0155]本實施例提供的客戶端與服務器進行握手的裝置及系統(tǒng)，能夠由回源服務器直接與客戶端進行握手，緩存服務器僅對兩者交互的握手信息進行代理轉發(fā)。由于轉發(fā)不涉及對往來信息的加解密，因此緩存服務器無需使用回源服務器的私鑰。與現(xiàn)有技術中由緩存服務器與客戶端進行握手相比，本實施例無需向緩存服務器開放回源服務器的私鑰，因此可以消除通過第三方泄露站點私鑰的隱患，由此提高私鑰部署的安全性。
[0156]以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡單元上。可以根據(jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本實施例方案的目的。本領域普通技術人員在不付出創(chuàng)造性的勞動的情況下，即可以理解并實施。
[0157]通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到各實施方式可借助軟件加必需的通用硬件平臺的方式來實現(xiàn)，當然也可以通過硬件?；谶@樣的理解，上述技術方案本質上或者說對現(xiàn)有技術做出貢獻的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品可以存儲在計算機可讀存儲介質中，如R0M/RAM、磁碟、光盤等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網(wǎng)絡設備等)執(zhí)行各個實施例或者實施例的某些部分所述的方法。
[0158]最后應說明的是:以上實施例僅用以說明本發(fā)明的技術方案，而非對其限制；盡管參照前述實施例對本發(fā)明進行了詳細的說明，本領域的普通技術人員應當理解:其依然可以對前述各實施例所記載的技術方案進行修改，或者對其中部分技術特征進行等同替換；而這些修改或者替換，并不使相應技術方案的本質脫離本發(fā)明各實施例技術方案的精神和范圍。
【主權項】
1.一種客戶端與服務器進行握手的方法，其特征在于，所述方法包括: 緩存服務器向回源服務器轉發(fā)客戶端發(fā)送的握手請求信息，所述握手請求信息用于請求與回源服務器建立握手流程； 向客戶端轉發(fā)回源服務器發(fā)送的證書信息，所述證書信息由回源服務器根據(jù)私鑰進行加密； 在客戶端對證書信息進行驗證后，向回源服務器轉發(fā)客戶端發(fā)送的密鑰生成信息，以便回源服務器根據(jù)私鑰解密后獲得對稱密鑰。2.根據(jù)權利要求1所述的方法，其特征在于，所述向回源服務器轉發(fā)客戶端發(fā)送的握手請求信息，包括: 根據(jù)握手請求信息中的域名向回源服務器轉發(fā)握手請求信息。3.根據(jù)權利要求1所述的方法，其特征在于，所述向回源服務器轉發(fā)客戶端發(fā)送的密鑰生成信息，包括: 向回源服務器轉發(fā)客戶端生成的第一隨機數(shù)，以便回源服務器根據(jù)第一隨機數(shù)以及自身生成的第二隨機數(shù)，生成對稱密鑰； 所述方法進一步包括: 向客戶端轉發(fā)回源服務器生成的第二隨機數(shù)，以便客戶端根據(jù)第一隨機數(shù)和第二隨機數(shù)生成與回源服務器相同的對稱密鑰。4.根據(jù)權利要求1所述的方法，其特征在于，所述證書信息中攜帶有回源服務器生成的第二隨機數(shù)； 所述向回源服務器轉發(fā)客戶端發(fā)送的密鑰生成信息，包括: 向回源服務器轉發(fā)客戶端生成的對稱密鑰，所述對稱密鑰為客戶端根據(jù)自身生成的第一隨時數(shù)以及接收的第二隨機數(shù)生成的對稱密鑰。5.一種客戶端與服務器進行握手的方法，其特征在于，所述方法包括: 回源服務器通過緩存服務器接收客戶端發(fā)送的握手請求信息，所述握手請求信息用于請求與回源服務器建立握手流程； 根據(jù)自身管理的私鑰對證書信息進行加密； 通過緩存服務器向客戶端發(fā)送加密后的證書信息，以便客戶端對證書信息進行驗證； 通過緩存服務器接收客戶端發(fā)送的密鑰生成信息； 根據(jù)私鑰對密鑰生成信息進行解密，獲得對稱密鑰。6.根據(jù)權利要求5所述的方法，其特征在于，所述密鑰生成信息為客戶端生成的第一隨機數(shù)； 所述方法進一步包括: 根據(jù)第一隨機數(shù)和自身生成的第二隨機數(shù)生成對稱密鑰； 在所述獲得對稱密鑰之后，所述方法進一步包括: 通過緩存服務器將第二隨機數(shù)發(fā)送給客戶端，以便客戶端根據(jù)第一隨機數(shù)和第二隨機數(shù)生成相同的對稱密鑰。7.根據(jù)權利要求5所述的方法，其特征在于，所述證書信息中攜帶有回源服務器生成的第二隨機數(shù)； 所述通過緩存服務器接收客戶端發(fā)送的密鑰生成信息，包括: 通過緩存服務器接收客戶端發(fā)送的對稱密鑰，所述對稱密鑰為客戶端根據(jù)自身生成的第一隨機數(shù)以及證書信息中的第二隨機數(shù)生成的對稱密鑰。8.一種客戶端與服務器進行握手的裝置，所述裝置位于緩存服務器一側，其特征在于，所述裝置包括: 第一轉發(fā)單元，用于向回源服務器轉發(fā)客戶端發(fā)送的握手請求信息，所述握手請求信息用于請求與回源服務器建立握手流程； 第二轉發(fā)單元，用于向客戶端轉發(fā)回源服務器發(fā)送的證書信息，所述證書信息由回源服務器根據(jù)私鑰進行加密； 第三轉發(fā)單元，用于在客戶端對證書信息進行驗證后，向回源服務器轉發(fā)客戶端發(fā)送的密鑰生成信息，以便回源服務器根據(jù)私鑰解密后獲得對稱密鑰。9.根據(jù)權利要求8所述的裝置，其特征在于，所述第一轉發(fā)單元用于根據(jù)握手請求信息中的域名向回源服務器轉發(fā)握手請求信息。10.根據(jù)權利要求8所述的裝置，其特征在于，所述第三轉發(fā)單元用于向回源服務器轉發(fā)客戶端生成的第一隨機數(shù)，以便回源服務器根據(jù)第一隨機數(shù)以及自身生成的第二隨機數(shù)，生成對稱密鑰； 所述裝置還包括: 第四轉發(fā)單元，用于向客戶端轉發(fā)回源服務器生成的第二隨機數(shù)，以便客戶端根據(jù)第一隨機數(shù)和第二隨機數(shù)生成與回源服務器相同的對稱密鑰。11.根據(jù)權利要求8所述的裝置，其特征在于，所述第二轉發(fā)單元轉發(fā)的所述證書信息中攜帶有回源服務器生成的第二隨機數(shù)； 所述第三轉發(fā)單元用于向回源服務器轉發(fā)客戶端生成的對稱密鑰，所述對稱密鑰為客戶端根據(jù)自身生成的第一隨時數(shù)以及接收的第二隨機數(shù)生成的對稱密鑰。12.—種客戶端與服務器進行握手的裝置，所述裝置位于回源服務器一側，其特征在于，所述裝置包括: 接收單元，用于通過緩存服務器接收客戶端發(fā)送的握手請求信息，所述握手請求信息用于請求與回源服務器建立握手流程； 處理單元，用于根據(jù)自身管理的私鑰對證書信息進行加密； 發(fā)送單元，用于通過緩存服務器向客戶端發(fā)送加密后的證書信息，以便客戶端對證書信息進行驗證； 所述接收單元還用于通過緩存服務器接收客戶端發(fā)送的密鑰生成信息； 所述處理單元還用于根據(jù)私鑰對密鑰生成信息進行解密，獲得對稱密鑰。13.根據(jù)權利要求12所述的裝置，其特征在于，所述接收單元接收的所述密鑰生成信息為客戶端生成的第一隨機數(shù)； 所述裝置進一步包括: 生成單元，用于根據(jù)第一隨機數(shù)和自身生成的第二隨機數(shù)生成對稱密鑰； 所述發(fā)送單元，用于在獲得對稱密鑰之后，通過緩存服務器將第二隨機數(shù)發(fā)送給客戶端，以便客戶端根據(jù)第一隨機數(shù)和第二隨機數(shù)生成相同的對稱密鑰。14.根據(jù)權利要求12所述的裝置，其特征在于，所述發(fā)送單元發(fā)送的所述證書信息中攜帶有回源服務器生成的第二隨機數(shù)； 所述接收單元用于通過緩存服務器接收客戶端發(fā)送的對稱密鑰，所述對稱密鑰為客戶端根據(jù)自身生成的第一隨機數(shù)以及證書信息中的第二隨機數(shù)生成的對稱密鑰。15.一種客戶端與服務器進行握手的系統(tǒng)，其特征在于，所述系統(tǒng)包括客戶端、緩存服務器及回源服務器，其中: 所述客戶端，用于通過所述緩存服務器向所述回源服務器發(fā)送握手請求信息，所述握手請求信息用于請求與所述回源服務器建立握手流程； 所述回源服務器，用于根據(jù)自身管理的私鑰對證書信息進行加密，通過所述緩存服務器向所述客戶端發(fā)送加密后的證書信息； 所述客戶端還用于對證書信息進行驗證，并通過所述緩存服務器向所述回源服務器發(fā)送密鑰生成信息； 所述回源服務器還用于通過私鑰對所述密鑰生成信息進行解密，獲得所述對稱密鑰。
【文檔編號】H04L29/08GK105871797SQ201510802482
【公開日】2016年8月17日
【申請日】2015年11月19日
【發(fā)明人】孫國良
【申請人】樂視云計算有限公司