首先，我在我的网站上为 OpenID 设置了一个私人代表，并将我的 SE 帐户指向我网站上的 URL；SE 不知道实际的 OpenID 提供程序端点，直到我的委托响应告诉它。
其次，在向 SE 等人进行身份验证时，我注意到如果我没有明确键入 https://... 它会使用 HTTP 而不是 HTTPS 发出请求。
第三，将我的 SE 帐户与我的 OpenID 端点关联后，我可以使用 HTTP 或 HTTPS 登录，尽管在关联帐户时使用了 HTTPS。
因此，这不会让我面临 MITM 攻击，攻击者只需修改来自我的 Web 服务器的响应以委托给他们自己的 OpenID 提供商，从而获得对我的 SE 帐户的访问权限吗？
注意：我不是在谈论 OpenID 提供程序的实际身份验证步骤，它确实使用 HTTPS 并在通过 HTTP 访问时重定向到 HTTPS，我说的是 SE 对我的委托的初始请求，SE 允许使用 HTTP 完成因为它们只存储从基域开始的 URL（省略协议和子域）以用于匹配帐户而不是完整的 URL。
是的。因此，您应该始终使用 https。
更糟糕的是，一些服务提供商违反了规范：
11.5.2. HTTP 和 HTTPS URL 标识符
依赖方必须区分具有不同方案的 URL 标识符。
任何违反此规则的消费者/服务提供者都容易受到攻击。这尤其糟糕，因为用户无法保护自己：他可能每次都使用 https，但攻击者只能使用 http。
此外，不需要中间向量中的人。攻击者能够读取到身份提供者的流量就足够了；在他选择的时间。
当最终用户输入被处理为 URL 时，它被处理为 HTTP URL。
因此，就默认为 http 而言，StackExchange 的行为是合规的。
规范继续：
[...] 建议从 HTTP URL 发出重定向到 HTTPS URL。由于 HTTP 和 HTTPS URL 不等价，并且使用的标识符是重定向后的 URL，因此使用此方案时不会降低安全性。
如果攻击者可以控制 HTTP URL，它不会对 HTTPS URL 产生影响，因为除了启动发现过程之外，HTTP URL 从未用作标识符。
注意：这种方法在第一次发现过程中仍然容易受到攻击。
规范： http: //openid.net/specs/openid-authentication-2_0.html#anchor45
是的。 我怀疑任何可以 MITM StackExchange <-> 您的网站（例如，可能有自签名证书）的人都能够插入一个替代 OpenID 委托（到 index.html 中）并使用它来闯入您的 StackExchange帐户。
您使用的委托 URL 是什么？HTTP 还是 HTTPS？
当您单击 Google 的 OpenID 提供程序或任何预配置的 OpenID 站点时，您将被重定向到 HTTPS 站点。
据我所知，只有一家 OpenID 提供商可以出色地处理这种情况：Symantec Verisign PiP Labs。登录后，您可以选择拒绝由重定向创建的所有初始身份验证。相反，他们要求您直接登录pip.verisignlabs.com，然后导航到 Stackoverflow 并登录。
这样做的问题是每次登录都会发起新的 HTTPS 请求，速度很慢。它绝对非常慢。但是，如果在 HTTP/1.1 上使用保持连接持久性的方式正确处理，则不是，所以这只是开发人员的纯粹懒惰......“谁需要 ssl 进行身份验证”？:-)