DTLS (OpenSSL) 中的会话 ID
我正在尝试使用 OpenSSL 实现 DTLS 服务器。我可以通过应用程序数据，但是当客户端和服务器协商时，我注意到服务器上的 session_id 为空。
检查代码，更具体地说是ssl_sess.c，session_id_length显式设置为零，注释参考RFC4507。
我的问题是，当协商连接时，我可以使用什么 ID 来唯一标识客户端？
我注意到在客户端，会话 ID 似乎是从票证中计算出来的，但这似乎不会发生在服务器上。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
与任何基于数据报的应用程序相同。根据 RFC 4347（数据报传输层安全）：
（强调我的）
从您的评论来看，您实际上是在尝试跨“会话”（一个模糊但可能适用的描述符）维护状态。跨“会话”维护状态是一个应用程序层问题。 (D)TLS 是传输层（因此得名）。
严格来说，通过 (D)TLS 运行的应用程序需要有自己的“客户端 ID”概念，由客户端发送到服务器。有无数种方法可以处理这个问题，具体取决于应用程序的性质和安全要求（当然，用户名+密码是最常见的）。
另一种选择是使用客户端证书来替代独立的应用程序层 ID，但这仍然需要应用程序层了解正在发生的情况并将客户端的证书与永久状态信息相关联。令人烦恼的是，这需要为每个客户端管理单独的证书。这实在是太繁重了，以至于大多数人都不会走这条路。它确实有优点，例如，用户无法准确选择错误的密码或将其写在显示器上的便签上。另一方面，如果有人可以访问存储证书的文件，那么游戏就结束了。
当然，许多书籍可以（并且已经非常频繁地）撰写关于安全和身份验证的主题......
Same as you would with any datagram-based application. Per RFC 4347 (Datagram Transport Layer Security):
(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...