[Security] Channels and MITMs

Dave Cridland 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.

No.

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.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


More information about the Security mailing list