[Twisted-Python] SSL + AMP
Drew Smathers
drew.smathers at gmail.com
Thu Mar 20 16:39:36 EDT 2008
On Thu, Mar 20, 2008 at 4:38 PM, Drew Smathers <drew.smathers at gmail.com> wrote:
>
> On Thu, Mar 20, 2008 at 3:45 PM, Brian Warner <warner at lothar.com> wrote:
> > On Wed, 19 Mar 2008 20:14:09 -0600
> > Nathan <nathan.stocks at gmail.com> wrote:
> >
> > > The security properties that I want are:
> > >
> > > 1) My client and my server refuse to establish SSL (or any other type
> > > of) connections with anybody but each other.
> > > 2) My client and server do establish SSL connections with each other.
> >
> > For reference, this is almost exactly what Foolscap does. The server
> > registers an object and gets back a "FURL" which contains two cryptographic
> > values: the hash of the SSL certificate, and the per-object secret. You give
> > this FURL to the client by some out-of-band means (paste it into a config
> > file, perhaps). Then the client connects to the server over SSL, verifies the
> > certificate hash, sends the secret, and gets back a reference to the object.
> >
> > The client will refuse to use any connection that has a different SSL
> > certificate. It will also refuse to use a non-SSL connection.
> >
> > The part where the capability-oriented Foolscap model differs from your
> > stated properties is that the server makes no attempt to distinguish between
> > various clients. Any client which knows the FURL will be granted access to
> > the object that you've registered. To accomplish both of your goals, simply
> > don't reveal the FURL to anyone but your desired client. Unauthorized clients
> > will be able to make an SSL connection to the server but they won't know the
> > object secret and will be unable to access the object.
> >
> > If you use Foolscap, you'll be working with objects and remote method calls,
> > rather than the single-endpoint model that AMP uses. This may be more
> > flexibility than you really need, but if you only publish one object and
> > always call a single method (perhaps called 'dispatch'), then you can program
> > in the same style. Of course, when you want to use multiple objects, pass
> > arbitrary reference graphs in arguments and responses, or allow third-party
> > introductions, Foolscap will be ready for you :).
> >
>
> Now that foolscap has been brought up ... since foolscap doesn't try
> to poke through firewalls, there seems to be some deployment issues
> when using this in say an MMO where you can't guarantee that
> participants in the system will be able talk to each other directly
> without tunneling through a central server. The way foolscap works
> (if I understand correctly), a server A can introduce a client B to C
> by passing B the FURL to some object hosted in B's tub. Is it sane
> the best way to handle the scenario when B and C can't establish a
> connection to each other (one or both are behind a NAT), but both
> trust A to make a proxy reference to the other on the server and
> simply route the conversation. Does foolscap already support such
> fall-back behavior for coping with firewalls? Or does that break the
> security model?
>
Woops, correction:
"server A can introduce a client B to C by passing B the FURL to some
object hosted in C's tub"
--
\\\\\/\"/\\\\\\\\\\\
\\\\/ // //\/\\\\\\\
\\\/ \\// /\ \/\\\\
\\/ /\/ / /\/ /\ \\\
\/ / /\/ /\ /\\\ \\
/ /\\\ /\\\ \\\\\/\
\/\\\\\/\\\\\/\\\\\\
d.p.s
More information about the Twisted-Python
mailing list