5

I am trying to implement a DTLS server using OpenSSL. I can get app data through, but when the client and server have negotiated, I have noticed that the session_id is null on the server.

Checking the code, more specifically ssl_sess.c, session_id_length is explicitly set to zero, the comments refer to RFC4507.

My question is when the connection is negotiated, what ID can I use to uniquely identify a client?

I have noticed that on the client side, the session id seems to be calculated from the ticket, but this does not seem to happen on the server.

4

1 に答える 1

4

データグラムベースのアプリケーションと同じです。RFC 4347 (データグラム トランスポート層セキュリティ) に従って:

IPsec とは異なり、DTLS レコードにはアソシエーション識別子が含まれていないことに注意してください。アプリケーションは、アソシエーション間で多重化するように手配する必要があります。 UDP では、これはおそらくホスト/ポート番号で行われます。

(私のものを強調)

あなたのコメントから、実際には「セッション」全体で状態を維持しようとしているように見えます (あいまいですが、おそらく適切な記述子)。「セッション」全体で状態を維持することは、アプリケーション層の問題です。(D)TLS はトランスポート層です (名前の由来)。

厳密に言えば、(D)TLS を介して実行されるアプリケーションには、クライアントからサーバーに送信される「クライアント ID」という独自の概念が必要です。アプリケーションの性質とセキュリティ要件に応じて、これに対処する方法は無数にあります (もちろん、ユーザー名とパスワードが最も一般的です)。

もう 1 つのオプションは、独立したアプリケーション層 ID の代わりにクライアント側の証明書を使用することですが、それでもアプリケーション層が何が起こっているのかを理解し、クライアントの証明書を永続的な状態情報に関連付ける必要があります。面倒なことに、これにはクライアントごとに個別の証明書を管理する必要があります。これは非常に負担が大きいため、ほとんどの人はこのルートをたどりません。これには利点があります。たとえば、ユーザーは間違ったパスワードを正確に選択したり、モニターの付箋に書き込んだりできません。一方、誰かが証明書が保存されているファイルにアクセスできるようになると、いずれにせよゲーム オーバーになります。

もちろん、セキュリティと認証については、多くの本が書かれている可能性があります (そして、非常に頻繁に書かれています)。

于 2011-05-29T11:14:34.310 に答える