How to intercept and forward traffic on any port?

Question

Traffic analysis

There are 2 programs, client and server.
They communicate on a non-standard port, but via https. In the client, you can specify the ip:port of the server

. Is there a "simple" way to raise a certain service that would listen to the XXX port, replace the certificate with traffic logging and redirect to ip:YYY. those. MIT attack

Answer 1

No, that's the whole point of using https, you won't be able to carry out a MITM attack unnoticed.
In order for the attack to be carried out in principle, it is necessary to somehow force the client to ignore the https certificate control or slip its root (by the way, this only makes sense if the service uses certificate control from the wasp and not its own). It is also possible if there is a certificate of the service used (the owner of the server has it) an attack is possible.
Here it is enough to raise a proxy service, signing its requests on an intermediate server.

Answer 2

iptables can do this configure NAT masquerade

Answer 3

There is no easy way. Its only implementation is as it is done in squid. And most importantly - that the client (initiator of the connection) has a trusted CA certificate that will issue a certificate for the interceptor server.
A very simplified regular session:
Client: Hi, I'm Vasya Piskin, I can encrypt this way and that
Server: Hi, I'm vk.com, I can encrypt this way and that
Client: OK, I agree to ..., my certificate
Server: My certificate
(further checking on the client that this is actually a vk.com certificate, checking the validity of the certificate, generating a session key)
[encrypted session]
Session via mitm (squid in this case):
Client: Hi, I'm Vasya Piskin, I can encrypt this way and that way
Proxy: Hello, I'm vk.com, I can encrypt this way and that
Client: OK, I agree to ..., my certificate
(the proxy quickly generates a certificate for itself in the name of vk.com)
Proxy: My certificate
(then check on the client that that this is actually a vk.com certificate, verifying the validity of the certificate, generating a session key Having obtained the session key, the proxy accesses the real vk.com, establishes a connection with it, and exchanges between Vasya and vk.com as if it were not there. But since the session key is available to him, he is inside the connection and can monitor it and break it if necessary.
Of course, the question arises - why does Vasya believe such an obvious fake as a certificate from CA "Big Brother" pretending to be vk.com? And the whole point is that the certificate of the CA that issued the certificate for the proxy MUST be trusted by Vasya - if this is not the case, Vasya's browser will say in response to the proxy certificate "Who are you? Come on, goodbye")