Editing XEP-0065: SOCKS5 Bytestreams
From JaWiki (Jabber/XMPP wiki)
Warning: The database has been locked for maintenance, so you will not be able to save your edits right now. You may wish to copy and paste your text into a text file and save it for later.
The administrator who locked it offered this explanation: MediaWiki upgrading
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 330: | Line 330: | ||
</iq> | </iq> | ||
− | === | + | === Target Establishes SOCKS5 Connection with StreamHost === |
− | + | If the Target is willing to accept the bytestream, it MUST attempt to open a standard TCP socket on the network address of the StreamHost communicated by the Initiator. If the Initiator provides more than one StreamHost, the Target SHOULD try to connect to them in the order they occur. | |
− | + | If the Target tries but is unable to connect to any of the StreamHosts and it does not wish to attempt a connection from its side, it MUST return a <item-not-found/> error to the Initiator. | |
− | + | Example 13. Target Is Unable to Connect to Any StreamHost and Wishes to End Transaction | |
− | + | <iq type='error' | |
− | + | from='target@host2/bar' | |
− | + | to='initiator@host1/foo' | |
− | + | id='initiate'> | |
− | + | <error code='404' type='cancel'> | |
− | + | <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> | |
− | + | </error> | |
− | + | </iq> | |
+ | |||
− | + | If the Target is able to open a TCP socket on a StreamHost, it MUST utilize the SOCKS5 protocol specified in RFC 1928 [7] to establish the connection with the StreamHost. In accordance with the SOCKS5 RFC, the Target MAY have to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this document. | |
− | + | Once the Target has successfully authenticated with the Proxy (even anonymously), it SHOULD send a CONNECT request to the appropriate host in order to continue the negotiation. The following rules apply: | |
+ | The hostname MUST be SHA1(SID + Initiator JID + Target JID) where the definition of the SHA1 hashing algorithm is as specified by RFC 3174 [8] and the output is hexadecimal-encoded (not binary). | ||
+ | The port MUST be 0 (zero). | ||
+ | The JIDs provided MUST be the JIDs used for the IQ exchange, which MAY be full JIDs (<node@domain.tld/resource>) or bare JIDs (<node@domain.tld>). | ||
+ | The appropriate stringprep profiles (as specified in XMPP Core [9]) MUST be applied to the JIDs before application of the SHA1 hashing algorithm. | ||
− | + | Example 14. Target Connects to StreamHost | |
− | + | CMD = X'01' | |
− | + | ATYP = X'03' | |
− | + | DST.ADDR = SHA1 Hash of: (SID + Initiator JID + Target JID) | |
+ | DST.PORT = 0 | ||
+ | |||
− | + | Example 15. StreamHost Acknowledges Connection | |
− | + | STATUS = X'00' | |
− | + | ||
− | + | ||
− | + | ||
− | + | When replying to the client in accordance with Section 6 of RFC 1928, the StreamHost SHOULD set the BND.ADDR and BND.PORT to the values provided by the client in the connection request. | |
− | + | ||
− | + | ||
− | + | ||
=== Цель подтверждает соединение SOCKS5 === | === Цель подтверждает соединение SOCKS5 === |