wolfSSLを利用されている皆さんの中でTLS1.3の利用を選択されている方々の比率がますます増えているのは大変素晴らしいことです。新しいプロトコルを使って、向上したセキュリティの恩恵にあずかる企業が増えているということです。同時に、アプリケーションでセッションチケットを使ってセッション再開を行う必要性に初めて気付かれた方々がいらっしゃいます。最新のwolfSSL 4.7.0ではこれまでより簡単にセッションチケットを扱えるようになりました。
暗号化アルゴリズム
セッションチケットを扱うにはそれらを暗号化および復号するためのコールバックの実装が必要です。wolfssl/test.hにその実装例があります。myTicketEncCb()関数を見てください。以前はChacha20-Poly1305を使って暗号化するために使われていましたが、現在は代わりにAES-GCMを使用するようになっています。皆さんのアプリケーションに適したアルゴリズムを選択してください。
デフォルト暗号化コールバック
wolfSSLでは、デフォルトのコールバックを提供することは価値があると判断しました。 そこでwolfSSL 4.7.0には、デフォルトのセッションチケット暗号化コールバックを含めています。このコールバックの機能を理解すると、デフォルトを使用するか、あるいは独自に作成する必要があるか判断できます。 コールバックは、セッションチケットの暗号化と復号に使われます。次のいずれかを定義することにより、使用する暗号化アルゴリズムを選択できます：
- WOLFSSL_TICKET_ENC_CHACHA20_POLY1305 — ChaCha20-Poly1305を使用
- WOLFSSL_TICKET_ENC_AES128_GCM — 128ビット長の鍵でAES-GCMを使用
- WOLFSSL_TICKET_ENC_AES256_GCM — 256ビット長の鍵でAES-GCMを使用
それ以外の場合、デフォルトはChaCha20-Poly1305になります。そのアルゴリズムがコンパイルされていない場合は、128ビット長のAES-GCMを使用します。
コールバックで生成される鍵には、プライマリとセカンダリの2つがあります。プライマリキーは、最初の使用時に秘密の乱数ジェネレーターを使用して生成され、その時点で有効期間が与えられます。デフォルトでは、これは1時間です。 WOLFSSL_TICKET_KEY_LIFETIMEを定義することにより、2段階でカスタマイズできます。有効期間は、デフォルトで5分であるセッションチケットの有効期間よりも長くする必要があります。これも、SESSION_TICKET_HINT_DEFAULTを定義することにより、2段階で変更できます。鍵の寿命が長いほど、鍵が危険にさらされた場合の露出時間が長くなります。
鍵には、暗号化用と復号用の2つの有効期間があります。 チケットの暗号化に使用される鍵は、チケットの存続期間中保持する必要があります。 したがって、暗号化の有効期間は、鍵の合計有効期間、つまり復号の有効期間よりも、チケットの有効期間だけ短くなります。 次の図を参照してください。
プライマリキーが暗号化のために期限切れになっているが復号のためは期限切れになっていない場合、つまり上の影付きの領域にある場合、次の暗号化要求でセカンダリキーが生成されます。
セカンダリキーは、暗号化の有効期限が切れるまで使用され、その後、新しいプライマリキーが生成されます。 セッションチケットが一般的に使用されないシナリオでは、暗号化の新しい呼び出しの前に、プライマリキーが復号のために期限切れになる可能性があることに注意してください。 この場合、新しいプライマリキーが生成されます。 マルチスレッド環境では、グローバルキーの生成はミューテックスによって保護され、上書きされないようにします。
鍵のエクスポートとインポートは：
- wolfSSL_CTX_get_tlsext_ticket_keys( )
- wolfSSL_CTX_set_tlsext_ticket_keys( )
を使用して行うこともできます。 これらのAPIは、プロセスまたはサーバーマシン間で鍵を共有するのに役立ち、有効期限はblobに含まれています。 デフォルトのセッションチケット暗号化コールバックは、ほとんどのユースケースをカバーするはずです。しかし、 別の暗号化アルゴリズムを使用する場合、メモリが非常に限られている場合、またはサーバー間で高度な共有戦略が必要な場合は、WOLFSSL_NO_DEF_TICKET_ENC_CBを定義し、独自のコールバックを設定する必要があります。
TLS1.3とTLS1.2におけるセッションチケットの利用
現在TLS 1.3を使用している方々でも、TLS 1.2接続ではセッションチケットを使用していなかったため、引き続きTLS1.2ではセッションチケットが使用されないようにしたいと考える方がいらっしゃるでしょう。 現在、そのような要求をサポートする次の関数を用意しています：
- wolfSSL_CTX_NoTicketTLSv12( )
- wolfSSL_NoTicketTLSv12( )
これらの関数を呼び出すと、コンテキストまたはオブジェクトに対してフラグが設定され、ネゴシエートされたプロトコルバージョンがTLS 1.2以下の場合、ハンドシェイクではクライアントとサーバーのセッションチケットを無視します。
ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。
原文：https://www.wolfssl.com/wolfssl-session-tickets-tls-1-3-tls-1-2/