XAuth critiques

[John Panzer]

On Tue, Jun 8, 2010 at 4:05 PM, SitG Admin
<sysadmin at shadowsinthegarden.com>wrote:

>  >(2) If an eavesdropper can listen in on all your network traffic, can't
> they see your HTTP requests to IdP and RP (and everything else) directly?
>
> Even setting aside the IP address versus sniffing request strings versus
> sniffing responses too, you've blanked out here on the idea of "Assume that
> ALL requests are protected with SSL" - it's one thing to be blind to
> anything which would contradict your favored belief, but when it starts to
> affect your logical faculty in other areas, you seriously need to take a
> step back and detach.
>

I think I must be misunderstanding what you said, then.  You said:

"Assume that ALL requests are protected with SSL, so that the contents of
communications cannot be spied upon. An eavesdropper can STILL figure out
when a user is logging in with OpenID (and, with attention to timing, WHICH
sites they are logged in to!) by looking for requests to the IP address of
the central server."

Given that all requests are protected by SSL but you can eavesdrop, you have
the IP addresses, the timestamps, and some notion of the size of all the
requests.  This applies both to traffic to xauth.org and to all other
servers, or at least that was my assumption ("If an eavesdropper can listen
in on all your network traffic...").  So you already know the IP addresses
and timestamps of TCP connections to all of the servers the victim is
talking to.  Presumably you also have a list of the IP addresses of commonly
used IdPs or can figure it out after the fact, so you know when the victim
visiting your IdP (or their browser is being redirected).  You can probably
infer when RPs are doing said redirects and what the RPs are.

Is this the scenario you're envisioning?  If so, I'm having trouble seeing
how some additional once-per-year cache revalidation requests to xauth.org's
IP would change the amount of information leakage in any appreciable way.
 Otherwise, could you please give some more details about the attack you're
proposing?

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100608/d8daffac/attachment.html>