Re: [tor-bugs] #5578 [Flashproxy]: Investigate WebRTC for flash proxy NAT punching

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#5578: Investigate WebRTC for flash proxy NAT punching
----------------------------+-----------------
     Reporter:  dcf         |      Owner:  dcf
         Type:  task        |     Status:  new
     Priority:  normal      |  Milestone:
    Component:  Flashproxy  |    Version:
   Resolution:              |   Keywords:
Actual Points:              |  Parent ID:
       Points:              |
----------------------------+-----------------

Comment (by dcf):

 Replying to [comment:24 infinity0]:
 > Continuing from the above, the following option probably would not
 require any changes to the ICE authentication code, nor the facilitator to
 have another certification key (nor to use the existing encryption key for
 certification) - but it does assume the existence of a fully-known
 confidential channel between the facilitator and the browser proxy (i.e.
 not SSL with x509).
 >
 > 1. the client, L, generates a secret key K(R) and sends it to the
 facilitator in an encrypted client registration. this means only the
 facilitator can read K(R).
 > 2. when the facilitator picks a proxy, R, to serve L, it gives it K(R)
 via the confidential channel. now only the facilitator and the proxy can
 read K(R).
 > 3. R then uses K(R) as the authentication key for ICE as normal. no
 changes to normal ICE authentication are needed.
 > 4. L assumes that the facilitator works honestly, and that no-one else
 can read K(R) in transit, due to the confidential channel.
 >
 > edit: thinking more about it, in the current system it's not so
 necessary for K(R) to remain fully-known confidential, since we're not
 assuming anything about the behaviour of proxies. they could be malicious,
 and they could be MITMd and replaced by an adversary. so, the above
 sequence is only really needed "for show" to be compatible with what ICE
 expects.
 >
 > (it may become more relevant if we ever track the behaviour of proxies
 in some future reputation system, but such a system would require the
 solution of this problem anyway.)

 Thanks for finding these links. I'm beginning to understand better. The
 key exchange you describe seems reasonable on first reading.

 Can signalling be done as a single request/response? If so, we might be
 able to build it into appspot rendezvous.

 It may also be fine to use whatever signalling and ICE channel is used by
 Google hangouts, or whatever is the most common user of WebRTC.

 I don't know what you mean by "fully-known confidential channel."

 A good first goal would be to have two C++ programs that are capable of
 chatting with each other, after being given an offer and answer manually.
 That can serve as a basis for the client and server transport plugins. We
 can use it to test our ideas as we work out the details of signalling.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5578#comment:25>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs