- SAP Managed Tags
This is the last of four scenarios, covered by the post series:
"HTTPS tracing and debugging: A simple way "
In this fourth and final example, we will see one of the most complicated scenarios to explore. To analyse this case, we will use a Foundry Cloud application, where we will be able to execute our proxy. An alternative, perhaps simpler, would be to have a remote server (in amazon/Google Services/Azure/Digital Ocean/etc). I was inclined for the option of an application in Cloud Foundry, since I imagine that by these parts there is more knowledge of this instrument. In addition, using the trial version provided by SAP, we can perform this exercise without having to make a payout or register in another platform. As it's the most complex scenario, it's the longest post in the series too. Cheer up!
The biggest difficulty in this scenario will be to prepare a Foundry Cloud application. Cloud Fundry has a BuilPack to run Linux binaries. The binary Build Pack of Cloud Foundry is based on Ubuntu 14.04 (Stack cflinuxfs2 at 27/12/2018), so it is safe to assume that mitmproxy and mitmweb will run smoothly. Also, since the default proxy runs on port 8080, the application will automatically assign the url of the proxy to the application. I will provide more details on how to incorporate the proxy as a Foundry Cloud application.
1.- Login and Pushing a binary build pack
Once you have downloaded the binaries for Linux, you must login to Cloud Foundry and push the binaries in a binary build pack. Attention, if you are using the trial account in Europe (EU10) you will not be able to use the name "mitmproxy" because "it belongs to me" and it will be busy. What you can do is rename your application to "mitmproxy-<suser>" or any other unique name. From now on, the guide always mentions the application "mitmproxy", but you should be careful to use your own application name.
Note that in the push, we are asking cloud foundry to run mitmweb and to push the files as a binary buildpack.
2.- Allow SSH connections to the application
It will be necessary to open a local SSH tunnel between Cloud Foundry and our computer. The idea is to be able to access the remote web application through a local route. It may sound confusing, but it is another property of SSH tunnels (enable remote services locally).
3.- Establish a local SSH tunnel
We will link our local port 8081, with the remote port 8081. This way "localhost:8081" will be accessing the remote port 8081.
After establishing the tunnel, through the SSH console, we can also verify that the proxy is already operative.
4.- Configure mitmweb in reverse mode.
We will do something similar to the previous exercise: we will enable a reverse proxy. However, this time, we will configure it through the web page. As the SSH tunnel is already established, in your browser simply access "localhost:8081". Then options -> edit options -> mode -> "reverse:<targetCPIhost>. What we are indicating is that the reverse proxy will be pointing to our target CPI system.
Also, check the "ssl_insecure" flag, so certificates are not going to be validated by the proxy.
5.- Get the URL of the application
We can do this through the command line, checking the routes or directly in the Cloud Foundry web console.
6.- Configure CPI (Sender & Receiver)
We will use the iflow already used in exercise 2 and exercise 3 of this series of posts. In the case of the iflow "sender", note that the host must now be changed to the host obtained in point 5 of this guide. The Snipets can be found in the last post of this series.
Sender:
In the sender system, you must register the certificate of cloud foundry where the proxy is hosted.
Receiver:
8.- Send a message
9.- And finally, check the proxy!
When I was testing, I had an error due to an incorrect password. I decided to leave this error, so I could show how the proxy behaves when facing errors.
In the second attempt, after correcting the password I can see correctly the HTTPS trace of this example.
With this I close this post series. For me, undoubtedly learning these techniques will help anyone who ever has to analyse an HTTP connection with problems. Finally, I imagine that there may be doubts and since the information is so scattered in these post, take a look at the last post where I can answer questions and attach some codes that might serve you.
Ariel Bravo Ayala
"HTTPS tracing and debugging: A simple way "
In this fourth and final example, we will see one of the most complicated scenarios to explore. To analyse this case, we will use a Foundry Cloud application, where we will be able to execute our proxy. An alternative, perhaps simpler, would be to have a remote server (in amazon/Google Services/Azure/Digital Ocean/etc). I was inclined for the option of an application in Cloud Foundry, since I imagine that by these parts there is more knowledge of this instrument. In addition, using the trial version provided by SAP, we can perform this exercise without having to make a payout or register in another platform. As it's the most complex scenario, it's the longest post in the series too. Cheer up!
Consumption of an echo service in CPI, from another CPI account.
The biggest difficulty in this scenario will be to prepare a Foundry Cloud application. Cloud Fundry has a BuilPack to run Linux binaries. The binary Build Pack of Cloud Foundry is based on Ubuntu 14.04 (Stack cflinuxfs2 at 27/12/2018), so it is safe to assume that mitmproxy and mitmweb will run smoothly. Also, since the default proxy runs on port 8080, the application will automatically assign the url of the proxy to the application. I will provide more details on how to incorporate the proxy as a Foundry Cloud application.
1.- Login and Pushing a binary build pack
Once you have downloaded the binaries for Linux, you must login to Cloud Foundry and push the binaries in a binary build pack. Attention, if you are using the trial account in Europe (EU10) you will not be able to use the name "mitmproxy" because "it belongs to me" and it will be busy. What you can do is rename your application to "mitmproxy-<suser>" or any other unique name. From now on, the guide always mentions the application "mitmproxy", but you should be careful to use your own application name.
Note that in the push, we are asking cloud foundry to run mitmweb and to push the files as a binary buildpack.
2.- Allow SSH connections to the application
It will be necessary to open a local SSH tunnel between Cloud Foundry and our computer. The idea is to be able to access the remote web application through a local route. It may sound confusing, but it is another property of SSH tunnels (enable remote services locally).
3.- Establish a local SSH tunnel
We will link our local port 8081, with the remote port 8081. This way "localhost:8081" will be accessing the remote port 8081.
After establishing the tunnel, through the SSH console, we can also verify that the proxy is already operative.
4.- Configure mitmweb in reverse mode.
We will do something similar to the previous exercise: we will enable a reverse proxy. However, this time, we will configure it through the web page. As the SSH tunnel is already established, in your browser simply access "localhost:8081". Then options -> edit options -> mode -> "reverse:<targetCPIhost>. What we are indicating is that the reverse proxy will be pointing to our target CPI system.
Also, check the "ssl_insecure" flag, so certificates are not going to be validated by the proxy.
5.- Get the URL of the application
We can do this through the command line, checking the routes or directly in the Cloud Foundry web console.
6.- Configure CPI (Sender & Receiver)
We will use the iflow already used in exercise 2 and exercise 3 of this series of posts. In the case of the iflow "sender", note that the host must now be changed to the host obtained in point 5 of this guide. The Snipets can be found in the last post of this series.
Sender:
In the sender system, you must register the certificate of cloud foundry where the proxy is hosted.
Receiver:
8.- Send a message
9.- And finally, check the proxy!
When I was testing, I had an error due to an incorrect password. I decided to leave this error, so I could show how the proxy behaves when facing errors.
In the second attempt, after correcting the password I can see correctly the HTTPS trace of this example.
With this I close this post series. For me, undoubtedly learning these techniques will help anyone who ever has to analyse an HTTP connection with problems. Finally, I imagine that there may be doubts and since the information is so scattered in these post, take a look at the last post where I can answer questions and attach some codes that might serve you.
Final words, Q&A and snippets
Ariel Bravo Ayala
5 Comments
| User | Count |
|---|---|
| 12 | |
| 9 | |
| 9 | |
| 7 | |
| 7 | |
| 6 | |
| 5 | |
| 5 | |
| 4 | |
| 4 |
