Can listening program return response to client?

[kmushegi]

I am building an application where I need to intercept requests going to domain A and conditionally either forward them to domain A (pass) or route them to my service S in which case I want to response of S to be returned to the client.

Is it possible to accomplish something like this with SSLproxy or must the request always be passed to the server after the listener program returns it back to SSLproxy?

[sonertari]

Firstly, the target server address is determined at connection establishment time. The two main options are using the NAT engine of the system or the target address specified in the proxyspec. Therefore, as you probably already know, once SSLproxy decides on the server address, it cannot be changed.

Ideally, all packets in the connection should pass through SSLproxy, so that SSLproxy knows when a connection ends, for example, and cleans up after it. This means that SSLproxy diverts all packets to the listening program, hence it expects the listening program return all packets to SSLproxy, in both directions.

First approach

In your case, I think you can try to conditionally redirect the client (web browser?) to your service S. So, the listening program always intercepts the connections, and:

1. If domain A is fine, business as usual
2. If it decides to change the target to your service S, then it can send a redirect (HTTP?) response to the client (over the client side of SSLproxy connection)

In the second case, the client would normally open a new connection to your service S, which again goes over SSLproxy and your listening program. This solution would be ideal, imo.

Second approach

But if what I describe above is not possible or acceptable, then your listening program can of course communicate with your service S directly (whenever it wants), but in this case, your listening program should handle all protocol details and encryption/description on its own on the server side (SSLproxy is not involved in this server side communication in anyway). The client side of the connection can still be open and go over SSLproxy, and the actual target domain A should still be reachable over SSLproxy on the server side.

One catch about the second approach, which I hinted above, is that SSLproxy should be able to detect the connection end, so that it can clean up after it. So your listening program should be careful to close all its connections with SSLproxy, when it's done (but not before it's done, otherwise SSLproxy will close the client side of the connection too).

Note about connection expiration: SSLproxy checks for and cleans up idle connections periodically, so resources can be freed. The default max idle time is 120 seconds. So if you choose to use the second approach, and want to keep the client side open, you shouldn't keep it idle for more than 120 seconds (or change that config option as you wish).

Everything I describe above are of course theoretical, meaning I never needed them and never tried, so you need to try (and perhaps fail) them yourself.