这仍然容易受到 MIM 攻击吗？

是的，是的，因为您可能会使用会话 cookie，这些会话 cookie 可能会通过浏览器插件（如 firesheep 或 man-in-the-middle）很容易被嗅到。

有哪些注意事项？

现在的最佳实践是让整个应用程序通过 HTTPS 运行，因为：

• 安全 cookie在混合环境中不起作用
• 中间人攻击确实在混合环境中起作用
• 确保您的网站对其用户的真实性在混合环境中不起作用
• 无需考虑 HTTPS 页面中的 HTTP 资源和丑陋的浏览器警报

为了确保整个站点的 HTTPS：

• 创建 2 个虚拟主机配置，一个用于 http：，一个用于 https：
• 在您的 http 配置中，使用重定向 from http://site/resourcetohttps://site/resource作为此配置中的唯一模式，因此如果有人输入http://site/somepath它，将始终重定向到安全站点
• 在您的 https 配置中，使用HTST标头来帮助确保（基于浏览器）您的用户始终通过 HTTPS 访问您的站点

其他所有内容，例如 login-page-encryption-only 已过时；搜索“火羊”

是的，由于您开始使用未加密的 Web 应用程序，因此您很容易受到 MITM 攻击。这就是攻击发生的地方，因为攻击者可以修改任何https://secure.bank.com对http://secure.bank.com. 然后，攻击者会拦截您的数据，并将内容中继到实际的安全连接https://secure.bank.com

强烈建议从会话一开始就强制使用 SSL，并且您应该确保只宣传安全 URL。

访问后http://normal.bank.com，攻击者可以将所有链接替换为https://secure.bank.com链接http://secure.bank.com。当用户单击 时http://secure.bank.com，MITM 将愉快地通过 HTTPS 连接到服务器，并通过 HTTP 将内容返回给客户端。无论此处使用何种重定向预防措施，MITM 都可以阻止整个重定向。

总之，是的，您仍然容易受到 MITM 攻击。

我要在这里逆势而上，说像这样重定向是可以接受的。

确实，如果用户访问http://secure.bank.com/并继续使用该站点而不进一步检查证书、URL 等，则用户很容易受到 MITM 的攻击。

但是，这是用户行为的问题，而不是您可以在服务器端解决的问题。

让我们想一想如何尝试修复此服务器端。您可以显示一个信息页面，而不是发出重定向，可能会带有措辞强硬的警告“要安全访问此站点，您必须使用https://secure.bank.com/ ”或者您可以让 Web 服务器仅侦听端口 443并拒绝 80 端口。

现在如果攻击者完全控制了用户的网络会发生什么？当用户访问http://secure.bank.com/时，攻击者将他们重定向到https://secure.bank.com.attacker.com/并显示一个钓鱼页面。或者，他们可能会直接在http://secure.bank.com/中插入钓鱼页面。无论哪种方式，经验丰富且警惕的用户都可以检测到这一点，但许多用户会继续使用。

真正的http://secure.bank.com/的行为方式没有任何区别——攻击者可以为所欲为。

所以最终这是一个用户培训问题。网站的行为会影响这一点。绝大多数用户访问该站点时，他们将访问真实站点，而不是 MITM 攻击。如果站点自动重定向它们，这不会阻止它们将来使用 http URL。如果他们收到警告消息，或者网站根本无法运行，他们将很快学会默认使用 https。

但是，作为网站运营商，您对这样培训用户的责任有多大？现实情况是，绝大多数网站都会像这样从 http 重定向到 https。从商业角度来看，为什么让您的网站比竞争对手更难使用？如果只是你做这个立场，你真的会对一般用户行为产生影响吗？

出于这些原因，总的来说，我建议大多数网站都以这种方式从 http 重定向到 https。

为了尽可能地锁定它，我建议您设置重定向，以便http://secure.bank.com/重定向到https://secure.bank.com/ - 剥离 URL 的其余部分。