Re: Bruce Schneiers CRYPTO-GRAM February 15, 2002

[Daniel Veillard <veillard redhat com>]

On Fri, Feb 15, 2002 at 05:51:21PM -0500, Alan Cox wrote:
> > the problem is not in SOAP, it's in HTTP being allowed without further
> > testing. Actually a firewall administrator has an easier control over
> > a SOAP messages crossing the interface than over say Javascript embedded
> 
> Unfortunately everyone uses HTTPS to prevent this, and while http/https
> were designed right conceptually, there are no IE or mozilla modules to
> support the https sessions being driven the proxy not the browser and
> using a single authenticated session to the trusted proxy

  If the firewall is the point of control, HTTPS can be blocked there,
it's a matter of policy. If not then you have to rely on the hosts behind
to be secure to HTTPS access, and deployement of such a browser is inadequate.
Of you get the browser and firewall/proxy to cooperate like you suggest
which like in SOCKs require specific tuning of all installed software.

  At that level it's an application issue too. If your browser exports
an RPC entry point, be it encoded in SOAP, JAVA, Javascript, whatever...
without means to control the RPC access or the sandbox it shall be running
in, then your browser is broken too.
  SOAP is the encoding mechanism for the RPC, not the transport layer. 
The exact same thing could be argued against for any kind of RPC serialization
I'm pretty sure tunelling DCE-RPC over HTTP(S) is possible.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/