From: Lisa Dusseault (lisa@xythos.com)
Date: Mon Oct 02 2000 - 18:26:40 PDT
Well then, my thoughts:
Half of this is solved by CONNECT. As I'm sure Rohit is aware, CONNECT can
be used to tunnel a client through their own firewall (by "own", I mean a
client inside a typical corporate firewall run by the user's company's
administrators). It was intended to allow SSL traffic, but it's way cooler
than that. If you can SSL to secure servers such as amazon's, I believe you
can use CONNECT almost anywhere -- and once you CONNECT, you don't have to
start SSL, and the firewall can't tell. I doubt many firewalls even
enforce that you have to CONNECT to port 443. So, your example of using
CONNECT from the IRC client to the EFNET server might be solved by this. In
general, any public server, one with public services, isn't protected by
their own firewall, so it works. Clients that use DAV sometimes take
advantage of this to be able to send those wierd-o DAV HTTP methods over
silly firewalls that think they know all the "proper" HTTP methods that
ought to be used.
Now, it's true that you can't come in out of the Internet with CONNECT. I
can't set up this machine to be an identd server that accepts connections
from the world, without going and getting the firewall administrator to poke
an identd-sized hole in the firewall. Firewalls sensibly don't allow just
anybody to tunnel from the Internet to one of their machines for just any
reason. Even if some servers at a site support CONNECT, it's usually a
limited list -- for very good security reasons. Opening a hole in your
firewall for CONNECT would be a very, very big hole. Some disgruntled
employee could post all your source code (not that there aren't easier ways
to do that), but even worse, there might alredy be a publicly-readable share
of the source code, only protected by being behind the firewall. Hackers
could find publicly-writable shares inside the company and put nasty, nasty
stuff on them. Etc, etc.
So, SUDS could be very dangerous if it allowed arbitrary traffic to
arbitrary points, but at least it sounds as if the endpoints of traffic are
SUDS agents. If that's true, and if SUDS agents are well-sandboxed (ha!),
well, it might be livable, security-wise. Not worse than email viruses,
anyway.
Of course you'd have to masquerade SUDS as HTTP (as SOAP has done) in order
to be able to get that connection out in the first place. And, it probably
wouldn't be very real-time, would it? But I'm sure some useful services
could be done that way, identd being a particularly good example.
Lisa
> -----Original Message-----
> From: Jeff Bone [mailto:jbone@jump.net]
> Sent: Monday, October 02, 2000 2:16 PM
> To: Lucas Gonze; FoRK@XeNT.CoM
> Subject: SUDS: the SOAP Universal Delivery System
>
>
>
> Okay, here's a basic sort of stream-of-consciousness description
> of this thing I've been
> pondering for a long while. Assume the following: HTTP is the
> universal transport,
> SOAP is the universal RPC, and firewalls are a "problem" in that
> it cannot be assumed
> anywhere that an initiator will be able to establish an HTTP
> stream to a desired service
> somewhere else. How can you ever build systems where clients
> (initiating peers) can
> initiate contact with desired services, regardless of the
> location of the service, i.e.
> across a firewall?
>
> Enter SUDS. SUDS is basically the thing I described in the last
> message: a service
> which provides a URL namespace rooted at some well-known location
> and allows its own
> clients (the desired services mentioned above) to adopt subtrees
> within that namespace
> via its own SOAP-based control interface. Imagine it as a sort
> of dynamic, web-based
> inetd meets web proxy with connection management semantics layered on top.
>
> Scenario: my IRC client wants to connect to an EFNet server, but
> the servers refuse
> connection because the server cannot connect across my firewall
> to the identd on my
> desktop. Imagine for a moment that identd is actually some kind
> of identd-like SOAP
> user authentication service for the purposes of this discussion,
> and imagine that IRC
> knew how to use SUDS. Here's what happens:
>
> My "identd" registers itself with some SUDS service somewhere,
> say http://suds.foo.com,
> and adopts a portion of the tree:
jbone@jump.net/identd">http://suds.foo.com/jbone@jump.net/identd or
similar. This SUDS service is outside my firewall, so my identd maintains
an open
connection to the SUDS service or periodically polls the service to see if
any inbound
connections / requests are pending. (In the case where the SUDS server can
initiate
inbound connections to my client, such as if the SUDS service was running on
the
corporate firewall, the SUDS server will make on-demand connections to my
client as
needed and neither persistent connections or polling are necessary. Or, in
the case
where the service provider and requester can directly communicate, the SUDS
service can
simply act as a referrer; in that case, SUDS merely acts as a symbolic
nameservice and
provider of well-known names.)
My IRC client connects to the EFNet server and provides my information, with
authentication information, along with the SUDS address of my identification
service.
EFNet contacts the indicated SUDs server, which then "connects" my identd
service at the
provided SUDS address with EFNet. The SUDS server brokers this connection
between my
identd service and the EFNet server and basically just proxies things back
and forth at
that point.
Different services registering with SUDS, as well as different SUDS servers,
could
support a variety of differing connection semantics to support a variety of
cases:
persistent connection, polling, queued SOAP messages with return addresses,
event
notification, SUDS-initiated callbacks to the service, etc.
Any thoughts about this?
jb
This archive was generated by hypermail 2b29 : Mon Oct 02 2000 - 18:37:15 PDT