应用错误收集

我正在考虑一个复杂的聊天应用程序，其中两个客户端可以像在p2p网络中那样直接相互连接。我的想法复杂性是关于网络和安全性（身份验证）。

网络部分

据我在互联网上阅读，p2p连接可以通过 TCP HOLE PUNCHING 来实现。在大多数打孔的例子中，我见过一个中间服务器，可以帮助客户将他们的地址相互传递。想象一下，服务器出现故障。我仍然希望我的客户能够找到对方。一个非常疯狂的想法是让他们（例如我的应用程序用户而不是代码）使用任何其他通信渠道来告诉对方一个代码（从数据生成）。我希望这个数据包含客户端{local ip, local port, public ip and public port}（在我见过的所有TCP打孔示例中，都使用了它们。）

客户自己可以找到这些数据吗？这够了吗？（考虑来自客户端的额外HTTP请求的帮助以找到他的PUBLIC IP地址）

另外，有没有比使用TCP打孔更好的想法？我的客户大部分都在NATS之后

认证和安全部分

我正尽力在中间服务器上越来越少地依靠帮助。我的客户端应用程序可以在建立连接后执行Diffie Hellman密钥交换和加密。但是，由于我希望真正的用户使用此应用程序，我需要一些客户端可以相互验证的方法。我不希望这个应用程序被广泛的用户使用。因此，也许他们有时可以（在现实世界中）实际看到对方并使用蓝牙（或应用程序层中的其他文件共享系统）传输某种文件，这些文件可以是其令牌或身份验证令牌。稍后，当他们想要在网络中建立连接时，此令牌可以稍后用于相互验证。这是我唯一的想法：

这里的问题是如果杰克和罗斯见面并且他们转移了他们的个人代币，后来杰克有罗斯认证令牌，可以在与吉姆交谈时用它假装成罗斯。

除非为这两个令牌生成具有相同值的令牌，并且某种方式表示其仅用于 {Jack和Rose}通信的令牌，并且{Jim和Rose}的令牌不同。（我的意思是它对任何对话或一对用户的唯一标记）

还有风险吗？任何类型的网络攻击或其他技巧都可以打破这个吗？

没有中间服务器的{p} pp网络中的客户端身份验证

1 个答案: