Isn't OpenID over HTTP (not HTTPS) fatally flawed when delegates are used?

Question

First, I have a private delegate set up on my web site for OpenID and pointed my SE account at the URL on my web site; SE has no knowledge of the actual OpenID provider endpoint until my delegate response tells it.

Second, when authenticating to SE et al I note that if I don't explicitly key in https://... it makes the request using HTTP instead of HTTPS.

Third, having associated my SE account with my OpenID endpoint, I am able to use either HTTP or HTTPS to login, despite using HTTPS when the account was associated.

Does this not, therefore, open me up to a MITM attack whereby the attacker simply modifies the response from my web server to delegate to their own OpenID provider, thereby gaining access to my SE account?

Note: I am not talking about the actual authentication step with the OpenID provider, which does use HTTPS and redirects to HTTPS if accessed via HTTP, I am talking about the initial request from SE to my delegate, which SE allows to be done using HTTP because they only store the URL from the base domain onwards (omitting both the protocol and the sub-domain) to use for matching up to an account instead of the full URL.

Answer 1

Yes, it is. So you should always use https.

Even worse, some service providers violate the specification:

11.5.2. HTTP and HTTPS URL Identifiers

Relying Parties MUST differentiate between URL Identifiers that have different schemes.

Any consumer/service provider which violates this rule, is vulnerable to an attack. This is especially bad because a user cannot protect himself: He may use https every single time, but the attacker can just use http.

Furthermore a man in the middle vector is not required. It is sufficient for the attacker to be able to read the traffic to the identity provider; at a time of his choice.

When end user input is processed into a URL, it is processed into a HTTP URL.

So the behavior of StackExchange is in compliance as far as defaulting to http is concerned.

The specification continues:

[...] it is RECOMMENDED that a redirect be issued from the HTTP URL to the HTTPS URL. Because the HTTP and HTTPS URLs are not equivalent and the Identifier that is used is the URL after following redirects, there is no foreseen reduction in security when using this scheme.

If an attacker could gain control of the HTTP URL, it would have no effect on the HTTPS URL, since the HTTP URL is not ever used as an Identifier except to initiate the discovery process.

Note: This approach is still vulnerable on the very first discovery process.

Specification: http://openid.net/specs/openid-authentication-2_0.html#anchor45

Answer 2

Yes. I suspect that anyone who could MITM StackExchange <-> your website (which may, e.g., have a self-signed cert) would be able to insert an alternative OpenID delegate (into the index.html) and use that to break into your StackExchange account.

Answer 3

What is the delegate URL you use? HTTP or HTTPS?

When you click on the OpenID provider for Google or any of the preconfigured OpenID sites, you are redirected to a HTTPS site.

Only one OpenID provider I know of deals with this scenario wonderfuly: Symantec Verisign PiP Labs. Once you log in you have the option to DENY all initial authentication created by a redirect. Instead, they ask that you login directly to pip.verisignlabs.com and then navigate to Stackoverflow and login.

Answer 4

The problem with this is that each login initiates the new HTTPS request, which is very slow. It is absolutely very slow. But if done right with HTTP/1.1 with keep-alive connection persistence, it's not, so it's just pure laziness of the developers... "who needs ssl for authentication"? :-)