[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9022 [Pluggable transport]: Create an XMPP pluggable transport
#9022: Create an XMPP pluggable transport
---------------------------------+------------------------------------------
Reporter: asn | Owner: feynman
Type: task | Status: accepted
Priority: normal | Milestone:
Component: Pluggable transport | Version:
Keywords: | Parent:
Points: | Actualpoints:
---------------------------------+------------------------------------------
Comment(by feynman):
I updated the protocol spec here:
https://raw.github.com/aeftimia/hexchat/master/doc/protocol-spec.txt
There is still work to be done.
JIDs are often given random strings for their so called "resources" (or if
a resource is requested, a random string is often appended to it). To send
an IQ, one must know the recipient's resource. This is great for security,
but bad for this particular application. To get around this, I use a
message (which can be sent without a resource) to send a connection
request to a JID with an unknown resource. When the recipient responds,
thus disclosing their resource, their full JID (including the resource) is
added to a table that keeps track of JIDs and resources.
The problem is if one of the computers disconnects and reconnects, they
acquire a new resource and their is no way (currently) for the other
computer to update its table.
Another problem is that messages that have no resource specified can only
be sent to people on your contact list. Thus, I may have to carry on with
the multi-user chat scheme and devise a secure way of acquiring the
target's resource by first sending a message to everyone in the chat room.
The obvious way of handling this would be to use asymmetric encryption to
send initial connection messages in an encrypted form to everyone in the
chat room, then have the recipient decrypt it and respond via IQ.
However, before I continue with this, I would like some feedback
concerning the practicality of the protocol thus far. Here are some
questions I want to consider:
Is the protocol lacking anything that has not been mentioned?
Is it too complicated?
Is the program still too slow to be useful?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9022#comment:44>
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