About Tor and Multi-Protocol Port Numbers.

On a past occasion I had tried to write on Facebook – of all places – that each computer, and therefore each IP Number, has seemingly arbitrary Port Numbers that it receives packets to, primarily to prevent most connection attempts from being futile. I.e., I was stating that there is an official, assigned port number, for most types of protocol that devices communicate with over the Internet. Yes, There Are Many More types of protocols, than just those for HTTP (80), HTTPS (443), POP, SMTP, IMAP, etc..

But this proclamation of mine just serves to remind, that no matter how hard we try to convey the truth, we only end up with approximations.

It’s possible for one server-program to listen on one port number, and to accept requests for a number of protocols – all on the same port number.

One example where this happens, is with proxy-servers. Typically, they might be listening for HTTP connections, let’s say on port 8118. But then the next question people might ask when setting up their browsers could be: ‘I like sending my regular HTML text through a proxy, let’s say to filter it, but I must also forward my HTTPS requests through a proxy – or not – And one might not want to send all the browser’s data through a single SOCKS5 port, just so that the proxy-server can do some differentiation. Therefore, where should I tell my browser to forward my HTTPS traffic?’

And in most cases, the answer would be through port 8118 again .  And that’s because a typical HTTP proxy, reacts to an HTTPS request, via a CONNECT instruction, which means that it treats the encrypted data as gibberish, and then either lets it through or not so. It’s not strictly necessary for a proxy server to analyze traffic, in order to be able to forward it. Yet, there can exist some HTTP proxies, whose feature just to accept a CONNECT command has been disabled. But you can in some cases just try them out.

Another example of this would be the “Tor” anonymizing network. Its standard port number has been 9050 for some time, but a Tor node simply listens on this one port number, regardless of whether that’s to accept connections from Tor nodes someplace else on the Internet, or whether that’s to accept an outbound connection from a local proxy-server – i.e. from another program on the same computer. With Tor specifically, If in doubt, you’d simply try to fire a connection at it and see what happens, via its only listening port. But for the most part, Tor likes a SOCKS5 connection going out.

Now there has been the issue, that certain firewalls will specifically block requests to connect to port 9050 on outside machines. And so some Tor nodes have been instructed to listen on some other port number, for incoming connections. But in order to get that to work, a kind of quiet agreement has been reached between Tor users, as to which port number they’re hijacking – that port number now being one officially assigned to an existing, other protocol.

So was I half-right, or half-wrong? I was trying to state basic knowledge, which might still be taken as a first-order approximation of the real world.

Dirk

 

Print Friendly, PDF & Email

One thought on “About Tor and Multi-Protocol Port Numbers.”

  1. It’s relevant here, that when a non-compromised Web-browser expects to retrieve an SSL-secured page, the browser will only pay attention, to whether the domain-name of the content-provider matches the one given on the public SSL certificate. The domain-name of the proxy is not allowed to interfere with that process.
    Yet, there could be browsers which offer to modify the content of SSL-secured pages, one example being “Opera”. In such a case what’s happening, is that the browser can send the unencrypted content to a proxy somewhere, and that the proxy can encrypt the content after modifying it. In principle, in such cases, the content-provider should be able to detect that the content has been encrypted on behalf of the user, if the effort is made to detect this, and that the connection is not secure for that reason.
    A secure browser won’t allow that to happen, instead encrypting the content before any copy of it has been sent anywhere.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please Prove You Are Not A Robot *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>