[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