[Twisted-Python] SSL + AMP

[Drew Smathers]

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?

-- 
\\\\\/\"/\\\\\\\\\\\
\\\\/ // //\/\\\\\\\
\\\/ \\// /\ \/\\\\
\\/ /\/ / /\/ /\ \\\
\/ / /\/ /\ /\\\ \\
/ /\\\ /\\\ \\\\\/\
\/\\\\\/\\\\\/\\\\\\
 d.p.s