[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
- To: "Airey, John" <john.airey@xxxxxxxxxxx>
- Subject: Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
- From: Kevin <KKadow@xxxxxxxxx>
- Date: Tue, 26 Oct 2004 23:34:15 -0500
On Tue, 26 Oct 2004 16:47:21 +0100, Airey, John <john.airey@xxxxxxxxxxx> 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