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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
