一種對中間人的存在進行辨識的方法及裝置的制造方法
【技術領域】
[0001]本申請涉及計算機技術領域，尤其涉及一種對中間人的存在進行辨識的方法及裝置。
【背景技術】
[0002]在很多情況下，互聯網使用者需要使用非私有終端上網，如使用公司或者網吧提供的電腦上網。對于此類終端的擁有者，其對于安全的需求與終端的實際使用者對于安全的需求并不完全一致，有時甚至會發生沖突。比如:對于實際使用者，會希望在上網過程中，其個人隱私如銀行賬號密碼等不被窺探；而對于企業而言，為了防止其內部機密被惡意泄露或者為了提升員工的工作效率，則希望對實際使用者的上網流量作掃描或者審計，從而確定實際使用者利用終端所傳輸的具體信息。
[0003]一般地，對于非加密流量，簡單的基于流的掃描就可以達到監控信息的目的；而對于米用安全超文本傳輸協議(Hyper Text Transfer Protocol over Secure SocketLayer, HTTPS)等安全套接層(Secure Sockets Layer, SSL)協議進行加密得到的加密流量，則需要通過代理技術才能實現信息監控。一種典型的代理技術的實現示意圖如圖1所示。
[0004]圖1中，左側方框代表企業的終端中安裝的客戶端(Web Client)，中間方框代表在企業網絡出口處的網關或防火墻設備部署的SSL代理(SSL Proxyl，在圖1所示的場景中，其一般被稱為“中間人”)，右邊方框代表客戶端所訪問的網站服務器，具體而言，該服務器的名稱可以是圖1中所示的“Alipay Web Server”。
[0005]圖1中，具備監控終端所傳輸的具體信息這一功能的是SSL代理，該功能的實現原理大致為:SSL代理劫持來自客戶端的SSL握手請求，然后利用該SSL握手請求發起與真實服務器的SSL連接；在與服務器側的SSL握手成功后，再恢復與客戶端的SSL握手，并在與客戶端進行SSL握手時，向客戶端推送一本偽造的證書，使得客戶端信任SSL代理，進而可以獲取客戶端所發送的信息。
[0006]需要說明的是，根據SSL協議的設計，其具備一致性檢查能力，即當遭受到中間人攻擊時，客戶端會彈出告警，告知用戶“當前接收到的證書非法”。然而，對公司而言，該告警實際上是由自身部署的SSL代理所致，并非公司網絡受到實際攻擊，因此，考慮到彈出的告警會影響實際使用者的上網體驗或者工作效率，一般會采用下述手段I和手段2，抑制客戶端彈出告警:
[0007]手段1:使用SSL代理的自簽名證書為客戶端簽發證書時，在簽發的證書中保持真實服務器的域名/Subject/Valid等信息。
[0008]手段2:將上述自簽名證書作為可信電子商務認證授權機構(CertificateAuthority, CA)證書，導入到客戶端中。
[0009]結合上述手段I和手段2，可以使得終端對SSL代理簽發的證書進行驗證時，會認為該證書是合法證書，從而得到客戶端信任。
[0010]通過上述方式，一個典型的信息監控過程可以包括如圖1所示的如下步驟:
[0011]1、客戶端向服務器發起SSL握手請求；
[0012]2、SSL代理劫持來自客戶端的SSL握手請求；
[0013]3、SSL代理向服務器發起SSL連接請求；
[0014]4、服務器響應SSL代理發起的SSL連接請求，并發送服務器自身的證書給SSL代理；
[0015]5、SSL代理根據服務器(即真實服務器)的證書，使用自簽名證書重新簽發一本證書(后文稱新生成證書)；
[0016]由前文所述的手段2可知，客戶端會認為SSL代理使用的自簽名證書是可信CA證書，從而后續客戶端在對新生成證書進行校驗時，也會依據該自簽名證書簽發的該新生成證書是可信的。
[0017]6、SSL代理將新生成證書推送給客戶端；
[0018]7、客戶端使用本地可信CA證書對收到的新生成證書做校驗，校驗通過；
[0019]8、客戶端向服務器請求登錄頁面；
[0020]9、服務器向客戶端回送登錄頁面；
[0021]10、客戶端發送包含登錄信息密文的HTTP POST (HTTP POST是一種HTTP請求)；
[0022]11、SSL代理對包含登錄信息密文的HTTP POST進行解密，得到登錄信息明文。
[0023]上述方案的缺陷在于，終端對于SSL代理的存在是無感知的，從而當終端的實際使用者訪問隱私或者金融類的HTTPS網站時，會將實際使用者的用戶名密碼信息等明文信息暴露給SSL代理，從而使得該些信息受到潛在的安全威脅。
[0024]類似地，在客戶端與服務器之間存在設置在其他協議層的中間人的場景下，也會存在上述問題。
【發明內容】
[0025]本申請實施例提供一種對中間人的存在進行辨識的方法，用以解決由于客戶端無法辨識客戶端與服務器之間是否存在中間人，從而可能使得傳輸的信息受到潛在的安全威脅的問題。
[0026]本申請實施例還提供一種對中間人的存在進行辨識的裝置，用以解決由于客戶端無法辨識客戶端與服務器之間是否存在中間人，從而可能使得傳輸的信息受到潛在的安全威脅的問題。
[0027]本申請實施例采用下述技術方案:
[0028]一種對中間人的存在進行辨識的方法，包括:獲得在客戶端與服務器的握手過程中由客戶端接收的服務器的第一證書相關信息，以及在所述客戶端與所述服務器的非握手過程中由客戶端接收的所述服務器的第二證書相關信息；判斷第一證書相關信息和第二證書相關?目息是否匹配。
[0029]一種對中間人的存在進行辨識的裝置，包括:信息獲得單元，用于獲得在客戶端與服務器的握手過程中由客戶端接收的服務器的第一證書相關信息，以及在所述客戶端與所述服務器的非握手過程中由客戶端接收的所述服務器的第二證書相關信息；辨識單元，用于判斷信息獲得單元獲得的第一證書相關信息和第二證書相關信息是否匹配。
[0030]本申請實施例采用的上述至少一個技術方案能夠達到以下有益效果:
[0031]當設置有中間人時，該中間人僅會在客戶端與服務器的握手過程中利用自身的自簽名證書和服務器的身份信息(如域名/Subject/Valid等信息)，得到新生成證書，而對客戶端與服務器的非握手過程中傳遞的服務器的證書相關信息不會執行類似操作，即非握手過程中傳遞的服務器的證書相關信息仍然是服務器的真實證書相關信息。因此，通過比較握手過程和非握手過程中接收的同一服務器的證書相關信息，可以達到辨識是否存在中間人的目的。
【附圖說明】
[0032]此處所說明的附圖用來提供對本申請的進一步理解，構成本申請的一部分，本申請的示意性實施例及其說明用于解釋本申請，并不構成對本申請的不當限定。在附圖中:
[0033]圖1為現有技術中采用代理技術監控終端所傳輸的具體信息的實現原理示意圖；
[0034]圖2為本申請實施例提供的一種對中間人的存在進行辨識的方法的實現流程示意圖；
[0035]圖3為本申請實施例2提供一種防范中間人攻擊的方法的實現流程示意圖；
[0036]圖4為本申請實施例3提供的一種對中間人的存在進行辨識的裝置的具體結構示意圖。
【具體實施方式】
[0037]為使本申請的目的、技術方案和優點更加清楚，下面將結合本申請具體實施例及相應的附圖對本申請技術方案進行清楚、完整地描述。顯然，所描述的實施例僅是本申請一部分實施例，而不是全部的實施例。基于本申請中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬于本申請保護的范圍。
[0038]以下結合附圖，詳細說明本申請各實施例提供的技術方案。
[0039]實施例1
[0040]為了解決客戶端無法辨識客戶端與服務器之間是否存在中間人的問題，本申請實施例I提供一種對中間人的存在進行辨識的方法。該方法的具體實現流程示意圖如圖2所示，包括如下步驟:
[0041]步驟21，獲得在客戶端與服務器的握手過程中由客戶端接收的服務器的第一證書相關信息，以及在客戶端與服務器的非握手過程中由客戶端接收的該服務器的第二證書相關信息；
[0042]步驟22，判斷第一證書相關信息和第二證書相關信息是否匹配。
[0043]其中，上述“證書相關信息”可以包括證書本身，也可以包括與證書密切相關的信息，比如通過對證書進行哈希運算而得到的哈希值等。
[0044]采用實施例1提供的上述方法，當設置有中間人時，該中間人僅會在客戶端與服務器的握手過程中利用自身的自簽名證書和服務器的身份信息(如域名/Subject/Valid等信息)，得到新生成證書，而對在客戶端與服務器的非握手過程中傳遞的服務器的證書相關信息不會執行類似操作，即在客戶端與服務器的非握手過