Session ID in DTLS (OpenSSL)

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开发者_Python百科 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.

---

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

Note that unlike IPsec, DTLS records do not contain any association identifiers. Applications must arrange to multiplex between associations. With UDP, this is presumably done with host/port number.

(Emphasis mine)

---

From your comment, it looks like you're actually trying to maintain state across "sessions" (a vague but probably applicable descriptor). Maintaining state across "sessions" is an application-layer problem. (D)TLS is transport-layer (hence the name).

Strictly speaking, the application running over (D)TLS needs to have its own concept of a "client ID" which gets sent by the client to the server. There are innumerable ways to deal with that, 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-layer ID, but that still requires the application layer to understand what is going on and associate the client's certificate with the permanent state information. Annoyingly, this requires the management of a separate certificate for every single client. This is sufficiently burdensome that most people don't take this route. It does have advantages, e.g. users can't exactly pick a bad password or write it on a sticky note on their monitor. On the other hand, if someone gets access to the file the certificate is stored in, it's game over anyway.

Of course, many books could be (and have been with great frequency) written on the subject of security and authentication...