Open oadele3 opened 2 years ago
The listening program listens on the port specified in the proxyspec. So when your listening program accepts a connection on that port, the packets are coming from the client side. After inspecting and/or modifying the packets, the listening program gives them back to sslproxy listening on a dynamically assigned port, which the listening program must obtain from the SSLproxy line in the first packet in the connection. SSLproxy reencrypts and sends those packets to the server, and then gives any packets sent from the server to the listening program over that same port. So when your listening program receives a packet from the dynamically assigned port of sslproxy, that packet is from the server side. HTH.
Thanks. That really helps a lot. The final thing to confirm. I am guessing that after the listening program processes a packet from the downstream server, we will need to send it back to the SSLproxy on the initial connection that SSLproxy opened to the listener program using port defined in proxy spec. Is that correct?
that is if (A) is SSLproxy connection to listener app over port in proxyspec (B) is listener app connection to SSLproxy over dynamic port. then we can have something like this.
client ---> SSLproxy ---(A)--> listener program ---(B)--> SSLproxy ---> server and server ---> SSLproxy ---(B)--> listener program ---(A)--> SSLproxy ---> client.
Yes, that's true.
Thank you!
Does SSLproxy open a different connection to divert program for decrypted packets that are on the response path from the downstream https server? How do I identify packet direction (to_server vs to_client) for packets in the same https connection in my divert program?