Mina SSL Filter安全加密過濾器相關知識介紹

阿新 • • 發佈：2019-01-17

SslFilter過濾器是負責管理資料的加密和解密通過安全連線。每當你需要建立一個安全連線,或將現有的連線使它安全,你必須新增SslFilter過濾器鏈。

任何會話可以修改它的資訊過濾器鏈,它允許使用協議像startTLS開啟連線。

請注意,雖然這個名字包括SSL,SslFilter支援TLS。實際上,TLS已經支援取代SSL,但是由於歷史原因,SSL仍然廣泛使用。

1.1.1. 基本應用

如果你想讓你的應用程式支援SSL / TLS,只需新增的SslFilter鏈:

...

DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();

SslFilter sslFilter = new SslFilter(sslContext);

chain.addFirst("sslFilter", sslFilter);

...

你當然也需要一個SslContext例項:

SSLContext sslContext;

    try

    {

        // Initialize the SSLContext to work with our key managers.

        sslContext = SSLContext.getInstance( "TLS" );

        sslContext.init( ... ); // Provide the needed KeyManager[], TrustManager[] and SecureRandom instances

    }

    catch ( Exception e )

    {

        // Handle your exception

    }

這取決於你提供的KeyManager,TrustManager和SecureRandom例項。

確保注入SslFilter到過濾器鏈中的第一的位置!

稍後我們將看到如何建立一個SSLContext詳細為例。

1.1.2. 理論

如果你想要更深入地理解它是如何工作的,請閱讀下面的段落…

1.1.2.1. 基本的SSL

我們不打算解釋SSL是如何工作的，在此之外有非常好的書。我們將給一個快速介紹它是如何工作的,以及它是如何在Mina中實現的。

首先,你必須明白SSL / TLS協議中定義的RFCs:

在成為TLS之前，它最初是由Netscape命名為SSL(從1.0到3.0)。如今,SSL 2.0 * 3.0

和SSL * *已經棄用並且不應該被使用了。

1.1.3. SSL/TLS協議

因為它是一個協議,它需要客戶端和伺服器之間的一些會話。這是所有的SSL / TLS是什麼:關於描述該會話。

這足以知道任何保證交換排除是一個過程階段，叫做握手，它的角色是客戶端和伺服器之間達成協議將加密方法來使用。一個基本的SSL / TLS會話將會看起來像下面這樣:

正如你所看到的這張照片,這是一個2階段協議:第一次握手,然後完成客戶端和伺服器將能夠交換資料加密。

1.1.3.1. 握手

一般地，它是關於談判階段許多元素將用於加密資料。在本文的上下文中細節不是很有趣的，足夠說許多訊息是客戶機和伺服器之間交換,並且沒有資料可以傳送在這個階段。

實際上,握手開始有兩個條件:伺服器必須等待一些握手訊息到達，客戶端必須傳送ClientHello訊息。

我們使用Java SSLEngine類來管理整個SSL / TLS協議。Mina應該關注的現狀是會話，這樣它將能夠獲取和處理客戶端HelloClient訊息。當你在過濾器鏈中注入SslFilter，有幾件事發生：

建立SslHandler例項(我們每個會話建立一個例項)。這個SslHandler例項負責整個處理(握手和即將到來的訊息的加密/解密)。
SslHandler使用SslContext例項建立一個SSLEngine，已附加到SslFilter。
SslEngine被例項配置和初始化。
SslHandler例項儲存到Session會話中。
除非特殊需要，我們發起握手(有不同的含義在客戶端和伺服器端,客戶端將傳送ClientHello訊息,而伺服器切換到一個模式,它等待一些資料開啟)。注意握手初始化以後可以做，如果需要的話。

我們都是set。接下來的幾個步驟是純粹的SSL / TLS協議交換。如果session.write()方法被呼叫時,該訊息將被排隊等待握手完成。任何等待訊息當時SslFilter新增到鏈會導致SSL / TLS握手失敗,所以當你想注入時確保你有一個乾淨的地方。我們也不會收到任何訊息,這並不是一個SSL / TLS協議訊息。

最後一點很重要,如果你想實現StartTLS:因為它允許您的應用程式在任何時候切換，從一個純文字交換加密交換，你要確保兩側沒有等待訊息。顯然,在客戶端——啟動StartTLS——每個等待訊息已被傳送，在StartTLS可以傳送訊息之前，但它必須阻止任何其他資訊,不屬於以下握手,直到完成握手。在伺服器端,一旦StartTLS訊息已經收到,沒有訊息應該寫入遠端對等。

事實上，注入鏈中的SslFilter應該阻止任何交換不握手協議的一部分,直到握手完成。如果你提交一個訊息傳送和加密前的握手已經完成，訊息不會被拒絕，但在握手已完成時會加入隊列並處理。

在此之後，每個傳送的訊息將會通過SslHandler例項被加密,和每條訊息收到必須通過SslHandler完全解密，然後提供給下一個過濾器。

1.1.3.2. 傳送資料

好，握手已完成。你的SslFilter準備好處理傳入和傳出訊息。讓我們聚焦那些你要寫的session會話。

一個重要的事情是你可以寫多個訊息在同一session會話(如果你有一個Executor鏈)。問題在於SSLEngine不能夠處理多個訊息。我們需要序列化訊息被寫入。更糟糕的是:你不能處理傳入訊息,並在同一時間傳出訊息。

總而言之，SSL / TLS處理就像一個黑盒，只接受一個輸入並且無法處理任何東西，直到它完成了它的任務。以下為傳出訊息模式代表了它的工作方式。

這與傳入訊息沒什麼不同，除了我們之間不會有一個Executor的IoProcessor和SslFilter。這讓事情變得更簡單，除了一個重要的事情發生：當我們處理傳入訊息的時候，我們不能處理輸出訊息。請注意，它還適用於反過來:當一個即將離任的訊息被處理,我們不能處理傳入訊息:

注意：重要的是SslHander無法處理超過一個訊息。

1.1.4. Mina2的SSL/TLS

現在,我們將深入一點，深入Mina程式碼。我們將涵蓋所有過濾器操作:

· Management
o init()
o destroy()
o onPreAdd(IoFilterChain, String, NextFilter)
o onPostAdd(IoFilterChain, String, NextFilter)
o onPreRemove(IoFilterChain, String, NextFilter)
o onPostRemove(IoFilterChain, String, NextFilter)
· Session events
o sessionCreated(NextFilter, IoSession)
o sessionOpened(NextFilter, IoSession)
o sessionClosed(NextFilter, IoSession)
o sessionIdle(NextFilter, IoSession, IdleStatus)
o exceptionCaught(NextFilter, IoSession, Throwable)
o filterClose(NextFilter, IoSession)
o inputClosed(NextFilter, IoSession)
· Messages events
o messageReceived(NextFilter, IoSession, Object)
o filterWrite(NextFilter, IoSession, WriteRequest)
o messageSent(NextFilter, IoSession, WriteRequest)

1.1.4.1. Management

這裡有過濾器的管理方法:

1.1.4.1.1. onPreAdd

這就是我們建立SslHandler例項,並初始化它。我們還定義了支援密碼。

SslHandler例項將本身建立一個SSLEngine的例項，並配置SslFilter它所有的引數設定:

如果這是客戶端或伺服器端
在伺服器端,國旗,表示我們想要或需要客戶端身份驗證
啟用密碼的列表
協議列表

當它完成的時候,這個例項的引用會儲存在session會話的屬性。

1.1.4.1.2. onPostAdd

如果不影響推遲，這就是我們開始握手的地方。這就是這個方法要做的。所有的邏輯是由SslHandler實現。

1.1.4.1.3. onPreRemove

在這裡,我們停止SSL會話並清理會話(從會話的屬性中刪除過濾器從會話的鏈和SslHandler例項)。在重新整理了任何尚未處理的事件之後，Sslhandler例項也要被銷燬。

1.1.4.2. Session events

這裡有事件傳播，通過SslFilter過濾器鏈並處理:

1.1.4.2.1. sessionClosed

我們只是銷燬SslHandler例項。

1.1.4.2.2. exceptionCaught

我們有一個特殊的任務進行異常，由於關閉session會話引起：我們必須收集所有的訊息回答epending將它們新增到異常傳播。

1.1.4.2.3. filterClose

在這裡,如果有一個SSL會話開始,我們需要關閉它。在任何情況下,我們傳播事件鏈到下一個過濾器。

1.1.4.3. Messages events

最後,同樣重要的是,這三個事件相對於訊息:

1.1.4.3.1. messageReceived

當我們從套接字讀取一些資料時，收到這個事件。我們必須照顧一些角落情況:已完成握手。握手已經啟動但仍未完成*沒有握手開始,和SslHandler尚未初始化。

根據頻率列出這三個用例的順序。讓我們看看會發生什麼對這些用例。

1.1.4.3.2. The handshake has been completed

好!這意味著每一個傳入訊息封裝在一個SSL / TLS信封,而且應該解密。現在,我們討論的是關於訊息的，但我們實際上收到位元組，可能需要進行聚合，以形成完整的資訊(至少在TCP)。如果訊息是支離破碎的，我們會收到許多緩衝區，當我們將收到最後一塊時我們將能夠完全解密它。記住，我們阻塞了所有的處理，它可以對這次session會話阻塞SslHandler例項很長一段時間……

在任何情況下,每個資料塊都是由SslHandler處理,它代表SslEngine解密接收的位元組。

這是我們已經實現的基本演算法messageReceived():

get the session's sslHandler

syncrhonized on sshHandler {

if handshake completed

then

get the sslHandler decrypting the data

if the application buffer is completed, push it into the message to forward to the IoHandler

else

enqueue the incoming data}

flush the messages if any

這裡的重要部分是SslHandler將累積資料,直到有一個完整的訊息進入鏈。這可能需要一段時間，並且有許多套接字讀取。原因是SSLEngine無法處理訊息，除非它有所有位元組符合完全解碼的資訊。

提示:增加傳輸緩衝區大小限制往返需要的數量來發送一個大訊息。

1.1.4.3.3. The handshake has not been completed

意味著收到訊息是握手協議的一部分。沒有將傳播到IoHandler,訊息將被SslHandler消費。

直到完成完整的握手,每個傳入的資料將被視為一個握手規範訊息。

同時,訊息IoHandler將加入佇列,等待握手完成。

這是一個模式代表完整的過程,當資料在兩個傳送接收:

1.1.4.3.4. filterwWrite

這個事件處理時IoSession.write()方法被呼叫。

如果SSL session會話沒有開始,我們只是積累寫的訊息。它將在稍後傳送。

在這裡有一個棘手的引數,對於一些非常具體的需要。通常,當實現startTLS協議,伺服器切換從一個非安全連線到一個安全連線的意思是一個應用程式訊息(和潛在的響應),我們需要響應傳送回客戶機之前SslFilter安裝(否則,響應將被阻塞,etablishement安全連線會失敗)。這是DISABLE_ENCRYPTION_ONCE屬性。它包含什麼都無所謂(它可以是一個布林值),這是足夠的為這個引數在會話第一訊息bypasse SslFilter。

我們控制在會話的屬性中存在DISABLE_ENCRYPTION_ONCE標識,並且如果存在,我們將它從session會話中移除，並且推送訊息進入訊息佇列被髮送。

此外，如果握手還沒有完成,我們保持訊息佇列中,如果完成,我們加密和排程寫。

如果已經安排寫一些訊息，我們就釋放。

1.1.4.3.5. messageSent

在這裡,它只是一種回到未加密的IoHandler訊息傳播。

1.1.5. SSLContext初始化

我們看到,為了建立SSL會話,我們需要建立一個SSLContext。這是程式碼:

SSLContext sslContext;

try{

    // Initialize the SSLContext to work with our key managers.

    sslContext = SSLContext.getInstance( "TLS" );

    sslContext.init( ... );

   // Provide the needed KeyManager[], TrustManager[] and SecureRandom instances
}catch ( Exception e ){

    // Handle your exception
}

我們沒有暴露的是建構函式和init()方法。

SSLContext可以影響——通過其建構函式建立,或者我們讓靜態工廠返回一個例項(這是我們所做的在前面的程式碼。第二種方法非常簡單,適合大多數時候。這足以通過使用協議的名稱,這是:

· SSL
· SSLv2
· SSLv3
· TLS
· TLSv1
· TLSv1.1
· TLSv1.2 (not supported in Java 6)

這裡強烈建議選擇更高的演算法(即TLSv1.2)如果你的客戶支援它。

init()方法接受3個引數:

· a KeyManager (can be null)
· a TrustManager (can be null)
· a random generator (can be null)

如果引數被設定為null,安裝安全提供者會選擇優先順序最高的實現。