Is it possible that for example there is a TCP packet, and using a proxy, you intercept it and using a tool you change the protocol entirely? Like for example from TCP to UDP or any other custom protocol?
2 Answers
In theory? Sure, but you're going to run into all sorts of problems in practice.
Network protocols are identified by a field - usually just a byte or two, total size varies between parent layer protocols though - on each packet, in the header of the underlying protocol (e.g. TCP and UDP are both identified by a field in the IP header). However, that doesn't mean you can just change the value in this field and have a different protocol. Protocols are defined as a whole structured type and an algorithm for using that type. Most of the structure is in a header, which varies in both size and information represented.
If you try to change e.g. TCP to UDP, you'd have to throw away a ton of information that TCP carries but UDP has no concept of (e.g. sequence numbers and acknowledgements). Then, even though UDP in theory has less metadata, you'd immediately encounter another problem: where do you split the messages? TCP is a stream-oriented protocol; at a conceptual level, the individual TCP frames contained in IP packets have no particular relationship to the sending process' invocations of send or write; one frame may contain 10 tiny writes, or 0.02% of a big one, or the tail end of one big write and then two small ones and then the start of another big one. TCP doesn't distinguish these! However, UDP does; each UDP packet ("datagram") is one message, and never a mishmash of multiple messages or a fraction of some larger one (except in the sense that some higher-level protocol may be running on top of UDP and support message packing/splitting). Going the other way, you run into the reverse problem; you can concatenate all the UDP bodies into one TCP stream easily enough, but the recipient won't know where those boundaries were supposed to be, and also you'll have to just come up with new TCP sequence numbers and so on. That's without even getting into things like broadcast and multicast, where the connection-oriented nature of TCP is just not compatible.
So, what are you trying to do? If you're just asking "can a proxy or similar translate one protocol to another?", the answer is probably yes, though it'll often look more like "wrapping" one protocol in another. For example, you receive a UDP message, so you connect a new TCP stream if you don't already have one, and write to the TCP stream a structured message that basically says "I got a UDP packet, it was from X IP on port A, it's N bytes long, here it is". The other end sends a TCP response in the same format, and you unpack it and send a corresponding UDP packet (and if the TCP sender tries to send you a 7000 byte message, you maybe send them back an error saying "too big" because that doesn't fit in one UDP datagram). You could do a similar thing to wrap TCP traffic using UDP, though that would be pretty silly in most cases unless you're OK with losing most of the advantages of TCP (reliable, in-order, congestion-managed delivery) since you'd just have to re-implement them in the UDP wrapper.
If your question is instead "could an intercepting proxy flip the protocol ID field on packets going through it?" the answer is "technically yes but they'd be completely incomprehensible to the receiving party, whether that party expected the original protocol or the new one, because the modified packets wouldn't be a valid form of either protocol at that point."
-
I have another question related to protocols, is it possible to create a custom protocol on the layer 4s (UDP, TCP) like RSP (Remote Shell Protocol)? For example it includes headers like "allow Shell" to the IP address you are sending it to? Sep 17 at 8:41
-
Conceptually, sure it's possible. You'll need raw socket access which usually means the process has to run elevated, and I'm not sure what the point would be unless you're inventing something that doesn't work well with the modern protocols such that just layering it one top of a suitable one doesn't work, but you can do it. As a side note, this isn't obviously a security question; the security of protocol design is its own very complicated topic. Sep 17 at 10:13
-
I know I'm being kind of annoying, but, I have a question, can the TCP packet response of a server be changed by an attacker doing a MiTM attack like instead of an HTTP response, the attacker converts it into an HTTP request by modifying the payload? Sep 17 at 21:08
-
... yes but what's the point? It's going to arrive back at the client, on whatever port the browser (or other HTTP client) was assigned, and the browser will go "this isn't a valid HTTP response", close the connection, and display an error message. Like, what's your threat model, here? What would somebody who is doing this be trying to achieve, and why should we care whether or not it succeeds? Sep 17 at 21:48
-
What I'm trying to say is, what if I set up for example a malicious listener and make the server's TCP packet response be manipulated so that it connects to my listener? Sep 17 at 22:42
There's a little detail you missed: a proxy creates an entirely new connection.
A proxy creates another connection in your behalf, and forwards all data to you. Like a VPN, for the destination system, it's the proxy that it talks to. And the proxy is the system talking to you, not the destination.
A proxy can change TCP for UDP, can change HTTP to HTTPS and vice versa, can convert FTP to FTPS... as long as it's possible to get the data from one connection and send it to another, it can convert that.
Software that encapsulates one thing into another are proxies, like encapsulating TCP streams over DNS. Or SSH over HTTP, or DNS over TLS. They grab the data from the incoming connection, send it to the destination, grab the response and send back to the first connection.
So yes, it's easy.
