[OpenID] Bug in OpenID RP implementations

Fri Jan 2 22:26:44 UTC 2009

Since Pat mentioned inducing an OP to POST back large assertions, I thought I'd try it: myopenid to foundation membership signup site (I gave up on trying it with pbwiki; their RP code is just not resilient enough, yet). I mixed that experiment with one addressing "the SSL CA trust issue during discovery".

While rendering the HTML shown below, the IE browser briefly shows the "Please click..." message, as if javascript is not enabled. (It is enabled.) Click or don’t click, things don’t proceed as you'd expect. This just feels like a programming bug on the RP site.

Now while that is just a bug, it happened to be induced while experimenting on topic.

I had the homepw.myopenid.com OP send a properly-formatted (url-encoding of a pem-encoded) SSL server cert using an assertion (which more ideally would be present in an unsolicited AX attribute, rather than a source route in an email address).

The idea was, __henceforth__ during discovery (only), that the particular RP would be willing to work with any all https servers that it encouters, whilst trundling along a 302 redirect sequence (starting at e.g. https://cacert.at/homepw), providing that their server cert's are registered to at least
"someone" (anyone) -- whose account has been previously linked by openid.

Rather than reject such an https server for discovery purposes (because the host OS doesn’t happen to know that CA or server cert), the openid would "provisionally" accept the SSL server certs and the implied https naming assertions .... until final discovery URL is computed. Providing the sequence of https 302 redirects finalize at the final discovery URL for known & registered openid, and providing that any server certs used in the 302 redirecting process are listed at the SP bound to that verified openid, then go ahead and perform openid authentication.

All this is doing of course is using openid assertions to populate - at one or more RPs - the user's own CTL - certificate trust list. A CTL cannot be done delivered using (unsigned) XRDS (since that’s what discovery is trying to read), but can be done by (i) pre-population of a per-openid CTL (ii) letting openid discovery recognize __user-certified__ discovery "paths".

Which all seems very UCI.

In implementation terms, most if not all SSL libraries use call backs to app code intending them to deal matters of PKI trust "on an application basis". Rather than continue to do the ostrich with head in sand act, hoping the OS SSL will sort life out matters of trust, the discovery code in Openid libraries could be facilitating CTL formulation/usage. (Windows already does cross-cert locators, CTLs, and OCSP override locators wonderfully; so more advanced PKI, with trust models tuned PER APPLICATION OF SSL, CAN be done, and at least on Windows library support is all there, just waiting to be leveraged.)

Peter

HTTP/1.0 200 OK
Date: Fri, 02 Jan 2009 21:44:08 GMT
Server: Apache/2.2
Content-Length: 4255
Content-Type: text/html; charset=UTF-8
Set-Cookie: ephemeral_session_id=c98fba73eab3402908940288c079735cc108e653fd9c3cef0d37f41363303a36; domain=myopenid.com; path=/; expires=Fri, 16-Jan-2009 21:44:08 GMT
Set-Cookie: secure_session_id=f1815276a6509a121aeab34b4e5e340c074779e27cb6e941c978da4e8ae81707; domain=myopenid.com; path=/; secure; expires=Sat, 02-Jan-2010 21:44:08 GMT
Set-Cookie: browser_id=9ab66f1106412ef6eab85611f5d93a393de35921dcac82d02445a6ec3b2c2e78; domain=myopenid.com; path=/
Set-Cookie: session_id=485ae27f1c65c5003034c08ae1bcdec3c7f90cff0349456e757099a74731033d; domain=myopenid.com; path=/; expires=Sat, 02-Jan-2010 21:44:08 GMT
Connection: close

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html>
  <head >
    <base href="https://www.myopenid.com/" />
    <title></title>
  </head>
  <body onload="document.forms[0].submit();"
>
    <script type="text/javascript">
      if (top != self) top.location.href = 'https://www.myopenid.com/trust?_=%2A9ab6-3548-37a5&tid=9b9f5a73&token=3da055d53976eb9598beee419c1ddd6f00000000000f2a09';
    </script>
<p>
Please click <b>Continue...</b> to continue your request.  To avoid seeing this message in the future, you should enable JavaScript in your browser.
</p>

<form accept-charset="UTF-8" action="https://signin.openid.net/openid/finish?token_url=https%3A%2F%2Fopenid.net%2Ffoundation%2Fmembers%2Frpx" enctype="application/x-www-form-urlencoded" method="post"><input name="openid.op_endpoint" type="hidden" value="http://www.myopenid.com/server" /><input name="openid.sig" type="hidden" value="IceBKhtEOzCqWGvwKQzfkj7QMok=" /><input name="openid.ns" type="hidden" value="http://specs.openid.net/auth/2.0" /><input name="openid.return_to" type="hidden" value="https://signin.openid.net/openid/finish?token_url=https%3A%2F%2Fopenid.net%2Ffoundation%2Fmembers%2Frpx" /><input name="openid.claimed_id" type="hidden" value="http://homepw.myopenid.com/" /><input name="openid.ns.sreg" type="hidden" value="http://openid.net/extensions/sreg/1.1" /><input name="openid.sreg.nickname" type="hidden" value="peter" /><input name="openid.response_nonce" type="hidden" value="2009-01-02T21:44:08ZGiB9Qp" /><input name="openid.signed" type="hidden" value="assoc_handle,claimed_id,identity,mode,ns,ns.sreg,op_endpoint,response_nonce,return_to,signed,sreg.email,sreg.nickname" /><input name="openid.assoc_handle" type="hidden" value="{HMAC-SHA1}{49590c24}{WZK5Gg==}" /><input name="openid.mode" type="hidden" value="id_res" /><input name="openid.identity" type="hidden" value="http://homepw.myopenid.com/" /><input name="openid.sreg.email" type="hidden" value="home_pw%https%3a%2f%2fxri.net%2f*pki*%3d-----BEGIN+CERTIFICATE-----%0d%0aMIIFVzCCAz%2bgAwIBAgIDBTfsMA0GCSqGSIb3DQEBBQUAMHkxEDAOBgNVBAoTB1Jv%0d%0ab3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ%0d%0aQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9y%0d%0adEBjYWNlcnQub3JnMB4XDTA4MDUyMDE1NTI0NVoXDTEwMDUyMDE1NTI0NVowfjEL%0d%0aMAkGA1UEBhMCQVUxDDAKBgNVBAgTA05TVzEPMA0GA1UEBxMGU3lkbmV5MRQwEgYD%0d%0aVQQKEwtDQWNlcnQgSW5jLjEXMBUGA1UEAxMOd3d3LmNhY2VydC5vcmcxITAfBgkq%0d%0ahkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQAD%0d%0aggEPADCCAQoCggEBAM3iqo3YIRO2BaAEEoZ%2fUi8efBtl44PlQO71ubOvhc7lMU%2fW%0d%0aSC%2fVuw36z6O8WwvX2Lgx2gwYwJ94JvyHCAmNNQc0ohHHk7jNOeOieJKBX3kwCPnQ%0d%0aSPQJpIZwR6gcpDsblEHADjq0Qugjdn5RTAg1v65xd8Y4yoalkETgtrncTZ1fkhpg%0d%0aAVEYcx38JeLL3IHoDgTQH%2bM29XyIN2NJEnClkdoGftZlPCKEvd36T%2fkl6vrEm0Vy%0d%0aZV9orUAKG116J%2bIwn%2bqFSgiz40gtDrpz9raEyixM72DqfY%2f4Gmgs1LrN19LEPu7u%0d%0aIGvs%2fV8FqZ5twpfdctZq0iaq9fIGvWa1q9quvC0CAwEAAaOB4jCB3zAMBgNVHRMB%0d%0aAf8EAjAAMDQGA1UdJQQtMCsGCCsGAQUFBwMCBggrBgEFBQcDAQYJYIZIAYb4QgQB%0d%0aBgorBgEEAYI3CgMDMAsGA1UdDwQEAwIFoDAzBggrBgEFBQcBAQQnMCUwIwYIKwYB%0d%0aBQUHMAGGF2h0dHA6Ly9vY3NwLmNhY2VydC5vcmcvMFcGA1UdEQRQME6CDCouY2Fj%0d%0aZXJ0Lm9yZ4IKY2FjZXJ0Lm9yZ4IMKi5jYWNlcnQubmV0ggpjYWNlcnQubmV0ggwq%0d%0aLmNhY2VydC5jb22CCmNhY2VydC5jb20wDQYJKoZIhvcNAQEFBQADggIBABjbtGob%0d%0a4GSzxFLeOEAoBl6Znt0Dk2VhsZv6IrdvcpSrhnnHvPDRXi%2bls9mwOkRT4M%2b2E3L9%0d%0aIQhMfGMveB5Nf1pfLk%2bAPCQUjVNVe7kZrxsJ18YnjqPYM3hYi3Sr96U2ixNvIGi%2b%0d%0aVaBvx1FoxHdFyKF3k2eApVWngJnCxwk%2fN4QRFP6OGeimLlPAYhw0R6SBOyPdyx3g%0d%0aL6NMDOUi9%2frz7cCNzlC8oW3Wy9VpFZh2jDTTve0JouG9%2fY8T2CFJWyrneeajecNZ%0d%0a6QLD52O2TOQRgi2Ym31J3%2brxx3Ujep85FcC4mawwweYnU6LqQ032GuWbRU9p9Oqv%0d%0aWF4ZOOnLy2ZaQdfMRBZ7dy6Dhrj8tkOjNSC4MmJDDXL0lVo0HTCo1TDVMUWIIDaK%0d%0aBZd7%2bwyoR5SXUcsuKxXGKWm9CITNFCYZttPtwtS1yH8p5YNdfhkNlr4jscWDAL2g%0d%0agLEEyRraAYjUh6Uot7mmXM2%2bIgwJX1DrS39bWghqk0gRXrkvhtx18R08dnZDJZaV%0d%0aghynZb6PSFRXYLMOqb9Uzf8%2fre6iWXwUKbzUcT1ZL4spZktfvaCUQP9YqZVYfhJ7%0d%0aXXymJqnCuXpMxzMTxbvq6zROqyRqVS%2f1hZxHhh%2fkr%2bEiNxDSkv7CJtuYVuufZkr%2b%0d%0aDBInG0zsM0C9ajuawgX3vY%2bMMbeuDTQXPcg3%0d%0a-----END+CERTIFICATE---- at msn.com" /><input type="submit" value="Continue" /></form>
  </body>
</html>

> -----Original Message-----
> From: Josh Hoyt [mailto:josh at janrain.com]
> Sent: Friday, January 02, 2009 10:04 AM
> To: Andrew Arnott
> Cc: Peter Williams; OpenID List
> Subject: Re: [OpenID] Bug in OpenID RP implementations
>
> On Thu, Jan 1, 2009 at 4:36 PM, Andrew Arnott <andrewarnott at gmail.com>
> wrote:
> > However, I don't agree with all of their decisions (AX
> > type URIs and non-https enforcement among them).
>
> The AX type URI thing is a problem that we do indeed need to fix.
>
> > Ideally, myopenid.com and all other OPs would redirect identity page
> > requests that come in on HTTP to HTTPS so that all claimed
> identifiers and
> > authentication would occur over HTTPS to provide higher security to
> users.
>
> The decisions we made regarding requiring HTTPS for identifiers were
> made because during the process of implementing and testing OpenID
> libraries as well as from library-user feedback, we encountered a
> significant fraction of environments where *client* support for HTTPS
> for use in the library was not present. As a result, we decided that
> we could not redirect all identity page requests (and thus, all OpenID
> traffic) to HTTPS without preventing myOpenID users from being able to
> sign in at these sites. The CA trust issue raised in this thread is
> another variation on this problem.
>
> This presents us with another major problem, which is that even if we
> do start redirecting identity page requests to HTTPS, we can't do it
> for existing identifiers, because the HTTP and HTTPS identifiers are
> distinct. They're distinct precisely so that we *can* derive any
> security benefit from using HTTPS at all.
>
> It's additionally problematic that we can't redirect users, because
> the vast majority of users will not know (and even if they do know,
> it's unlikely that they'll understand) that they should prefer the
> HTTPS identifier when given the choice.
>
> I hope that sheds some light on the implementation decisions that
> providers face with respect to HTTPS. I think that the situation has
> changed somewhat since our original policy decisions were made (most
> notably, relying parties now have to support HTTPS in order to allow
> Yahoo and Google OpenIDs.)
>
> Josh