信息處理方法、網關及驗證平臺與流程

2023-09-22 14:48:20

本發明涉及通信領域，尤其涉及一種信息處理方法、網關及驗證平臺。

背景技術：

為了對超文本傳輸協議(hypertexttransferprotocol，http)報文進行內容計費，目前業界普遍採用基於加密層(transportlayersecurity，tls)流程中初始協商消息中帶的明文欄位(servernameindication，sni)，該欄位用於標識業務的域名信息。但存在客戶端和伺服器配合作假，把sni欄位設置為免流的欄位，造成流量的盜用。所以伺服器如何校驗sni欄位的真實性是一個待解決的問題。

技術實現要素：

有鑑於此，本發明實施例期望提供一種信息處理方法、網關及驗證平臺，至少部分解決sni欄位導致的計費的精準性差的問題。

為達到上述目的，本發明的技術方案是這樣實現的：

本發明實施例第一方面提供一種信息處理方法，包括：

獲取伺服器的ip地址；

識別伺服器名字指示sni欄位，獲取所述伺服器的域名；

基於所述域名和所述ip地址進行可信度驗證；

基於所述可信度驗證的結果，確定業務數據包的內容計費策略。

基於上述方案，所述基於所述域名和所述ip地址進行可信度驗證，包括：

判斷所述域名和所述ip地址是否位於可信列表和不可信列表中；

若所述域名和ip地址位於所述可信列表中，則直接根據所述sni欄位確定計費策略；

若所述域名和ip地址位於所述不可信列表中，則結合所述sni信息校正計費策略。

基於上述方案，所述基於所述域名和所述ip地址進行可信度驗證，還可包括：

若所述域名和所述ip地址既然不位於所述可信列表，也不位於所述不可信列表中，則將所述域名和所述ip地址發送給驗證平臺，進行所述可信度驗證；

接收所述驗證平臺進行所述可信度驗證的驗證結果。

基於上述方案，所述方法還包括：

根據所述驗證結果，更新所述可信列表或所述不可信列表。

基於上述方案，所述方法還包括：

若所述域名和所述ip地址既然不位於所述可信列表，也不位於所述不可信列表中，轉發業務數據包並按照所述sni欄位進行首次計費。

本發明實施例第二方面提供一種信息處理方法，包括：

接收網關發送的域名和ip地址；其中，所述域名為基於數據包中的伺服器名字指示sni欄位確定的；

對所述域名和所述ip地址進行驗證，並形成驗證結果；

將所述驗證結果發送給所述網關；其中，所述驗證結果，能夠用於為所述網關進行內容計費提供依據。

基於上述方案，所述對所述域名和所述ip地址進行驗證，並形成驗證結果，包括：

依據所述域名和所述ip地址，查詢黑名單和/或白名單，根據查詢結果形成所述驗證結果；其中，所述黑名單為包括不可信的域名和ip地址；所述白名單包括可信的域名和ip地址。

基於上述方案，所述對所述域名和所述ip地址進行驗證，並形成驗證結果，包括：

當所述黑名單和白名單中都不包括所述域名和所述ip地址時，根據所述域名查詢預製證書，以獲取所述ip地址對應的密鑰信息；

依據所述密鑰信息，向所述ip地址發送驗證信息；

接收所述ip地址返回的驗證信息，形成所述驗證結果。

基於上述方案，所述方法還包括：

根據所述驗證結果，更新所述黑名單或白名單。

本發明實施例第三方面提供一種網關，包括：

獲取單元，用於獲取伺服器的ip地址；

識別單元，用於識別伺服器名字指示sni欄位，獲取所述伺服器的域名；

第一驗證單元，用於基於所述域名和所述ip地址進行可信度驗證；

確定單元，用於基於所述可信度驗證的結果，確定業務數據包的內容計費策略。

基於上述方案，所述第一驗證單元，具體用於判斷所述域名和所述ip地址是否位於可信列表和不可信列表中；

所述確定單元，具體用於若所述域名和ip地址位於所述可信列表中，則直接根據所述sni欄位確定計費策略；若所述域名和ip地址位於所述不可信列表中，則結合所述sni信息校正計費策略。

基於上述方案，所述第一驗證單元，具體用於若所述域名和所述ip地址既然不位於所述可信列表，也不位於所述不可信列表中，則將所述域名和所述ip地址發送給驗證平臺，進行所述可信度驗證；接收所述驗證平臺進行所述可信度驗證的驗證結果。

基於上述方案，所述網關還包括：

第一更新單元，用於根據所述驗證結果，更新所述可信列表或所述不可信列表。

基於上述方案，所述網關還包括：

通信單元，用於若所述域名和所述ip地址既然不位於所述可信列表，也不位於所述不可信列表中，轉發業務數據包並按照所述sni欄位進行首次計費。

本發明實施例第四方面提供一種驗證平臺，包括：

接收單元，用於接收網關發送的域名和ip地址；其中，所述域名為基於數 據包中的伺服器名字指示sni欄位確定的；

第二驗證單元，用於對所述域名和所述ip地址進行驗證，並形成驗證結果；

發送單元，用於將所述驗證結果發送給所述網關；其中，所述驗證結果，能夠用於為所述網關進行內容計費提供依據。

基於上述方案，所述第二驗證單元，具體用於依據所述域名和所述ip地址，查詢黑名單和/或白名單，根據查詢結果形成所述驗證結果；其中，所述黑名單為包括不可信的域名和ip地址；所述白名單包括可信的域名和ip地址。

基於上述方案，所述第二驗證單元，還用於當所述黑名單和白名單中都不包括所述域名和所述ip地址時，根據所述域名查詢預製證書，以獲取所述ip地址對應的密鑰信息；依據所述密鑰信息，向所述ip地址發送驗證信息；接收所述ip地址返回的驗證信息，形成所述驗證結果。

基於上述方案，所述驗證平臺還包括：

第二更新單元，用於根據所述驗證結果，更新所述黑名單或白名單。

本發明實施例提供一種信息處理方法、網關及驗證平臺，在tls連接建立的過程中，會對域名和ip地址之間的對應關係進行驗證，以驗證sni欄位中攜帶的域名是真實的，以減少sin欄位中攜帶者偽造的域名或與ip地址不對應的域名導致的基於該sni欄位進行收費導致的計費精確度低的現象。

附圖說明

圖1為本發明實施例提供的第一種信息處理方法的流程示意圖；

圖2為本發明實施例提供的第二種信息處理方法的流程示意圖；

圖3為本發明實施例提供的對域名和ip地址進行驗證的驗證流程示意圖；

圖4為本發明實施例提供的一種網關的結構示意圖；

圖5為本發明實施例提供的一種驗證平臺的結構示意圖；

圖6為本發明實施例提供的一種信息系統結構示意圖；

圖7為本發明實施例提供的第三種信息處理方法的流程示意圖。

具體實施方式

以下結合說明書附圖及具體實施例對本發明的技術方案做進一步的詳細闡述。

實施例一：

如圖1所示，本實施例提供一種信息處理方法，包括：

步驟s110：獲取伺服器的ip地址；

步驟s120：識別伺服器名字指示sni欄位，獲取所述伺服器的域名；

步驟s130：基於所述域名和所述ip地址進行可信度驗證；

步驟s140：基於所述可信度驗證的結果，確定業務數據包的內容計費策略。

本實施例所述的信息處理方法，為能夠應用於網關中的信息處理方法，本實施例中所述的網關可包括路由器。

在步驟s110中獲取伺服器的ip地址，可包括網關與伺服器建立傳輸控制協議(transportcontrollerprotocol，tcp)連接，在建立tcp連接時就可以將獲得伺服器的ip地址。

在步驟s120中識別所述sni欄位，通常sni欄位是明文信息，故網關直接可以通過解碼就能夠獲得sni欄位中的域名。通常在進行計費時，根據該域名來進行計費。

在步驟s130中將對該域名和ip地址進行可信度驗證，避免域名造假導致的計費結果不準確的問題。網關在進行數據轉發時，是根據數據包中的目的ip地址進行數據包的轉發的，而計費則時根據sni欄位中的域名來處理的。若出現sni欄位造假，即sni中的域名並非目的ip地址的域名，就有可能將收費的數據包，視為免費的數據包給轉發了，從而導致計費結果的不準確。在本實施例中為了防止這種現象的產生，在本實施例中網關增加了進行可信度驗證的步驟。

在步驟s130中，將根據可信度驗證的結果進行內容計費處理。具體可包括，若sni欄位表明是免費的，且驗證結果表示為可信，則直接對該數據包進行免 費。若sni欄位表示是免費的，而驗證結果表明是不可信的，也可對該數據包進行收費處理。顯然這樣可以提高收費的準確度。

作為本實施例的進一步改進，在所述網關中存儲有可信列表和非可信列表。通常可信列表中包括的域名和ip地址的對應關係，表示域名和ip地址之間的對應關係是正確的，不會存在ip地址或域名的偽造或錯誤。非可信列表中的域名和ip地址之間的對應關係是非可信的，表示域名或ip地址的至少其中之一有錯誤。故在本實施例中，所述步驟s130可包括：判斷所述域名和所述ip地址是否位於可信列表和不可信列表中；若所述域名和ip地址位於所述可信列表中，則直接根據所述sni欄位確定計費策略；若所述域名和ip地址位於所述不可信列表中，則結合所述sni信息校正計費策略。顯然，這樣可以簡便的避免sni欄位造假導致的計費結果不精確的問題。在本實施例中若步驟s110中提取的域名和步驟s120中獲取的ip地址對應位於所述可信列表中，表示所述sni欄位可信，可以直接根據所述sni欄位確定出內容計費策略。若域名和ip地址的這種對應關係位於非可信列表中，則需要校正內容計費策略。通常情況下，非法用戶為了避免計費，會將收費業務數據，通過位置sni欄位的內容，改變成免費數據，則此時需要將免費策略校正為計費策略。還有一種可能是sni欄位中原本要存儲的收費較高的域名修改成收費較低的域名，這個時候，需要將計費策略中的計費單價恢復到較高的計費。

進一步地，所述步驟s130還可包括：

若所述域名和所述ip地址既然不位於所述可信列表，也不位於所述不可信列表中，則將所述域名和所述ip地址發送給驗證平臺，進行所述可信度驗證；

接收所述驗證平臺進行所述可信度驗證的驗證結果。

若當前域名和ip地址是第一次獲取到，這個時候，需要重新驗證。在本實施例中所述網關可以將所述域名和ip地址發送給驗證平臺，由驗證平臺來進行驗證。

在具體的實現過程中，所述網關也可以自行進行驗證。例如，所述網關與該ip地址對應的伺服器重新發起tls連結建立，在所述網關中存儲有該域名 對應的預製證書。所述網關可以通過查詢該預製證書，確定出向該域名對應的所述ip地址發送驗證信息的密鑰，該密鑰通常為公鑰。若所述域名和所述ip地址都並非偽造的，則所述ip地址應該能夠接收並解碼所述驗證信息，再接收到所述驗證信息之後，將會向網關反饋信息，這個時候所述網關就可以根據反饋信息來確定出所述域名和所述ip地址的對應關係是否正確，進而在步驟s140中確定出是否可以根據該sni欄位直接進行計費。例如，所述反饋信息表明接收驗證信息的一方，正確解碼了驗證信息，則認為該域名和ip地址之間的對應關係是正確的，是不存在偽造的條件的。

當然，具體實現時，可以由驗證平臺來實現上述驗證處理，而網關僅直接接收驗證結果就好。

延續上述實施例，所述方法還包括：

根據所述驗證結果，更新所述可信列表或所述不可信列表。

若驗證結果表明，所述域名和所述ip地址不可信，則將該域名和該ip地址添加到所述不可信列表中，則下次在出現該域名和ip地址時，就可以直接認為出現造假現象，應該進行內容收費。若所述域名和ip地址可信，則將該域名和該ip地址添加到所述可信列表中，方便後續數據包的快速轉發及計費處理。

在本實施例中為了，避免可信sni欄位，因未記載網關中的可信列表中導致的延時問題，在本實施例中所述方法還包括：

若所述域名和所述ip地址既然不位於所述可信列表，也不位於所述不可信列表中，轉發業務數據包並按照所述sni欄位進行首次計費。即網關一邊對所述域名和ip地址發送給網關進行驗證，或自行根據預製證書繼續驗證，一邊轉發數據包，避免數據包的延時，若下次再出現類似的數據包，則可以根據當前次驗證的結果進行數據中sni欄位的再次驗證，一方面提升了收費的精準性，另一方面減少了因驗證導致的時延大的問題。

在具體的實現過程中，若驗證出sni欄位攜帶的域名與伺服器的ip地址的對應關係不正確，存在偽造和篡改的嫌疑，向指定設備發送提示信息，例如，向發送業務數據包的兩端發送提示信息，和通信運營商的監控設備發送提示信 息，以通過提示信息，告知當前sni欄位存在域名偽造和篡改的嫌疑，方便後續的監控，從源頭上減少sni欄位偽造和篡改的嫌疑。

實施例二：

如圖2所示，本實施例提供一種信息處理方法，其特徵在於，包括：

步驟s210：接收網關發送的域名和ip地址；其中，所述域名為基於數據包中的伺服器名字指示sni欄位確定的；

步驟s220：對所述域名和所述ip地址進行驗證，並形成驗證結果；

步驟s230：將所述驗證結果發送給所述網關；其中，所述驗證結果，能夠用於為所述網關進行內容計費提供依據。

本實施例所述的方法，可為應用於驗證平臺中的方法，在本實施例中所述驗證平臺可又一臺或多臺伺服器構成，也可以由一臺或多臺具有驗證功能的虛擬機構成。

在本實施例中步驟s210中將從路由器等網關接收域名和ip地址，此時的域名為可為從sni欄位中提取的。

在步驟s220中將進行域名和ip地址的驗證，並形成驗證結果。

在步驟s230中將驗證結果發送給網關，方便網關對數據包的轉發進行收費等處理。

在本實施例中所述驗證平臺將協助網關進行域名和ip地址是否可信的驗證，以提升網關進行計費的精準度。

所述步驟s220的實現方式有多種，以下提供幾種可實現方式：

方式一：

如圖3所示，所述步驟s220可包括：

步驟s221：根據所述域名查詢預製證書，以獲取所述ip地址對應的密鑰信息；

步驟s222：依據所述密鑰信息，向所述ip地址發送驗證信息；

步驟s223：接收所述ip地址返回的驗證信息，形成所述驗證結果。

所述預製證書可為預先存儲在驗證平臺中的信息，當一個伺服器構架完畢 之後，可能會與通信運營商進行籤約，形成籤約信息，籤約信息中就可能包括所述預製證書。通常所述預製證書中包括公鑰，在信息交互時利用公鑰進行加密，則需要由存儲在對應ip地址的設備中的私鑰進行解密，才能獲得正確的信息。在本實施例中，利用所述域名查詢所述預製證書，從預製證書可讀取所述公鑰，利用所述公鑰將向該ip地址發送驗證信息，並接收該ip地址返回的驗證信息，若該驗證信息表明該ip地址的設備正確解密並解碼了該驗證信息，則表示該域名和該ip地址的對應關係正確，不存在著域名造價的問題，從而不存在者sni欄位中域名的造價問題，可以直接根據該sni欄位進行計費處理。

方式二：

所述步驟s220可包括：

依據所述域名和所述ip地址，查詢黑名單和/或白名單，根據查詢結果形成所述驗證結果；其中，所述黑名單為包括不可信的域名和ip地址；所述白名單包括可信的域名和ip地址。

在本實施例中所述驗證平臺中可預先存儲了有域名和ip地址的對應關係，存儲有正確對應關係的為白名單，包括錯誤域名和ip地址對應關係的黑名單。在本實施例中所述驗證平臺可以通過查詢白名單和黑名單中的至少其中之一，初步確定出域名和ip地址的對應關係是否正確。

當然，作為方式二的進一步改進，所述步驟s220還包括：

當所述黑名單和白名單中都不包括所述域名和所述ip地址時，根據所述域名查詢預製證書，以獲取所述ip地址對應的密鑰信息；

依據所述密鑰信息，向所述ip地址發送驗證信息；

接收所述ip地址返回的驗證信息，形成所述驗證結果。

若當前域名和ip地址的對應關係在白名單和黑名單中都未存儲，此時，就還不能確定該域名和ip地址的對應關係是否正確，在本實施例中同樣可以採用前述步驟s221至步驟s223進行驗證，以通過信息交互的方式確定出所述域名和所述ip地址之間的對應關係是否正確。

為了方便後續的域名和ip地址之間對應關係的驗證，所述方法還包括：

根據所述驗證結果，更新所述黑名單或白名單。

在本實施例中，還將根據步驟s223的處理，更新白名單或黑名單。若步驟s223的驗證結果表明，該ip地址對應的設備，沒有能夠正確解密該驗證信息，則將該域名和該ip添加到黑名單中，這樣後續，在進行驗證時，直接通過查詢黑名單就能夠確定出是否存在著sni欄位造假的問題。若驗證結果表明，對應的ip地址的設備正確解密所述驗證信息，則可將該域名和ip地址添加到白名單中，方便後續驗證。

在本實施例中所述驗證平臺可以與多臺網關進行上述域名和ip地址之間對應關係的驗證，這樣就可以多臺設備進行黑名單和白名單的共享，以提高驗證效率。

實施例三：

如圖4所示，本實施例提供一種網關，包括：

獲取單元110，用於獲取伺服器的ip地址；

識別單元120，用於識別伺服器名字指示sni欄位，獲取所述伺服器的域名；

第一驗證單元130，用於基於所述域名和所述ip地址進行可信度驗證；

確定單元140，用於基於所述可信度驗證的結果，確定業務數據包的內容計費策略。

在本實施例中所述獲取單元110、識別單元120、第一驗證單元130及確定單元140都可對應於網關中的處理器或處理電路。所述處理器可包括中央處理器、數位訊號處理器、應用處理器、微處理器或可編程陣列等。所述處理電路可包括專用集成電路。

所述處理器或處理電路可以通過可執行代碼的執行，實現上述功能，以識別出所述sni欄位中攜帶的域名與ip地址的對應關係是否正確，從而防止sni欄位中攜帶偽造的域名或不真實的域名導致的計費精確度低的現象。在本實施例中所述網關可以為路由器等設備。所述處理器可為路由器中的通信處理器等。

所述第一驗證單元130，具體用於判斷所述域名和所述ip地址是否位於可 信列表和不可信列表中；

所述確定單元140，具體用於若所述域名和ip地址位於所述可信列表中，則直接根據所述sni欄位確定計費策略；若所述域名和ip地址位於所述不可信列表中，則結合所述sni信息校正計費策略。

在本實施例中所述第一驗證單元130可包括存儲介質，所述存儲介質可存儲有可信列表和所述不可信列表。所述第一驗證單元130可以將獲取單元110獲取的ip地址和識別單元120識別的域名，為查詢所以，查詢所述可信列表和不可信列表中的至少其中之一，然後確定出所述域名和ip地址的對應關係是否正確。若正確，則可能在所述可信列表中查詢到該域名和該ip地址的對應關係，若不正確，則可能在不可信列表中查詢到該ip和該域名。總之，在本實施例中所述第一驗證單元130在tls建鏈階段，識別出所述sni欄位中攜帶的域名是否正確，是否存在偽造和篡改等現象，從而方便確定單元140確定出能夠提升計費精準度的信息。

在本實施例中，所述第一驗證單元130具體可用於在與該ip地址對應的伺服器重新發起tls連結建立時，查詢該域名對應的預製證書，通過查詢該預製證書，確定出向該域名對應的所述ip地址發送驗證信息的密鑰，該密鑰通常為公鑰；若所述域名和所述ip地址都並非偽造的，則所述ip地址應該能夠接收並解碼所述驗證信息，再接收到所述驗證信息之後，將會向網關反饋信息，這個時候所述網關就可以根據反饋信息來確定出所述域名和所述ip地址的對應關係是否正確，從而實現對所述域名和ip地址的驗證。

進一步地，所述第一驗證單元130，具體用於若所述域名和所述ip地址既然不位於所述可信列表，也不位於所述不可信列表中，則將所述域名和所述ip地址發送給驗證平臺，進行所述可信度驗證；接收所述驗證平臺進行所述可信度驗證的驗證結果。

在本實施例中所述網關中可存儲有所述可信列表和不可信列表，從而方便第一驗證單元130快速通過查詢所述可信列表或不可信列表，確定域名和ip地址之間的對應關係是否正確，以完成驗證。本實施例所述的可信列表和不可信 列表的定義可以參見前述實施例，在此就不重複了。

所述網關還包括：第一更新單元，用於根據所述驗證結果，更新所述可信列表或所述不可信列表。在本實施例中所述網關還包括第一更新單元，這裡的更新單元用於根據從驗證平臺或網關自行通過驗證的信息，更新所述可信列表或不可信列表，以方便下一次的驗證。

所述網關還包括：

通信單元，用於若所述域名和所述ip地址既然不位於所述可信列表，也不位於所述不可信列表中，轉發業務數據包並按照所述sni欄位進行首次計費。

在本實施例中所述網關包括通信單元，該通信單元可以向伺服器發送業務數據包，在本實施例中為了避免首次驗證過程中，因驗證流程所需的時間較長，導致的業務數據包的轉發延時，在本實施例中會在查詢到該域名和ip地址的對應關係既不在所述可信列表，也不再所述不可信列表中，則先轉發所述業務數據包，並直接根據sni欄位首次計費，在後續完成了校驗，更新了所述可信列表或非可信列表之後，則會基於驗證結果進行後續的計費策略的校正，以提升後續計費的精準度。本實施例中所述通信單元可對應於網關的通信接口，這裡的通信接口可為有線接口或無線接口。所述有線接口可為光纖接口或電纜接口。所述無線接口可為各種天線等。

實施例四：

如圖5所示，本實施例提供一種驗證平臺，包括：

接收單元210，用於接收網關發送的域名和ip地址；其中，所述域名為基於數據包中的伺服器名字指示sni欄位確定的；

第二驗證單元220，用於對所述域名和所述ip地址進行驗證，並形成驗證結果；

發送單元230，用於將所述驗證結果發送給所述網關；其中，所述驗證結果，能夠用於為所述網關進行內容計費提供依據。

本實施例所述接收單元210可為一臺或多臺能夠進行域名和ip地址之前對應關係驗證是否正確的伺服器。

所述接收單元210可對應於接收接口，能夠從網關接收到域名和ip地址。所述域名可以為tls報文中提取的sni欄位中獲取的。所述tls報文可為tls建鏈中傳輸的數據。

第二驗證單元220將會進行域名和ip地址是否有正確的對應關係的驗證，形成上述驗證結果。本實施例所述的第二驗證單元220可對應於驗證平臺中的處理器或處理電路。所述處理器或處理電路的結構。

所述發送單元230可對應於發送接口，這裡的發送接口同樣可為網關進行數據交互的接口，可以將所述驗證結果發送給網關，方便網關進行內容計費策略的確定和校正。

總之，本實施例提供了一種驗證平臺，能夠協助網關提升計費精準度。

此外，所述第二驗證單元220，具體用於依據所述域名和所述ip地址，查詢黑名單和/或白名單，根據查詢結果形成所述驗證結果；其中，所述黑名單為包括不可信的域名和ip地址；所述白名單包括可信的域名和ip地址。

在本實施例中所述驗證平臺中存儲有黑名單和白名單。在本實施例中所述的黑名單對應於前述實施例中的不可信列表；所述白名單對應於前述實施例中的可信列表。

在本實施例中所述驗證平臺可以通過黑名單和白名單的查詢，確定出從網關接收的域名和ip地址之間的對應關係是否正確，從而方便網關根據驗證平臺的驗證結果，確定出sni欄位的內容是否存在偽造和篡改的現象，提升計費的精準度。

此外，所述第二驗證單元220，還用於當所述黑名單和白名單中都不包括所述域名和所述ip地址時，根據所述域名查詢預製證書，以獲取所述ip地址對應的密鑰信息；依據所述密鑰信息，向所述ip地址發送驗證信息；接收所述ip地址返回的驗證信息，形成所述驗證結果。

在本實施例中所述第二驗證單元220若確定出黑名單和白名單都不包括所述域名和ip地址時，通過與該ip地址的設備進行信息交互，來進行所述域名和ip地址之間對應關係是否正確的驗證的結構。當然，所述第二驗證單元220 也可以不查詢黑名單和白名單的情況下，直接通過與該ip地址對應的設備的信息交互，來進行域名和該ip地址之間的驗證。

作為本實施例的進一步改進，第二更新單元，用於根據所述驗證結果，更新所述黑名單或白名單。

本實施例所述第二更新單元，可對應於處理器或處理電路，能夠用於根據上述驗證結果，更新所述黑名單或白名單，方便後續的驗證，以提升後續的驗證效率。

以下結合上述任意實施例提供兩個具體示例：

示例一：

如圖6所示，本示例提供一種通信系統，包括：

用戶設備(userequipment，ue)、網關(ggsn/p-gw)、伺服器(sp)及驗證平臺。

在本實施例所述ue與伺服器之間的數據包，需要通過網關進行轉發。在進行數據轉發之前，網關需要建立ue與伺服器之間的tcp連接及進行tls建鏈處理。

在本實施例中所述驗證平臺分別能夠與網關和伺服器進行連接。

在本實施例中所述網關中存儲有可信列表和不可信列表，當進行tls建鏈時，在建鏈的初始階段，網關會從tls報文中提取sni欄位，根據該sni欄位，得到後續進行業務數據收發的域名。在進行tls建鏈之前，網關將作為中間節點，建立ue與伺服器之間將進行tcp連接，在建立tcp連接的過程中，會確定出伺服器的ip地址。在本實施例中，所述伺服器可為內容服務提供者(serviceprovider，sp)故也可以如圖6所示，簡稱為sp。所述網關可包括如圖6中所示的通用分組無線業務網關支持節點(gatewaygprssupportnode)或分組數據網網關。

當網關通過自身存儲的可信列表和不可信列表，無法確定該域名與ip地址之間的對應關係是否正確時，將該域名和ip地址發送給驗證平臺進行統一驗證。

驗證平臺接收到給域名和ip地址之後，查詢內部的黑名單和白名單，根據 查詢結果確定域名和ip地址是否正確。若無法通過查詢確定，則可以通過向該ip地址對應的設備發送利用公鑰加密的驗證信息，來進行驗證。若驗證成功，則認為該域名和ip地址的對應關係正確，否則認為驗證不正確。

在具體的實現過程中，所述驗證平臺將會與網絡中大量的網關進行連接，由於大量的信息處理，在該驗證平臺中存儲有大量的黑名單和白名單，可以簡便的通過查詢進行驗證。

示例二：

如圖7所示，本示例提供一種信息處理方法：

步驟1：網關通過透傳建鏈消息，實現ue與伺服器sp之間的tcp三次握手，網關透傳建鏈消息。這裡的建鏈消息為建立tcp連接的信息，此時，網關獲得了伺服器的ip地址。

步驟2：進行tls建鏈處理。網關從ue接收到第一消息，這裡的第一消息可為ue傳輸的打招呼的信息，例如，「clienthello」。網關在ue和sp之間透傳消息；解析sni欄位，如果sni欄位中的域名和sp的ip在可信列表中有對應關係，則驗證通過，將sid設置為後向計費；如果在不可信列表中，sid設為正常前向計費。如果sp的ip和域名對應關係在上述列表中都不存在，則記錄握手信息，傳遞給驗證平臺。這裡的後向計費和正常前向計費都為前述內容計費策略的一種。此處的後向計費為由運營商的伺服器進行計費的計費策略；前向計費可為由客戶端進行計費的計費策略。這樣的話，後向計費能夠監督偽造sin欄位的數據費用，提高計費的精確度。

網關還會將無對應關係的域名和ip地址發送給驗證平臺。

網關透傳消息，本次建鏈成功。這裡透傳的消息為第二消息。這裡的第二消息可包括伺服器的招呼消息，整數、伺服器密鑰交互等各種消息。

步驟3：驗證平臺模擬ue發起tcp建鏈和tls握手，握手使用的整數為sni欄位中域名對應的預製整數，向sp發送第二消息；如果模擬握手過程中出現問題，則計入該ip和域名的對應關係入黑名單，如果握手通過，則記錄該ip地址和域名的對應關係如白名單；並通知網關。

在本申請所提供的幾個實施例中，應該理解到，所揭露的設備和方法，可以通過其它的方式實現。以上所描述的設備實施例僅僅是示意性的，例如，所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現時可以有另外的劃分方式，如：多個單元或組件可以結合，或可以集成到另一個系統，或一些特徵可以忽略，或不執行。另外，所顯示或討論的各組成部分相互之間的耦合、或直接耦合、或通信連接可以是通過一些接口，設備或單元的間接耦合或通信連接，可以是電性的、機械的或其它形式的。

上述作為分離部件說明的單元可以是、或也可以不是物理上分開的，作為單元顯示的部件可以是、或也可以不是物理單元，即可以位於一個地方，也可以分布到多個網絡單元上；可以根據實際的需要選擇其中的部分或全部單元來實現本實施例方案的目的。

另外，在本發明各實施例中的各功能單元可以全部集成在一個處理模塊中，也可以是各單元分別單獨作為一個單元，也可以兩個或兩個以上單元集成在一個單元中；上述集成的單元既可以採用硬體的形式實現，也可以採用硬體加軟體功能單元的形式實現。

本領域普通技術人員可以理解：實現上述方法實施例的全部或部分步驟可以通過程序指令相關的硬體來完成，前述的程序可以存儲於一計算機可讀取存儲介質中，該程序在執行時，執行包括上述方法實施例的步驟；而前述的存儲介質包括：移動存儲設備、只讀存儲器(rom，read-onlymemory)、隨機存取存儲器(ram，randomaccessmemory)、磁碟或者光碟等各種可以存儲程序代碼的介質。

以上所述，僅為本發明的具體實施方式，但本發明的保護範圍並不局限於此，任何熟悉本技術領域的技術人員在本發明揭露的技術範圍內，可輕易想到變化或替換，都應涵蓋在本發明的保護範圍之內。因此，本發明的保護範圍應以所述權利要求的保護範圍為準。