You need experienced geek for that. Good luck.
1 of 1 people found this helpful
actually this is not really complicated. I created an example rule set for two Web Servers called
When the Client looks up these host names they will point to MWG. MWG has an entry in the /etc/hosts file, so that DNS resolution on the MWG points to the original web server.
On MWG I have a port 80 and a port 443 to receive HTTP and HTTPS requests:
First of all I created a rule which redirects HTTP to HTTPS:
The rule is only triggered when an HTTP request comes in on Port 80 (see the criteria of the rule set and the rule). In the Event I take the original URL and replace http:// by https://. The result is written into "Redirect.URL". Then I call the redirect action, which redirects to the content of Redirect.URL.
Now I create a rule set to intercept SSL traffic. As you mentioned using the "Enable Client Context without CA" and especially the "Client connection only" flag are what we need. The flag causes MWG to do the SSL handshake completely without verification/talking to the remote server. This means we establish a tunnel between the client and MWG. Once done, the client can talk HTTP in the tunnel as usual. My setting looks like this:
The corresponding rule set looks like this:
I trigger the SSL rule set only for request on port 443. Please note that I also enabled Content Inspection, which is required for MWG to perform the handshake.
Now so far there is probably nothing new to you. At this point MWG would already work as a reverse proxy, but talk HTTPS to the remote server. You can change this behaviour:
That Event causes MWG to talk plain HTTP to the web server.
This is what happens:
- Client etablished connection to MWG on port 443
- MWG performs handshake with client, without talking to the server
- SSL tunnel is set up
- Client sends GET / HTTP/1.1 within the tunnel to MWG
- MWG takes that request and forwards it to the webserver via HTTP
- Web server answers with an HTTP response
- MWG sends this response to the client within the tunnel
- Client displays data
That should do the trick.
Please note that the rules/rule set may not be perfect or need to be changed to match your enironment. I created them in a couple of minutes for my lab here.
Thanks for your reply Andre. This is the response I am getting.
I guess there's something with the redirection rule that I am not getting. Could you please take a look at my ruleset? Also can you explain how "string.ReplaceFirstMatch" works.
Reverse Proxy.xml 42.6 K
please look at the redirect rule again. In the event you need to rewrite the property "URL", not a string URL. The string "URL" does not match the regular expression so MWG tries to redirect you to "URL", which is not a valid destination :-)
I admin this can hardly be seen from the screenshot. the only difference is that the string URL is in quoes, while the property is not. I should have added a more detailed screenshot here.
If you modify your redirect rule as follows it should work:
Additionally I found that you call the Redirect Event only for Response and Embedded Cycles. I would recommend to call it in Request cycle only, as shown in my screenshot above (look at the enabled/disabled cycles).
String.ReplaceFirstMatch applied a regular expression and rewrites something in a string. In this case I look for ^http://(.*), so I check if a string starts with (^) http://. The (.*) "remembers" everything that follows the http:// string. I replace this by https://\1. \1 will be filled with the content I remembered before. So when I have
the "\1" contains "www.ranbaxy.com/index.htm". With the replace string the rule redirects to
Thats the idea behing it. The String.ReplaceFirstMatch ensures that MWG does not try to rewrite more occurences of "http://". If will only replace the very first match and then stop.
Note: I found somewhere that you plan to switch to transparent environment. I am not sure if this rule will work for transparent setups.
Thanks for the update. With correction, the rule works like a charm. Currently I am exploring if I transparent mode can help me in serving reverse proxy connections in a better manner. Will give it a shot. If it works fine, otherwise we have more or less completed it in explicit proxy scenario. We will stick to that.
Thanks again for all the help you have given us in caarying forward this implementation, you have been immensely helpful.
One more question. If my webserver receives http requests at a non-standard port (say 3311) and we want to cloak these as https as discussed intially.
Client sends http request on port 3311
This request is turned into https by virtue of http to https redirection rule.
MWG sees that request is Https, and will send appropriate certificate based on the host name. As SSL Scanner functionality applies to client connection only, an HTTP connection will be established with webserver (will this connection established on standard port 80 or port 3311?) For safety sake, I trigger an action to initiate URL.port=3311 when URL.Host matches with that of the webserver.
However this configuration doesn't seem to work. Could this be due to port settings in proxy? Will using * in ports treated as SSL for 3311 make any difference?
If there is HTTP traffic coming in on port 3311 you should not tell MWG to treat traffic on this port as SSL. I would assume that you would enter port 443 as the ports treated as SSL for port 3311 as well.
I would assume MWG tries to talk to port 80 in the backend. Setting the URL.Port should work (I didn´t test this so far). Can you try setting 443 as the ports for SSL and see what the result is? Maybe you can share some more details abotu the error(s) you see.
if you add 3311 or * to the ports treated as SSL MWG will expect HTTPS communication on this port. Since you are talking to this port HTTP, you do not want to set this. Please change it back to 443. Then we should look at the server unreachable error.
Did I understand it correctly that you want to redirect a client coming in on port 3311 to HTTPS (443)? Is this already working with the existing rules? Can you find out which port MWG is trying to talk to?
I believe MWG is probably talking to the web server on the wrong port.