Questions tagged «man-in-the-middle»

我已经重新安装服务器，并且收到以下消息： [user@hostname ~]$ ssh root@pong @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the …

618 ssh  verification  ipa  man-in-the-middle 

我已经阅读了与该问题有关的大量文档，但仍然无法将所有内容整理在一起，因此我想提出几个问题。 首先，我将以我理解的方式简要描述身份验证过程，因为在这方面我可能会误会：客户端启动连接，服务器使用公钥，一些元数据和数字签名的组合来响应服务器的连接。受信任的权威。然后，客户端将决定是否信任服务器，并使用公共密钥对某些随机会话密钥进行加密并将其发送回去。只能使用存储在服务器上的私钥来解密此会话密钥。服务器执行此操作，然后HTTPS会话开始。 因此，如果我在上面是正确的，问题是在这种情况下中间人攻击如何发生？我的意思是，即使有人用公共密钥拦截了服务器（例如www.server.com）的响应，并且有某种手段使我认为他是www.server.com，他仍然无法解密我的会话密钥没有私钥。 说到相互认证，这是否完全关系到服务器对客户端身份的信心？我的意思是，客户端已经可以确定自己正在与正确的服务器通信，但是现在服务器希望找出谁是客户端，对吗？ 最后一个问题是关于相互身份验证的替代方法。如果我在上述情况下充当客户端，如果在建立SSL会话后在HTTP标头中发送登录名/密码怎么办？如我所见，该信息无法被截取，因为连接已被保护，服务器可以依靠它来识别我。我错了吗？与相互身份验证相比，这种方法的缺点是什么（仅安全问题很重要，而实现的复杂性却不重要）？

91 security  ssl  man-in-the-middle