What’s a proxy?
A proxy acts as a gateway between you and the internet. The internet traffic flow back and forth if a proxy is setup in the middle. So, what is the need of proxy? There are several reasons organizations and individuals use proxies:
- Control and monitor internet usage
- Proxy servers can give better speed and bandwidth by caching websites
- Proxy servers can also be setup along with VPNs to provide anonymity and better security
There are different types of proxies, but a specific type of proxy that we are going to talk about in this blog is interception proxy.
For starters – Interception proxies are tools that analyses, modifies, and, in some cases, injects traffic into a standard client-server session.
Examples of such tools are Burp, Zap, etc.
Now-a-days, unlike the good ol’ days, every website uses TLS to encrypt their traffic, to prevent stealing/sniffing packets or information on the run. So, if TLS/SSL is put in place to avoid interception for analyzing, modifying and injecting traffic, how do these proxy tools, intercept traffic and we can see everything in clear text i.e., without encryption.
For that we need to understand a couple of concepts – How OSI Layer works and What are certificates.
Let’s Dive into it!
How OSI Layer works?
This section will not help you in understanding the detailed working of OSI, but a few bit and pieces.
A packet travels through all the seven layers to reach the user, and through out the way several processes happen to make data consumable by normal user. The layer that is the most interesting one in this scenario, is the Presentation Layer and Transport Layer.
There are generally three functions of the presentation layer – translation, encryption/decryption, and compression. So, this is the layer where all the encryption/decryption happens, which then sends the data to Application Layer.
The transport layer takes care of the end-to-end delivery of the complete message. It looks after segmentation and de-segmentation of packets and point where it needs to go. Examples of layer 4 transport layer are TCP and UDP protocols.
So, now there can be two ways to get hands on readable traffic –
- If we intercept the traffic on the Application Layer
- If we decrypt the traffic for interception
Intercepting the traffic at application layer is within browser or similar, it might work for browsers but not for thick client, for example.
We are left with the option of traversing all the layers of the OSI model and performing further decryption/encryption, and this method works everywhere.
To understand that we need to understand the significance of the certificates, more specifically CA certificate.
What are CA certificates?
CA Certificates are digital certificates issued by a certificate authority (CA), so SSL/TLS clients (browsers) can use them to verify the authenticity of the server we are talking to. They are the ones that allow security in the traversal.
So, if you need to do secure communication, you need a CA certificate for verification and validation.
That kicks of the basic knowledge required to understand the functionality of Interception Proxy.
To learn more about how CA certificates function or “Why do I need to install Burp’s CA certificate?”- https://portswigger.net/burp/documentation/desktop/getting-started/proxy-setup/certificate
How does interception proxy works?
I am taking burp’s proxy as an example to demonstrate the usage, but generally other interception tools work in a similar fashion.
When we first initialize burp, it does not allow HTTPS traffic by default if the proxy is on. To let burp, allow HTTPS traffic, we install a burp certificate in our browsers.
TLS certificates help encrypt the transmitted data and implement integrity checks to protect against man-in-the-middle attacks. In order to intercept the traffic between your browser and destination web server, Burp needs to break this TLS connection. As a result, if you try and access an HTTPS URL while Burp is running, your browser will detect that it is not communicating directly with the authentic web server and will show a security warning.
To prevent this issue, Burp generates its own TLS certificate for each host, signed by its own Certificate Authority (CA). This CA certificate is generated the first time you launch Burp and stored locally. To use Burp Proxy most effectively with HTTPS websites, you need to install this certificate as a trusted root in your browser’s trust store. Burp will then use this CA certificate to create and sign a TLS certificate for each host that you visit, allowing you to browse HTTPS URLs as normal. You can then use Burp to view and edit requests and responses sent over HTTPS, just as you would with any other HTTP messages. 
So, when a request is being made from a device, it travels through the OSI layers, then that goes to burp, where it bifurcates the packets for interception (modifies, forward, drop, analyze) and then it repackages it with the burp’s certificate to create and sign the TLS certificate, to send it forward to the server.
For the server, it is interacting with the burp and does not know about the client, hence the server sends back response to burp which is being forwarded to the client, completing the complete request-response cycle.
It works a bit different, if the client machine is used to intercept the requests/response. It does not have to traverse through different OSI models, but works well in one OSI model’s layers. Let’s see how it works!
So, here the data circles in one OSI model. For any data to be intercepted, an entire data packet needs to be created that is returned for the interception in the same OSI layer based on proxy settings. For HTTPS traffic, burp uses its CA certificate to sign the SSL certificate that uses HTTPS requests to encrypt and decrypt, before sending them to the server. It works in a similar fashion as demonstrated in the D1.
P.S.: OSI Model is more of a theoretical model, in real world application TCP/IP model is being used.