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

Question

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

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

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

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

非常感谢你的回复 BR 斯登

Answer 1

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

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

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

Answer 2

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