Re: Bruce Schneiers CRYPTO-GRAM February 15, 2002

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 Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]