[Security] Channels and MITMs
dave at cridland.net
Wed Aug 20 08:29:20 CDT 2008
On Wed Aug 20 13:14:00 2008, Johansson Olle E wrote:
> 20 aug 2008 kl. 12.50 skrev Dave Cridland:
>> For the record, I'm saying that we, here, don't need to care at
>> all about NAT traversal because this problem is either solved, or
>> else needs to be solved by Jingle and not by us and not here.
> Well, if you want end to end TLS, there's some architecture
> examples that will be affected by a middle man. Take the example
> of the OTR "proxy" :-) I mentioned earlier. No one really
> bother to check the OTR fingerprints, so they would not discover
> the proxy, unless the client reacted the way my ssh client reacts
> to a new key fingerprint.
> You need to be aware of this when designing a solution. Requiring
> TLS encryption of the stream after connection setup won't really
> be affected as much as using the TLS connection certificate/keys,
> where a middleman can
> present a different set of keys.
Whether you're using IBB, ICE-TCP, plain TCP, or avian carrier, the
TLS endpoints always have to be the channel endpoints, otherwise you
have an MITM.
But the channels themselves will almost certainly be carried over a
multihop path, and just like TLS is usually carried in a single TCP
channel over many IP hops with routers passing each packet, MITMs
aren't really MITMs unless they're actually manipulating the data
within the logical channel, or pretending to be the remote endpoint.
If they're not, then we really don't care about them.
My point is that whatever happens, we need to assume the presence of
an end-to-end logical reliable channel, but that how that gets setup
is really not our problem to solve.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Security