Re: Possibly a stupid question RPC over HTTP

[Kevin <KKadow () gmail com>]

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