客户端和服务器之间的安全连接
我正在开发一个服务器组件，它将为嵌入式客户端提供服务，这也是我的控制。
现在一切都是测试版，安全性如下：
-
客户端通过https发送用户名/密码。
-
服务器返回访问令牌。
-
客户端通过自定义标头中的访问令牌通过http进行进一步请求。
这对于演示来说很好，但它有一些问题需要在发布之前修复：
-
任何人都可以复制有些用户回答说这不是问题，因为它超过了https。 我的错。login请求，重新发送并获取访问令牌。 -
任何人都可以通过检查请求标头来监听并获取访问密钥。
我可以想到一个对称的密钥加密，带有时间戳，所以我可以拒绝重复的请求，但我想知道这个场景是否有一些众所周知的良好实践（这似乎很常见）。
非常感谢您的洞察力。
PS：我正在使用Java作为服务器而客户端是用C ++编写的，以防万一。
我没有得到第一部分，如果登录请求是https，那么任何人都可以复制它？
关于第二部分，t这是一个非常标准的会话劫持场景。 看到这个问题 。 当然，这里没有内置的浏览器选项，但基本思路是相同的 – 要么只在重要时通过安全连接发送令牌，要么以某种方式将令牌与发送设备相关联。
在浏览器中，基本上你所拥有的只是IP地址（这不是很好），但在你的情况下，你可能能够表达你的设备的特定信息，你根据请求进行validation，以确保不存在相同的令牌从其他地方使用。
编辑：你可以在这里幸运，并能够排除在代理后面改变的IP地址，并实际上将其用于此目的。
但是在一天结束时，使用来自知名且经过审核的库中的https而不是尝试在这里推广自己更安全。 我意识到https是一个开销，但滚动你自己有很大的风险，可以找到攻击者可以利用的明显事情。
第一个问题，只是为了得到它：如果你对恶意的客户端模仿访问充分关注，为什么不通过HTTPS进行整个对话？ 这个应用程序的最小性能是否足够重要，它不值得增加安全层？
第二，有人如何重播登录请求？ 如果我没弄错的话，这是通过HTTPS进行的; 如果连接设置正确，HTTPS会阻止使用一次性随机数的重放攻击（请参阅此处 ）。
其中一个常见的建议是 – 使用https
https man在中间攻击旁边使用https进行整个会话应该足够可靠。 您甚至不需要担心访问令牌 – https会为您解决此问题。
使用http进一步请求似乎会引入一些漏洞。 现在任何拥有网络嗅探器的人都可以拦截您的流量窃取令牌并欺骗您的请求。 你可以构建保护来防止它 – 令牌加密，使用一次令牌等，但这样做你将重新创建https。
回到中间攻击中的https人 – 这是基于某人能够在您的服务器和客户端之间插入自己并通过他们的代码汇集您的请求的能力。 这一切都是可行的，即如果攻击者可以访问物理网络。 攻击者将面临的问题是，他无法为您提供适当的数字证书 – 他没有您用来签名的私钥。 当通过浏览器访问https时，浏览器会向您发出警告，但仍然可以让您访问该页面。
在您的情况下，您的客户将与服务器通信。 并且您可以确保证书的所有正确validation都已到位。 如果你这样做，你应该没事
编辑
借调Yishai – 是的，涉及一些开销，主要是CPU，但如果这个额外的开销推动你的服务器在船上，你的应用程序有更大的问题