-1

I am currently implementing a TCP Proxy Server. The huge problem I have right now is that, based on the clients' TCP data, I am trying to determine whether the client is making an HTTP, FTP or SMTP request.

My solution, I am thinking that I have to read the first line of data of the TCP data. For example, an HTTP request would contain an HTTP method such as GET, POST, DELETE, etc.

My question is: is this solution of mine correct? and if so or not, how should I go about it (as well as for determining FTP and SMTP) ?

10
  • 9
    I think you need to explain a little bit more what it is that you actually want to achieve. When I look at your question in its current state with the information given, I am thinking this: If you are implementing a TCP Proxy, then you only need to know about TCP and not about any higher-level protocol. If you need to know about any higher-level protocol, then you are not implementing a TCP Proxy. So, either there is something wrong with your TCP Proxy that requires it to know things it shouldn't, or you need to implement an HTTP Proxy, an FTP Proxy, and an SMTP Proxy instead of a TCP Proxy. Commented Jan 13, 2019 at 17:42
  • 1
    In other words: a TCP Proxy shouldn't need to know the things you are asking about. If it needs to know those things, then it stops being a TCP Proxy, and you will end up with 3 proxies (might still be the same executable, but logically, it will be 3 proxies) for the 3 protocols instead. E.g. Squid can do both HTTP and FTP, I believe. Commented Jan 13, 2019 at 17:44
  • 1
    It is impossible to determine the higher-level protocol from TCP. The client and server agree on the higher-level protocol out-of-band, there is simply no information transmitted inside TCP that would allow you to determine the protocol. The client and server agree on the protocol outside of TCP, before they even start to communicate. (In most cases, this "agreement" actually simply boils down to the client blindly assuming that on that specific port it connects to, there will be some daemon listening which speaks that protocol. E.g. a browser will just send HTTP to port 80 and hope the best.) Commented Jan 13, 2019 at 17:49
  • 1
    and how will you deal with encrypted protocols so common these days? Even www.google.com uses https..
    – Erik Eidt
    Commented Jan 13, 2019 at 17:51
  • 1
    @marvinIsSacul: At the TCP level, you can get the ip address and port of the sender and the ip address and port of the destination (which will be the proxy server). The address/port that the packet needs to be forwarded to must be configured in the proxy server. Commented Jan 13, 2019 at 18:48

1 Answer 1

0

Different types of proxies do different things.

A VPN proxy will commonly receive largely unprocessed packets as the payload of the packets actually crossing the network, translate the headers to it's own interface, and send them without looking at the data at all. This can implement a TCP proxy, but requires special configuration on the machine using the proxy, and can easily cause protocol failures if the server is expected to establish it's own connection to the client, as can happen with FTP.

A SOCKS proxy starts out with the socket in "SOCKS mode", processes the SOCKS commands, and uses the received information to connect the another socket to the destination, doing as little modification as it can afterwards. This does not implement a TCP proxy.

An HTTP proxy assumes from the start that incoming connections will be in HTTP, and looks for any headers specifically would tell it the desired connection point, inevitably resulting in errors if a different type of connection comes in. This does not implement a TCP proxy.

Different types of proxy work in different ways.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.