DTLS Session ID (OpenSSL)

Question

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

Code verification, or rather ssl_sess.c, session_id_length is explicitly set to zero, the comments relate to RFC4507.

My question is, when the connection is being discussed, which identifier can be used to uniquely identify the client?

I noticed that on the client side, the session identifier seems to be computed from the ticket, but this does not seem to be happening on the server.

Answer 1

Same as any datagram-based application. Per RFC 4347 (Datagram Transport Layer Security):

Note that unlike IPsec, DTLS records do not contain any association identifiers. Applications should organize multiplexing between associations. With UDP, this is supposedly with the host / port number.

(Emphasis mine)

---

From your comment, it looks like you are trying to maintain state through "sessions" (an undefined, but probably an applicable descriptor). Maintaining state through "sessions" is an application level problem. (D) TLS is the transport layer (hence the name).

Strictly speaking, an application working on (D) TLS must have its own concept of a "client identifier", which is sent by the client to the server. There are many ways to handle this, depending on the nature of your application and your security requirements (username + password, of course, is the most common).

Another option is to use client-side certificates as a substitute for an independent application-level identifier, but this still requires the application-level to understand what is happening and associates the client’s certificate with persistent state information. Annoyingly, this requires managing a separate certificate for each individual client. It is quite burdensome that most people do not take this route. It has advantages, for example. users cannot precisely select a bad password or write it on a note on their monitor. On the other hand, if someone gains access to the file in which the certificate is stored, in any case it is a game.

Of course, many books can be (and have been with great frequency) written for security and authentication ...