Full Disclosure mailing list archives
Re: Possibly a stupid question RPC over HTTP
From: "Mark O'Neill" <mark () vordel com>
Date: Mon, 1 Nov 2004 16:52:13 -0500
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 () rnib 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 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Re: Possibly a stupid question RPC over HTTP Mark O'Neill (Nov 01)