c++ - 套接字身份验证和加密

Question

这包括多个问题，但由于它们之间有些相关性，因此我想将它们一起发布。

我在做什么:
我正在编写一个服务器-客户端应用程序，用户必须在其中登录才能与服务器通信。现在，我正在使用udp(是的，我确定我想使用udp)进行一些小的修改。

第一部分:

存储用户连接的最佳方法是什么？

我的想法:

创建一个容器，该容器存储允许连接的所有客户端的所有地址(成功登录后)

创建一个存储所有 session ID的容器( session ID将与每个数据包一起发送)

赞赏其他想法(特别是如果已经在使用它们的话)

我的担心:

有人可以更改数据包发件人的地址吗？ (我认为是)

session ID可能会被嗅出。 (我记得有些大公司有这个问题)

第二部分:

但是，我将不得不对我的数据包进行加密。在(2)的情况下，加密可以与 session ID相关联，以便仅可以使用与该客户端相对应的正确 session key 来解密来自用户的数据包(例如，AES仅用于提供示例)。

这将需要一种合适的算法，该算法要快速(可能有30-50个数据包，每秒从单个客户端发送256个字节)

哪种算法适用于此算法(RSA似乎有点慢)？

该算法如何工作？ (仅是简短的摘要，但希望您能获得更多信息的来源)

会加密数据包，使其与原始数据包一样大还是更大，以便我必须在服务器端编写某种缓存机制来组装这些数据包？

哦，顺便说一句。我不需要有关公钥/私钥，握手等的解释。重要的是，要知道我将在商用产品中使用此算法(从许可角度出发)。

Answer 1

如果没有特定的应用程序，这很难回答，但是我将尝试给出一些一般性的提示:

Create a container storing all addresses of all clients which are allowed to connect (after successful login)

由于NAT，这根本行不通，可悲的是NAT仍在使用中，由于IPv4耗尽，实际上甚至还在增加。您至少需要src-ip + src-port。即使这样，考虑到移动用户，您可能永远也不想使用IP作为 session ID。普通的智能手机将很容易在蜂窝网络和WiFi网络之间切换，大多数情况下会导致IP堆栈完全重启，因此无法将新流量与之前的流量相关联。这可能是问题，也可能不是问题，但是除非您对IP地址有控制权，否则我永远不会使用这种方法。

Create a container storing all session ids (session id will be sent with every packet)

这实际上是通用解决方案，您的第一个解决方案只是一个特定的实现，在其中您将source-ip用作 session ID。如果您担心 session ID管理，只需使用 UUID's， session ID之间发生冲突的几率就非常低。或者，当使用公钥/私钥加密时，可以将用户的公钥用作 session ID。

这里的重要部分是如何协商 session ID。您可能想让用户选择，您可能想输入一个“特殊” session ID(例如0)来让服务器选择。最佳选择取决于您的应用程序。

Could someone change the address of the sender of a packet? (I assume yes)

当然，这被称为 man-in-the-middle attack(如果在传输中的数据包上完成)或 ip address spoofing(如果发送带有伪IP的数据包)，并且对于大多数最终用户而言都是无法检测到的。尽管许多网络都对此提供保护，例如使用 Reverse Path Forwarding。

Session ids could get sniffed out. (I remember some big company names having this problem)

如果已加密:也许(请参阅下文)。如果未加密:当然可以。

然后，关于加密问题的整个部分:

通常，您走在正确的轨道上，通常希望对常规流量使用对称 key 加密方案。 AES是一个不错的选择，但还有其他选择，请进行一些研究。

但是，您在设置加密时遇到问题。通常，您需要安全地获得双方的加密 key ，而无需人们嗅探它们。您可以尝试通过航空邮件发送 key ，但是我怀疑大多数用户会发现这种用户友好的方式甚至是不安全的。

那就是非对称 key 加密方案出现的地方。通常，您将使用RSA之类的东西来协商初始连接( session ID，加密 key ，也许还有一些记帐等)，然后让对称 key 接管实际流量。流行的方案是 Diffie-Hellman key exchange，但是仍然有更多的方案。

话虽这么说，您可以很好地保护自己的 channel ，但是中间人攻击始终是一个令人担忧的问题。事实证明，实际上您几乎无法采取任何措施来阻止这种情况，因为您无法控制任何一方(客户端)，如果这是一台受感染的计算机，那么所有赌注都将关闭:

为每个用户使用一个唯一的，预分配的私钥，您可以在传入 session 中对其进行验证。如果不以其他方式获得 key ，这将使mitm攻击更加困难，但是非自动生成的私钥通常很难与用户友好性结合使用。您在如何分发它们(该死，我该如何处理那里的mim？)，如何在用户处存储它们(哦，他使用笔记本电脑，iPhone和iPad)，在丢失时如何恢复它们上遇到了麻烦。 ..

确保所有流量都由客户端启动，并立即使用服务器的公钥加密。这很容易，因为您不必分发私钥。但是，黑客仍然可以用自己的 key 替换服务器的公共(public) key ，但这要困难得多，而且如果做得好，几乎可以归结为在客户端计算机上安装病毒。

在客户端应用程序中进行一些完整性检查。例如，确保要连接到服务器IP的已知池，检查DNS查询是否正确，等等。它与故障安全相距甚远，但它是简单的验证，可以阻止潜在的黑客。

教育您的用户。这就是许多银行的做法(至少在我居住的地方)，让他们进行定期的防病毒检查，仅使用受信任的WiFi网络，验证DNS服务器，...。当然，有些事情比其他事情更难教，但是一些常识可以使您走得很长。

哦，最后我确实要评论UDP部分:您真的确定吗？因为该方案的几乎所有内容，甚至更多，都包含在 TLS中，它集成在 boost asio中。如果您的流量是低速率的，我几乎无法想象它是需要UDP提供的优点的应用程序，除非您想要保护voip(已经完成)，否则请不要浪费精力。