本發(fā)明涉及通信領(lǐng)域，尤其涉及一種信息處理方法、網(wǎng)關(guān)及驗證平臺。

背景技術(shù)：

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

技術(shù)實現(xiàn)要素：

有鑒于此，本發(fā)明實施例期望提供一種信息處理方法、網(wǎng)關(guān)及驗證平臺，至少部分解決sni字段導(dǎo)致的計費的精準(zhǔn)性差的問題。

為達到上述目的，本發(fā)明的技術(shù)方案是這樣實現(xiàn)的：

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

獲取服務(wù)器的ip地址；

識別服務(wù)器名字指示sni字段，獲取所述服務(wù)器的域名；

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

基于所述可信度驗證的結(jié)果，確定業(yè)務(wù)數(shù)據(jù)包的內(nèi)容計費策略。

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

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

若所述域名和ip地址位于所述可信列表中，則直接根據(jù)所述sni字段確定計費策略；

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

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

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

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

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

根據(jù)所述驗證結(jié)果，更新所述可信列表或所述不可信列表。

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

若所述域名和所述ip地址既然不位于所述可信列表，也不位于所述不可信列表中，轉(zhuǎn)發(fā)業(yè)務(wù)數(shù)據(jù)包并按照所述sni字段進行首次計費。

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

接收網(wǎng)關(guān)發(fā)送的域名和ip地址；其中，所述域名為基于數(shù)據(jù)包中的服務(wù)器名字指示sni字段確定的；

對所述域名和所述ip地址進行驗證，并形成驗證結(jié)果；

將所述驗證結(jié)果發(fā)送給所述網(wǎng)關(guān)；其中，所述驗證結(jié)果，能夠用于為所述網(wǎng)關(guān)進行內(nèi)容計費提供依據(jù)。

基于上述方案，所述對所述域名和所述ip地址進行驗證，并形成驗證結(jié)果，包括：

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

基于上述方案，所述對所述域名和所述ip地址進行驗證，并形成驗證結(jié)果，包括：

當(dāng)所述黑名單和白名單中都不包括所述域名和所述ip地址時，根據(jù)所述域名查詢預(yù)制證書，以獲取所述ip地址對應(yīng)的密鑰信息；

依據(jù)所述密鑰信息，向所述ip地址發(fā)送驗證信息；

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

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

根據(jù)所述驗證結(jié)果，更新所述黑名單或白名單。

本發(fā)明實施例第三方面提供一種網(wǎng)關(guān)，包括：

獲取單元，用于獲取服務(wù)器的ip地址；

識別單元，用于識別服務(wù)器名字指示sni字段，獲取所述服務(wù)器的域名；

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

確定單元，用于基于所述可信度驗證的結(jié)果，確定業(yè)務(wù)數(shù)據(jù)包的內(nèi)容計費策略。

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

所述確定單元，具體用于若所述域名和ip地址位于所述可信列表中，則直接根據(jù)所述sni字段確定計費策略；若所述域名和ip地址位于所述不可信列表中，則結(jié)合所述sni信息校正計費策略。

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

基于上述方案，所述網(wǎng)關(guān)還包括：

第一更新單元，用于根據(jù)所述驗證結(jié)果，更新所述可信列表或所述不可信列表。

基于上述方案，所述網(wǎng)關(guān)還包括：

通信單元，用于若所述域名和所述ip地址既然不位于所述可信列表，也不位于所述不可信列表中，轉(zhuǎn)發(fā)業(yè)務(wù)數(shù)據(jù)包并按照所述sni字段進行首次計費。

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

接收單元，用于接收網(wǎng)關(guān)發(fā)送的域名和ip地址；其中，所述域名為基于數(shù) 據(jù)包中的服務(wù)器名字指示sni字段確定的；

第二驗證單元，用于對所述域名和所述ip地址進行驗證，并形成驗證結(jié)果；

發(fā)送單元，用于將所述驗證結(jié)果發(fā)送給所述網(wǎng)關(guān)；其中，所述驗證結(jié)果，能夠用于為所述網(wǎng)關(guān)進行內(nèi)容計費提供依據(jù)。

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

基于上述方案，所述第二驗證單元，還用于當(dāng)所述黑名單和白名單中都不包括所述域名和所述ip地址時，根據(jù)所述域名查詢預(yù)制證書，以獲取所述ip地址對應(yīng)的密鑰信息；依據(jù)所述密鑰信息，向所述ip地址發(fā)送驗證信息；接收所述ip地址返回的驗證信息，形成所述驗證結(jié)果。

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

第二更新單元，用于根據(jù)所述驗證結(jié)果，更新所述黑名單或白名單。

本發(fā)明實施例提供一種信息處理方法、網(wǎng)關(guān)及驗證平臺，在tls連接建立的過程中，會對域名和ip地址之間的對應(yīng)關(guān)系進行驗證，以驗證sni字段中攜帶的域名是真實的，以減少sin字段中攜帶者偽造的域名或與ip地址不對應(yīng)的域名導(dǎo)致的基于該sni字段進行收費導(dǎo)致的計費精確度低的現(xiàn)象。

附圖說明

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

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

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

圖4為本發(fā)明實施例提供的一種網(wǎng)關(guān)的結(jié)構(gòu)示意圖；

圖5為本發(fā)明實施例提供的一種驗證平臺的結(jié)構(gòu)示意圖；

圖6為本發(fā)明實施例提供的一種信息系統(tǒng)結(jié)構(gòu)示意圖；

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

具體實施方式

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

實施例一：

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

步驟s110：獲取服務(wù)器的ip地址；

步驟s120：識別服務(wù)器名字指示sni字段，獲取所述服務(wù)器的域名；

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

步驟s140：基于所述可信度驗證的結(jié)果，確定業(yè)務(wù)數(shù)據(jù)包的內(nèi)容計費策略。

本實施例所述的信息處理方法，為能夠應(yīng)用于網(wǎng)關(guān)中的信息處理方法，本實施例中所述的網(wǎng)關(guān)可包括路由器。

在步驟s110中獲取服務(wù)器的ip地址，可包括網(wǎng)關(guān)與服務(wù)器建立傳輸控制協(xié)議(transportcontrollerprotocol，tcp)連接，在建立tcp連接時就可以將獲得服務(wù)器的ip地址。

在步驟s120中識別所述sni字段，通常sni字段是明文信息，故網(wǎng)關(guān)直接可以通過解碼就能夠獲得sni字段中的域名。通常在進行計費時，根據(jù)該域名來進行計費。

在步驟s130中將對該域名和ip地址進行可信度驗證，避免域名造假導(dǎo)致的計費結(jié)果不準(zhǔn)確的問題。網(wǎng)關(guān)在進行數(shù)據(jù)轉(zhuǎn)發(fā)時，是根據(jù)數(shù)據(jù)包中的目的ip地址進行數(shù)據(jù)包的轉(zhuǎn)發(fā)的，而計費則時根據(jù)sni字段中的域名來處理的。若出現(xiàn)sni字段造假，即sni中的域名并非目的ip地址的域名，就有可能將收費的數(shù)據(jù)包，視為免費的數(shù)據(jù)包給轉(zhuǎn)發(fā)了，從而導(dǎo)致計費結(jié)果的不準(zhǔn)確。在本實施例中為了防止這種現(xiàn)象的產(chǎn)生，在本實施例中網(wǎng)關(guān)增加了進行可信度驗證的步驟。

在步驟s130中，將根據(jù)可信度驗證的結(jié)果進行內(nèi)容計費處理。具體可包括，若sni字段表明是免費的，且驗證結(jié)果表示為可信，則直接對該數(shù)據(jù)包進行免 費。若sni字段表示是免費的，而驗證結(jié)果表明是不可信的，也可對該數(shù)據(jù)包進行收費處理。顯然這樣可以提高收費的準(zhǔn)確度。

作為本實施例的進一步改進，在所述網(wǎng)關(guān)中存儲有可信列表和非可信列表。通?？尚帕斜碇邪ǖ挠蛎蚷p地址的對應(yīng)關(guān)系，表示域名和ip地址之間的對應(yīng)關(guān)系是正確的，不會存在ip地址或域名的偽造或錯誤。非可信列表中的域名和ip地址之間的對應(yīng)關(guān)系是非可信的，表示域名或ip地址的至少其中之一有錯誤。故在本實施例中，所述步驟s130可包括：判斷所述域名和所述ip地址是否位于可信列表和不可信列表中；若所述域名和ip地址位于所述可信列表中，則直接根據(jù)所述sni字段確定計費策略；若所述域名和ip地址位于所述不可信列表中，則結(jié)合所述sni信息校正計費策略。顯然，這樣可以簡便的避免sni字段造假導(dǎo)致的計費結(jié)果不精確的問題。在本實施例中若步驟s110中提取的域名和步驟s120中獲取的ip地址對應(yīng)位于所述可信列表中，表示所述sni字段可信，可以直接根據(jù)所述sni字段確定出內(nèi)容計費策略。若域名和ip地址的這種對應(yīng)關(guān)系位于非可信列表中，則需要校正內(nèi)容計費策略。通常情況下，非法用戶為了避免計費，會將收費業(yè)務(wù)數(shù)據(jù)，通過位置sni字段的內(nèi)容，改變成免費數(shù)據(jù)，則此時需要將免費策略校正為計費策略。還有一種可能是sni字段中原本要存儲的收費較高的域名修改成收費較低的域名，這個時候，需要將計費策略中的計費單價恢復(fù)到較高的計費。

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

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

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

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

在具體的實現(xiàn)過程中，所述網(wǎng)關(guān)也可以自行進行驗證。例如，所述網(wǎng)關(guān)與該ip地址對應(yīng)的服務(wù)器重新發(fā)起tls鏈接建立，在所述網(wǎng)關(guān)中存儲有該域名 對應(yīng)的預(yù)制證書。所述網(wǎng)關(guān)可以通過查詢該預(yù)制證書，確定出向該域名對應(yīng)的所述ip地址發(fā)送驗證信息的密鑰，該密鑰通常為公鑰。若所述域名和所述ip地址都并非偽造的，則所述ip地址應(yīng)該能夠接收并解碼所述驗證信息，再接收到所述驗證信息之后，將會向網(wǎng)關(guān)反饋信息，這個時候所述網(wǎng)關(guān)就可以根據(jù)反饋信息來確定出所述域名和所述ip地址的對應(yīng)關(guān)系是否正確，進而在步驟s140中確定出是否可以根據(jù)該sni字段直接進行計費。例如，所述反饋信息表明接收驗證信息的一方，正確解碼了驗證信息，則認為該域名和ip地址之間的對應(yīng)關(guān)系是正確的，是不存在偽造的條件的。

當(dāng)然，具體實現(xiàn)時，可以由驗證平臺來實現(xiàn)上述驗證處理，而網(wǎng)關(guān)僅直接接收驗證結(jié)果就好。

延續(xù)上述實施例，所述方法還包括：

根據(jù)所述驗證結(jié)果，更新所述可信列表或所述不可信列表。

若驗證結(jié)果表明，所述域名和所述ip地址不可信，則將該域名和該ip地址添加到所述不可信列表中，則下次在出現(xiàn)該域名和ip地址時，就可以直接認為出現(xiàn)造假現(xiàn)象，應(yīng)該進行內(nèi)容收費。若所述域名和ip地址可信，則將該域名和該ip地址添加到所述可信列表中，方便后續(xù)數(shù)據(jù)包的快速轉(zhuǎn)發(fā)及計費處理。

在本實施例中為了，避免可信sni字段，因未記載網(wǎng)關(guān)中的可信列表中導(dǎo)致的延時問題，在本實施例中所述方法還包括：

若所述域名和所述ip地址既然不位于所述可信列表，也不位于所述不可信列表中，轉(zhuǎn)發(fā)業(yè)務(wù)數(shù)據(jù)包并按照所述sni字段進行首次計費。即網(wǎng)關(guān)一邊對所述域名和ip地址發(fā)送給網(wǎng)關(guān)進行驗證，或自行根據(jù)預(yù)制證書繼續(xù)驗證，一邊轉(zhuǎn)發(fā)數(shù)據(jù)包，避免數(shù)據(jù)包的延時，若下次再出現(xiàn)類似的數(shù)據(jù)包，則可以根據(jù)當(dāng)前次驗證的結(jié)果進行數(shù)據(jù)中sni字段的再次驗證，一方面提升了收費的精準(zhǔn)性，另一方面減少了因驗證導(dǎo)致的時延大的問題。

在具體的實現(xiàn)過程中，若驗證出sni字段攜帶的域名與服務(wù)器的ip地址的對應(yīng)關(guān)系不正確，存在偽造和篡改的嫌疑，向指定設(shè)備發(fā)送提示信息，例如，向發(fā)送業(yè)務(wù)數(shù)據(jù)包的兩端發(fā)送提示信息，和通信運營商的監(jiān)控設(shè)備發(fā)送提示信 息，以通過提示信息，告知當(dāng)前sni字段存在域名偽造和篡改的嫌疑，方便后續(xù)的監(jiān)控，從源頭上減少sni字段偽造和篡改的嫌疑。

實施例二：

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

步驟s210：接收網(wǎng)關(guān)發(fā)送的域名和ip地址；其中，所述域名為基于數(shù)據(jù)包中的服務(wù)器名字指示sni字段確定的；

步驟s220：對所述域名和所述ip地址進行驗證，并形成驗證結(jié)果；

步驟s230：將所述驗證結(jié)果發(fā)送給所述網(wǎng)關(guān)；其中，所述驗證結(jié)果，能夠用于為所述網(wǎng)關(guān)進行內(nèi)容計費提供依據(jù)。

本實施例所述的方法，可為應(yīng)用于驗證平臺中的方法，在本實施例中所述驗證平臺可又一臺或多臺服務(wù)器構(gòu)成，也可以由一臺或多臺具有驗證功能的虛擬機構(gòu)成。

在本實施例中步驟s210中將從路由器等網(wǎng)關(guān)接收域名和ip地址，此時的域名為可為從sni字段中提取的。

在步驟s220中將進行域名和ip地址的驗證，并形成驗證結(jié)果。

在步驟s230中將驗證結(jié)果發(fā)送給網(wǎng)關(guān)，方便網(wǎng)關(guān)對數(shù)據(jù)包的轉(zhuǎn)發(fā)進行收費等處理。

在本實施例中所述驗證平臺將協(xié)助網(wǎng)關(guān)進行域名和ip地址是否可信的驗證，以提升網(wǎng)關(guān)進行計費的精準(zhǔn)度。

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

方式一：

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

步驟s221：根據(jù)所述域名查詢預(yù)制證書，以獲取所述ip地址對應(yīng)的密鑰信息；

步驟s222：依據(jù)所述密鑰信息，向所述ip地址發(fā)送驗證信息；

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

所述預(yù)制證書可為預(yù)先存儲在驗證平臺中的信息，當(dāng)一個服務(wù)器構(gòu)架完畢 之后，可能會與通信運營商進行簽約，形成簽約信息，簽約信息中就可能包括所述預(yù)制證書。通常所述預(yù)制證書中包括公鑰，在信息交互時利用公鑰進行加密，則需要由存儲在對應(yīng)ip地址的設(shè)備中的私鑰進行解密，才能獲得正確的信息。在本實施例中，利用所述域名查詢所述預(yù)制證書，從預(yù)制證書可讀取所述公鑰，利用所述公鑰將向該ip地址發(fā)送驗證信息，并接收該ip地址返回的驗證信息，若該驗證信息表明該ip地址的設(shè)備正確解密并解碼了該驗證信息，則表示該域名和該ip地址的對應(yīng)關(guān)系正確，不存在著域名造價的問題，從而不存在者sni字段中域名的造價問題，可以直接根據(jù)該sni字段進行計費處理。

方式二：

所述步驟s220可包括：

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

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

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

當(dāng)所述黑名單和白名單中都不包括所述域名和所述ip地址時，根據(jù)所述域名查詢預(yù)制證書，以獲取所述ip地址對應(yīng)的密鑰信息；

依據(jù)所述密鑰信息，向所述ip地址發(fā)送驗證信息；

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

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

為了方便后續(xù)的域名和ip地址之間對應(yīng)關(guān)系的驗證，所述方法還包括：

根據(jù)所述驗證結(jié)果，更新所述黑名單或白名單。

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

在本實施例中所述驗證平臺可以與多臺網(wǎng)關(guān)進行上述域名和ip地址之間對應(yīng)關(guān)系的驗證，這樣就可以多臺設(shè)備進行黑名單和白名單的共享，以提高驗證效率。

實施例三：

如圖4所示，本實施例提供一種網(wǎng)關(guān)，包括：

獲取單元110，用于獲取服務(wù)器的ip地址；

識別單元120，用于識別服務(wù)器名字指示sni字段，獲取所述服務(wù)器的域名；

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

確定單元140，用于基于所述可信度驗證的結(jié)果，確定業(yè)務(wù)數(shù)據(jù)包的內(nèi)容計費策略。

在本實施例中所述獲取單元110、識別單元120、第一驗證單元130及確定單元140都可對應(yīng)于網(wǎng)關(guān)中的處理器或處理電路。所述處理器可包括中央處理器、數(shù)字信號處理器、應(yīng)用處理器、微處理器或可編程陣列等。所述處理電路可包括專用集成電路。

所述處理器或處理電路可以通過可執(zhí)行代碼的執(zhí)行，實現(xiàn)上述功能，以識別出所述sni字段中攜帶的域名與ip地址的對應(yīng)關(guān)系是否正確，從而防止sni字段中攜帶偽造的域名或不真實的域名導(dǎo)致的計費精確度低的現(xiàn)象。在本實施例中所述網(wǎng)關(guān)可以為路由器等設(shè)備。所述處理器可為路由器中的通信處理器等。

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

所述確定單元140，具體用于若所述域名和ip地址位于所述可信列表中，則直接根據(jù)所述sni字段確定計費策略；若所述域名和ip地址位于所述不可信列表中，則結(jié)合所述sni信息校正計費策略。

在本實施例中所述第一驗證單元130可包括存儲介質(zhì)，所述存儲介質(zhì)可存儲有可信列表和所述不可信列表。所述第一驗證單元130可以將獲取單元110獲取的ip地址和識別單元120識別的域名，為查詢所以，查詢所述可信列表和不可信列表中的至少其中之一，然后確定出所述域名和ip地址的對應(yīng)關(guān)系是否正確。若正確，則可能在所述可信列表中查詢到該域名和該ip地址的對應(yīng)關(guān)系，若不正確，則可能在不可信列表中查詢到該ip和該域名?？傊诒緦嵤├兴龅谝或炞C單元130在tls建鏈階段，識別出所述sni字段中攜帶的域名是否正確，是否存在偽造和篡改等現(xiàn)象，從而方便確定單元140確定出能夠提升計費精準(zhǔn)度的信息。

在本實施例中，所述第一驗證單元130具體可用于在與該ip地址對應(yīng)的服務(wù)器重新發(fā)起tls鏈接建立時，查詢該域名對應(yīng)的預(yù)制證書，通過查詢該預(yù)制證書，確定出向該域名對應(yīng)的所述ip地址發(fā)送驗證信息的密鑰，該密鑰通常為公鑰；若所述域名和所述ip地址都并非偽造的，則所述ip地址應(yīng)該能夠接收并解碼所述驗證信息，再接收到所述驗證信息之后，將會向網(wǎng)關(guān)反饋信息，這個時候所述網(wǎng)關(guān)就可以根據(jù)反饋信息來確定出所述域名和所述ip地址的對應(yīng)關(guān)系是否正確，從而實現(xiàn)對所述域名和ip地址的驗證。

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

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

所述網(wǎng)關(guān)還包括：第一更新單元，用于根據(jù)所述驗證結(jié)果，更新所述可信列表或所述不可信列表。在本實施例中所述網(wǎng)關(guān)還包括第一更新單元，這里的更新單元用于根據(jù)從驗證平臺或網(wǎng)關(guān)自行通過驗證的信息，更新所述可信列表或不可信列表，以方便下一次的驗證。

所述網(wǎng)關(guān)還包括：

通信單元，用于若所述域名和所述ip地址既然不位于所述可信列表，也不位于所述不可信列表中，轉(zhuǎn)發(fā)業(yè)務(wù)數(shù)據(jù)包并按照所述sni字段進行首次計費。

在本實施例中所述網(wǎng)關(guān)包括通信單元，該通信單元可以向服務(wù)器發(fā)送業(yè)務(wù)數(shù)據(jù)包，在本實施例中為了避免首次驗證過程中，因驗證流程所需的時間較長，導(dǎo)致的業(yè)務(wù)數(shù)據(jù)包的轉(zhuǎn)發(fā)延時，在本實施例中會在查詢到該域名和ip地址的對應(yīng)關(guān)系既不在所述可信列表，也不再所述不可信列表中，則先轉(zhuǎn)發(fā)所述業(yè)務(wù)數(shù)據(jù)包，并直接根據(jù)sni字段首次計費，在后續(xù)完成了校驗，更新了所述可信列表或非可信列表之后，則會基于驗證結(jié)果進行后續(xù)的計費策略的校正，以提升后續(xù)計費的精準(zhǔn)度。本實施例中所述通信單元可對應(yīng)于網(wǎng)關(guān)的通信接口，這里的通信接口可為有線接口或無線接口。所述有線接口可為光纖接口或電纜接口。所述無線接口可為各種天線等。

實施例四：

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

接收單元210，用于接收網(wǎng)關(guān)發(fā)送的域名和ip地址；其中，所述域名為基于數(shù)據(jù)包中的服務(wù)器名字指示sni字段確定的；

第二驗證單元220，用于對所述域名和所述ip地址進行驗證，并形成驗證結(jié)果；

發(fā)送單元230，用于將所述驗證結(jié)果發(fā)送給所述網(wǎng)關(guān)；其中，所述驗證結(jié)果，能夠用于為所述網(wǎng)關(guān)進行內(nèi)容計費提供依據(jù)。

本實施例所述接收單元210可為一臺或多臺能夠進行域名和ip地址之前對應(yīng)關(guān)系驗證是否正確的服務(wù)器。

所述接收單元210可對應(yīng)于接收接口，能夠從網(wǎng)關(guān)接收到域名和ip地址。所述域名可以為tls報文中提取的sni字段中獲取的。所述tls報文可為tls建鏈中傳輸?shù)臄?shù)據(jù)。

第二驗證單元220將會進行域名和ip地址是否有正確的對應(yīng)關(guān)系的驗證，形成上述驗證結(jié)果。本實施例所述的第二驗證單元220可對應(yīng)于驗證平臺中的處理器或處理電路。所述處理器或處理電路的結(jié)構(gòu)。

所述發(fā)送單元230可對應(yīng)于發(fā)送接口，這里的發(fā)送接口同樣可為網(wǎng)關(guān)進行數(shù)據(jù)交互的接口，可以將所述驗證結(jié)果發(fā)送給網(wǎng)關(guān)，方便網(wǎng)關(guān)進行內(nèi)容計費策略的確定和校正。

總之，本實施例提供了一種驗證平臺，能夠協(xié)助網(wǎng)關(guān)提升計費精準(zhǔn)度。

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

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

在本實施例中所述驗證平臺可以通過黑名單和白名單的查詢，確定出從網(wǎng)關(guān)接收的域名和ip地址之間的對應(yīng)關(guān)系是否正確，從而方便網(wǎng)關(guān)根據(jù)驗證平臺的驗證結(jié)果，確定出sni字段的內(nèi)容是否存在偽造和篡改的現(xiàn)象，提升計費的精準(zhǔn)度。

此外，所述第二驗證單元220，還用于當(dāng)所述黑名單和白名單中都不包括所述域名和所述ip地址時，根據(jù)所述域名查詢預(yù)制證書，以獲取所述ip地址對應(yīng)的密鑰信息；依據(jù)所述密鑰信息，向所述ip地址發(fā)送驗證信息；接收所述ip地址返回的驗證信息，形成所述驗證結(jié)果。

在本實施例中所述第二驗證單元220若確定出黑名單和白名單都不包括所述域名和ip地址時，通過與該ip地址的設(shè)備進行信息交互，來進行所述域名和ip地址之間對應(yīng)關(guān)系是否正確的驗證的結(jié)構(gòu)。當(dāng)然，所述第二驗證單元220 也可以不查詢黑名單和白名單的情況下，直接通過與該ip地址對應(yīng)的設(shè)備的信息交互，來進行域名和該ip地址之間的驗證。

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

本實施例所述第二更新單元，可對應(yīng)于處理器或處理電路，能夠用于根據(jù)上述驗證結(jié)果，更新所述黑名單或白名單，方便后續(xù)的驗證，以提升后續(xù)的驗證效率。

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

示例一：

如圖6所示，本示例提供一種通信系統(tǒng)，包括：

用戶設(shè)備(userequipment，ue)、網(wǎng)關(guān)(ggsn/p-gw)、服務(wù)器(sp)及驗證平臺。

在本實施例所述ue與服務(wù)器之間的數(shù)據(jù)包，需要通過網(wǎng)關(guān)進行轉(zhuǎn)發(fā)。在進行數(shù)據(jù)轉(zhuǎn)發(fā)之前，網(wǎng)關(guān)需要建立ue與服務(wù)器之間的tcp連接及進行tls建鏈處理。

在本實施例中所述驗證平臺分別能夠與網(wǎng)關(guān)和服務(wù)器進行連接。

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

當(dāng)網(wǎng)關(guān)通過自身存儲的可信列表和不可信列表，無法確定該域名與ip地址之間的對應(yīng)關(guān)系是否正確時，將該域名和ip地址發(fā)送給驗證平臺進行統(tǒng)一驗證。

驗證平臺接收到給域名和ip地址之后，查詢內(nèi)部的黑名單和白名單，根據(jù) 查詢結(jié)果確定域名和ip地址是否正確。若無法通過查詢確定，則可以通過向該ip地址對應(yīng)的設(shè)備發(fā)送利用公鑰加密的驗證信息，來進行驗證。若驗證成功，則認為該域名和ip地址的對應(yīng)關(guān)系正確，否則認為驗證不正確。

在具體的實現(xiàn)過程中，所述驗證平臺將會與網(wǎng)絡(luò)中大量的網(wǎng)關(guān)進行連接，由于大量的信息處理，在該驗證平臺中存儲有大量的黑名單和白名單，可以簡便的通過查詢進行驗證。

示例二：

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

步驟1：網(wǎng)關(guān)通過透傳建鏈消息，實現(xiàn)ue與服務(wù)器sp之間的tcp三次握手，網(wǎng)關(guān)透傳建鏈消息。這里的建鏈消息為建立tcp連接的信息，此時，網(wǎng)關(guān)獲得了服務(wù)器的ip地址。

步驟2：進行tls建鏈處理。網(wǎng)關(guān)從ue接收到第一消息，這里的第一消息可為ue傳輸?shù)拇蛘泻舻男畔?，例如，“clienthello”。網(wǎng)關(guān)在ue和sp之間透傳消息；解析sni字段，如果sni字段中的域名和sp的ip在可信列表中有對應(yīng)關(guān)系，則驗證通過，將sid設(shè)置為后向計費；如果在不可信列表中，sid設(shè)為正常前向計費。如果sp的ip和域名對應(yīng)關(guān)系在上述列表中都不存在，則記錄握手信息，傳遞給驗證平臺。這里的后向計費和正常前向計費都為前述內(nèi)容計費策略的一種。此處的后向計費為由運營商的服務(wù)器進行計費的計費策略；前向計費可為由客戶端進行計費的計費策略。這樣的話，后向計費能夠監(jiān)督偽造sin字段的數(shù)據(jù)費用，提高計費的精確度。

網(wǎng)關(guān)還會將無對應(yīng)關(guān)系的域名和ip地址發(fā)送給驗證平臺。

網(wǎng)關(guān)透傳消息，本次建鏈成功。這里透傳的消息為第二消息。這里的第二消息可包括服務(wù)器的招呼消息，整數(shù)、服務(wù)器密鑰交互等各種消息。

步驟3：驗證平臺模擬ue發(fā)起tcp建鏈和tls握手，握手使用的整數(shù)為sni字段中域名對應(yīng)的預(yù)制整數(shù)，向sp發(fā)送第二消息；如果模擬握手過程中出現(xiàn)問題，則計入該ip和域名的對應(yīng)關(guān)系入黑名單，如果握手通過，則記錄該ip地址和域名的對應(yīng)關(guān)系如白名單；并通知網(wǎng)關(guān)。

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

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

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

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

以上所述，僅為本發(fā)明的具體實施方式，但本發(fā)明的保護范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到變化或替換，都應(yīng)涵蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范圍應(yīng)以所述權(quán)利要求的保護范圍為準(zhǔn)。