full-disclosure - Possibly a stupid question RPC over HTTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6ec88adc04102621347b38883b@mail.gmail.com>
From: KKadow at gmail.com (Kevin)
Subject: Possibly a stupid question RPC over HTTP

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