[OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP implementations)

[Andrew Arnott]

Peter,
These are great resources.  Can you help me understand one issue that I
think I see with your initial discovery phase that you explained?

It seems to me that if during discovery the RP is required to (temporarily)
accept SSL certs that are not signed by a known good CA, and at the end of
discovery or authentication the public keys for these certs are sent from OP
to RP so the RP can match each cert it encountered with the known good list
from the OP or identifier, (Am I understanding this correctly??) it seems to
me a wide open door for someone to DNS poison the RP, redirecting traffic to
his own server with his own certs, and his own OP which will send approval
messages for those certs.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire


On Sun, Jan 4, 2009 at 1:06 AM, Peter Williams <pwilliams at rapattoni.com>wrote:

>  CTLs are not the whole story, but are a good place to start to see where
> the security constraints in the hosted  environment are imposed by the
> hoster's core setup. It's also interesting to glimpse from the following how
> .NET has evolved the trust management framework since the IIS4 days I once
> knew well, and see how the modern ACS is going further (rant on. in ways
> that are no longer being enforced solely within the crypto boundary, relying
> more on trusted systems theory like AuthMan RBAC. rant off).
>
>
>
> I'm starting to envy Dick. This modern trust stuff looks like so much fun!
> Microsoft core platform engineering on crypto has always been classy, though
> can tend to become somewhat obscure and overly-professionalized –
> particularly as native code is mapped into the VM, as we see in the first
> resource:-
>
>
>
> http://blogs.msdn.com/gproano/archive/2005/03/22/400645.aspx (fiddling
> with CTLs programmatically in early .NET)
>
>
>
> If GoDaddy has console access,
> http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCFTransportSecurity.aspx.
> gives you a start on the core CTL ideas in an IIS context, but is obviously
> not dynamic.
>
>
>
> http://www.leastprivilege.com/SslStreamSample.aspx (lowlevel access to the
> SSL client library, presumably applying http.sys, with validation callback
> interface)
>
>
>
> WCF model on app-based certificate trust constructs
> http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCF.aspx
>
>
>
> custom validation
> http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCFMessageSecurity.aspx
> .
>
>
>
> Looks like the peer trust model may be good for an openid ID RP doing what
> I suggested (to enhance https openid discovery . It can then collect all the
> asserted certificates from an OP, and then custom validation logic binds a
> particular cert to the inbound openid, for use next time with a vanity https
> URL that ultimately resolves during discovery to that OP-provisioned openid
> (via redirect, via delegation, or whatever)
>
>
>
>
>
>
> http://www.leastprivilege.com/FederatingWithLiveIDUsingTheAccessControlService.aspx(modern clue on how folks MAY? address the issue of trust in a .NET host (of
> which IIS7 is only one option, recall). See notion of ACS. Only relevant to
> the distant future tho. Will probably be highly relevant to OP/RP
> white-listing too, tho.
>
>
>
> *From:* general-bounces at openid.net [mailto:general-bounces at openid.net] *On
> Behalf Of *Andrew Arnott
> *Sent:* Saturday, January 03, 2009 7:06 PM
> *To:* Peter Watkins
> *Cc:* general at openid.net
> *Subject:* Re: [OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP
> implementations)
>
>
>
> On Sat, Jan 3, 2009 at 4:34 PM, Peter Watkins <peterw at tux.org> wrote:
>
>
> Can't you "just" add the CAs to trusted roots for the Windows account
> that the asp.net app runs as?
>
>
>
> Not while that ASP.NET app is running with medium trust.
>
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - Voltaire
>
>  On Sat, Jan 3, 2009 at 4:34 PM, Peter Watkins <peterw at tux.org> wrote:
>
>
> Can't you "just" add the CAs to trusted roots for the Windows account
> that the asp.net app runs as? I supposed it'd be tougher for folks
> using integrated auth & impersonation, but I also expect most asp.net
> webapps doing OpenID auth aren't using impersonation. Similarly, I'd
> expect to be able to remove CA certs from the asp.net webapp user's
> profile in order to shorten the CA whitelist.
>
> I don't know how tough it is to edit the root certs for the profiles of
> app pool-type accounts, and hope you'll forgive my not firing up
> Studio on a Saturday night to see if there's an obvious API. :-)
>
> On *nix it's usually pretty straightforward -- find the keystore
> holding root certs and manipulate it via OpenSSL, Java keytool,
> or whatever app is appropriate for the environment. Is it not the
> same in Windows?
>
> -Peter
>
>
> On Sat, Jan 03, 2009 at 03:24:37PM -0800, Andrew Arnott wrote:
> > Definitely some interesting thoughts in there.
> > I'll add one more: while it makes a sensible default for Microsoft to
> cause
> > .NET connections to HTTPS servers without a signed cert by a known good
> CA
> > to fail, it doesn't seem like it should require the whole machine to
> trust
> > the individual web site if that web site wishes to go ahead and make a
> > connection.  Crying out loud: if a partial trust web site can initiate an
> > HTTP connection to a random server (which it can, with GoDaddy's small
> > deviation to Medium Trust), why couldn't it also open an HTTPS connection
> in
> > order to encrypt the traffic, and decide to be its own judge on the
> validity
> > of that certificate?
> >
> > I'm going to poke around Microsoft and see if I can't get this policy
> > changed so that .NET clients can approve of these certs signed by
> > lesser-known CAs.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090104/65196248/attachment-0001.htm>