Message-ID: <4186519900000811@mailserve.vordel.com> (added by postmaster@vordel.com)
From: mark at vordel.com (Mark O'Neill)
Subject: Possibly a stupid question RPC over HTTP

Moving sideward from the specific case of Microsoft's RPC-over-HTTPS to the
case of XML-over-HTTPS used for Web Services, here are some thoughts from
the "Web Services Security" world:

I find that people start from a standpoint of thinking "firewalls are
oblivious to XML" but then realize that a far more frightening issue is that
"firewalls are oblivious to any encrypted data that's being sent over
HTTPS", i.e. exactly what's being discussed here. And the SSL issue must be
addressed before you look for threats inside the XML. The knee-jerk solution
is usually to terminate the SSL at an "XML Firewall" and then ignore the
security from the "XML Firewall" to the endpoint which is consuming the XML.
This creates a "last mile" problem and obviously does not block an attacker
who simply who do not go through the "XML Firewall". It also means storing
policies out in the DMZ, and synching them up between many "XML Firewall"
instances, if you have more than one.

As I see it, there are two architectural solutions to this problem. 

Option One is to terminate the SSL at the "XML Firewall" and then, following
authentication and content-inspection of the XML, to insert a security token
into the XML which identifies the client which you've just authenticated.
The XML, plus the embedded security token identifying the authenticated
client, is then passed to the endpoint. SAML and WS-Security are perfect for
this, or else you can put the client identity (e.g. Distinguished Name) into
a HTTP header as many load-balancers/SSL-terminators do today. SSL is then
used to encrypt the connection from the "XML Firewall" to the "Web Service"
endpoint itself. At the endpoint, you can the native capabilities of the Web
Services platform to consume the security token, or you can embed an "Agent"
in there to validate (check the integrity) and verify (check the trust) the
security token against a central "Security Server" that acts as a Policy
Decision Point (as in RFC 2753).

Option Two is to not put an "XML Firewall" in place and to just embed the
"Agent" after the SSL terminator takes place at the Web Services endpoint
itself. In this case, you are relying on your existing network firewall to
detect and block traditional "flooding" DoS attacks from reaching the Web
Services endpoint, and the "Agent" is taking care of the XML validation (is
it the right format and does it contain threats?) and verification (do we
trust the sender?) by connecting to a central "Security Server" which does
the policy decision making (RFC 2753 again). The "Agents" may be on machines
which are in the line of fire in the DMZ, but the Security Server should not
be, and should be on a non-routable subnet behind NAT.

I've written about this in this Java Pro article ("Architecting Security for
Web Services")
http://www.ftponline.com/javapro/2003_08/magazine/features/moneill/
And in this book ("Web Services Security")
http://www.amazon.com/exec/obidos/tg/detail/-/0072224711

A bit of full-disclosure now: I'm from a vendor (Vordel) which has software
which implements the above functionality (XML Firewall and XML Security
Server with Agents) but I hope that the principles are generic enough to
apply outside of our own customers.

-Mark

Mark O'Neill
CTO, Vordel
www.vordel.com
weblog: http://radio.weblogs.com/0111797/
 
- Entrust adds Vordel XML security products to its portfolio
  http://www.vordel.com/news/press/04_09_02.html 
- Vordel and RSA Security partner for XML security   
  http://www.vordel.com/news/press/04_07_20.html
  

On Tue, 26 Oct 2004 16:47:21 +0100, Airey, John <john.airey@...b.org.uk>
wrote:
> Therefore my point still stands that if someone does possess a
mathematical solution
to the above, then all bets are off.
> (Whoever it was who disagreed about my statements on encryption, please
remember the
context of the thread is about SSL security, not one-time keys).

Agreed.  Current SSL standards rely on public key encryption methods
which obtain their strength from the difficulty of the factoring
problem.

> Getting back to the original question, you can't discover if someone is
sending
RPC over https unless you have a solution to the RSA hard problem above. Nor
is it a major
security issue if someone is using RPC over https either, unless there are
flaws in the
implementation of SSL or RPC that could be exploited by someone else.

Yes -- however, there are workarounds.
If you control one end point or the other, then you can take steps to
permit examination of the contents of SSL sessions.

Server:
If you control the server, you can of course load the keys into the
sniffer (risky, but not unheard of, see
http://www.radware.com/content/products/ct100/default.asp)) or 
terminate the SSL session on a device under your control. (For an
RPC-over-HTTP example, see this document:
http://www.msexchange.org/pages/article_p.asp?id=613)

Client:
If you control the client (say a corporate desktop PC), you have
another option -- you can modify the clients list of trusted CAs, and
force the client to establish the SSL session to your proxy server. 
This gives the proxy an opportunity to inspect/log/modify the
cleartext contents of the session.  The proxy establishes it's own SSL
session to the remote server normally neither the client or server
would be aware of the MITM.

A freeware implementation of this MITM approach was "Achilles", I have
also seen at least one commercial product offering this functionality
to permit content-scanning of outbound HTTPS browser traffic.

Kevin Kadow

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists