使用 HTTPS 进行客户端-服务器通信

Question

我想使用 HTTPS 来保护我的客户端和服务器之间的通信。第一个加密通信将用于验证用户身份 - 即检查他/她的用户名和密码。

在服务器成功检查用户凭据后，我想开始在后续请求中获取一些数据。但是服务器如何确定后续请求是由用户发送的，其凭据已被检查？

由于 TCP 连接可能在登录和后续 HTTPS 请求之间关闭，（我认为）这意味着 SSL 上下文必须由服务器释放，因此对于新的 GET 请求，必须建立新的 TCP 连接并且必须进行新的 SSL(TLS) 握手（即双方必须交换新的加密共享密码等）

为此，我认为服务器需要在初始身份验证请求的 200 OK 响应中向客户端发送一些随机生成的随机数（在一定时间内有效），我将在每个后续请求中包含这些随机数，因此服务器将能够根据这个随机生成的 nonce 检测请求背后的用户名，并检查该用户是否已经登录。我的理解是否正确？

非常感谢您的回复 BR 不锈钢

Answer 1

最简单的方法是要求所有通信都通过 HTTPS 进行（因此数据是机密的；除了客户端和服务器之外没有人可以看到它）并在该安全连接内的每个请求上使用简单的用户名和密码。这在实践中非常简单（用户名和密码实际上作为 HTTP 标头通过连接，这在这里没问题，因为我们使用的是 HTTPS）并且服务器可以检查每次允许用户。您无需担心 SSL 握手；这是 SSL/HTTPS 层的职责（这就是为什么 HTTPS/SSLnice）。

或者，登录可以使用任何方法完成，并生成存储在会话 cookie 中的某种幻数（例如，UUID 或随机数和用户名的加密哈希）。随后的请求可以检查幻数是否是它从会话开始时识别的一个（并且自发出以来没有经过太多时间）；注销只是忘记了服务器端的幻数（并要求客户端也忘记）。实现这一点需要做更多的工作，但仍然不难，并且有服务器端的库来处理驴子的工作。

第一个选项特别适合您编写供其他程序使用的内容，因为它非常容易实现。第二种选择在客户端是 Web 浏览器的情况下更好，因为它可以让用户更好地控制他们的浏览器何时被授权（程序 API 往往不需要那种东西）。每当客户端将成为浏览器时，您也需要注意防范其他类型的攻击（例如，各种类型的请求伪造），但这几乎与其他一切无关。

Answer 2

在您的情况下发明自定义身份验证机制是非常冒险的 - 很容易犯错误，这会导致很多错误的行为。因此，对我而言，正确的方法是使用 HTTPS 并在每个请求中传递用户凭据。