Thanks for the replies to my query. If you'll bear with me here, I want to
test my overall understanding and discuss this in a bit more detail.
Scenario: Corp A builds or acquires a new distributed application "Z". Corp B
enters into some sort of relationship with Corp A (as a customer, supplier,
partner, subsidiary, etc.) where it will run a chunk of app "Z" on its net
behind its (external) security perimeter (defined at least in part by
firewalls).
| |
| Internet |
Corp A | | Corp B
| |
| |
| |
+---------------+ | | +---------------+
| System J |<===================================>| System K |
|(part of app Z)| | "X protocol" | |(part of app Z)|
+---------------+ | | +---------------+
| |
| |
| |
| |
| |
A's Security B's Security
Perimeter Perimeter
| |
| |
+---------------------------- Span of App "Z" -------------------------+
Now, app "Z" uses some protocol, named "X" say, to communicate between its
component(s) behind Corp A's security perimeter and those behind Corp B's
security perimeter. And protocol "X" is something that up to now has not been
permitted (neither via pass-through nor via proxy) across either Corp A's or
Corp B's security perimeters.
There is a perception among various industry players who are working on
creating such cross-organizational (read: cross administrative domain)
applications that having an app such as "Z" require alterations
to (especially) Corp B's (i.e. the partner, supplier, or customer, etc.)
security configuration will severely impede such app's deployment or even its
purchase (i.e. if one vendor's app requires such security cofig mods, and
another vendor's app "just works"). See [1] (subtitle "Firewall Woes") for
some evidence of this perception.
I'm trying to get a sense for how reasonable or unreasonable this perception
is, from the security administrators' perspectives. For example, if app "Z"'s
vendor typically sells into customers at the CIO level, and CIO types tend to
ask their security administrators for their opinion on such new systems (e.g.
App "Z"), and value those opinions, and security admins are willing to
re-evaluate and evolve their configurations, then the claim that using HTTP as
a protocol substrate carries less weight.
But, if the in-house champions of something like app "Z" tend not to be able
to cooperatively work with security admins (or that interaction is "too
expensive"), then they will arguably lean more towards deploying stuff, and/or
participating in arrangements such as depicted in the figure above, that
mitigates their need to enlist their security admins' cooperation.
So, from your perspectives, what's it like in your shops?
I interpret from these comments..
"Bill Royds" <[EMAIL PROTECTED]> said:
> If a protocol has a well defined syntax and semantics that allow full
> control by the client of an activity in the protocol, then there is
> little risk of using it over a well-defined TCP port. If I can write a
> proxy program for the protocol that can guarantee that all
> transactions using the protocol act in a secure well defined manner,
> then using a standard TCP or UDP well-known port is much more
> efficient and easier than trying to embed it in HTTP.
[EMAIL PROTECTED] said:
> The real issue is not whether or not it runs on one port although that
> is much easier for a firewall admin. The issue is whether or not the
> protocol, itself, is secure and is there a reasonably good proxy for
> that protocol to enforce the rules the protocol is suppose to follow.
..that having proxy support (in perimeter security systems) for a given
protocol, such as "X", is desirable. What if some folks in your company come
to you wanting to deploy an app such as "Z", using new protocol "X" which
doesn't yet have off-the-shelf proxy support? Is that necessarily a
showstopper (from your perspective)? Would folks be willing to roll their own
proxy (at least to get going) as Bill hints? Or might early deployment trials
and phases be run over an open pass-through port, with proxies being
incorporated as such support for protocol "X" emerges?
An alternative scenario for the builders of app "Z" is is to use HTTP as a
substrate for protocol "X", such as SOAP [2] does -- with the tacit
expectation that the deployers of app "Z" will not be obliged to interact as
closely (or at all) with their security administrators.
But, as mentioned in [2a], SOAP uses an explicit HTTP request header field
("SOAPAction") which one can use to filter SOAP traffic out of HTTP streams.
So, it seems to me, layering app protocols such as "X" on SOAP-over-HTTP isn't
necessarily a panacea for "going through firewalls" -- those of you who're
running HTTP proxies will likely easily notice SOAP going through port 80,
though in {some | many?) cases you'll have to configure stuff to explicitly
look for it (yes?).
thoughts?
thanks,
JeffH
-----
[1] SOAP: The Simple Object Access Protocol, Aaron Skonnard
http://msdn.microsoft.com/library/periodic/period00/soap.htm
[2] Simple Object Access Protocol (SOAP) 1.1
http://www.w3.org/TR/SOAP/
[2a] 6.1.1 The SOAPAction HTTP Header Field
http://www.w3.org/TR/SOAP/#_Toc478383528
-----
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
