# Proxy Mode

### Introduction

In Proxy Mode, users communicate with a target server through a browser plugin and a proxy server.

<figure><img src="https://mermaid.ink/img/pako:eNo9jctqwzAQRX_FzNoxlmQ5sgjdNNl1UbopFG3UaPwASwqyRJ2a_HuVQHpXc2Y4dzY4e4MgoZ_9z3nUIRZvH8oVOac1olsm74rDLueleA9-vT7hE7-XKSKUMITJgIwhYQkWg9V3hO1eoiCOaFGBzKPBXqc5KlDulrWLdl_e26cZfBpGkL2el0zpYnTE46SHoO3_NqAzGF59chEkYY8OkBusmVpRMU4ZayjhjLBWlHAFuaOi2tc17zitKeN837W3En4ff0nVECpEw3jDu2zk0x84j1Df" alt=""><figcaption></figcaption></figure>

The Proxy Server establishes a "tunnel" between the browser plugin and the target server. Users communicate data through this tunnel, and the Proxy Server logs all data packets sent and received via the tunnel.

Since the Proxy Server does not possess the encryption key, it cannot decrypt the communication data.

After the TLS handshake is completed, the user can begin sending data to the target server. At this point, the `createRequest` method of the provider is called to generate the data and its associated redaction policy.

Before data transmission, the data is validated using the same rules as the server to ensure successful claim creation.

To achieve data desensitization, users must send data in a specific manner:

* **TLS Key Update Method** (default, high efficiency, supports only TLS 1.3, and applies only to data sent from the user to the server):
  * The user sends data in segments, each encrypted with a different TLS session key. The Proxy Server only obtains partial keys, thus can only decrypt partial data.
* **Zero-Knowledge Proof (ZKP)** Method (redaction, see [ZKP](/orangepass/introduction/zero-knowledge-proof.md)):
  * Using zero-knowledge proofs, the user can prove to the verifier that a specific encrypted block can be decrypted into a particular plaintext without revealing the key used for encryption.

***

### Detailed Process Flowchart

<figure><img src="https://mermaid.ink/img/pako:eNqFkkuP2jAUhf-K5TUgkhAeWVTqJBBG0wUiTBdjZmGSS7Ca2NSPURnEf6-xQwWaRbOKfb7re8-xz7gUFeAEb3kt6fGANtmWI_t9J8-caUYb9gkoFZxDqZng76jf_4aeyFxpumuYsgXGas27r3pycko2Pwq0pLxSB_oLOi11WkYyqinaSMpVy5SyZyILojVU1HfwdOboOVlJOFIJjwVrKIWsOnLuyAUpzK5lGqUNZa0lfhtQukMWDsnJT5Bsz0qqb10LVnPG6w7LHbYka9BGXrso01yP8KoyOx_RVwOFpjXcz50FpIC6Ba6h8vycl_J0vDcYeDIkS1YBKoArm_cHoGe-F7Kl92jo0Yi8KpuEzfYFTuj1WFENSEj09rLqSODVl3EfTN9N6t3mgU_l1F0kWlFJW9Ag1S0VP2geklS0_7mL3E-aRyQD59eZv4mRF0ckpU1jHcsPVsLjfAvD71-B9YN7uJaswomWBnq4BZvNdYnPV2SL9QFa2OLE_lawp_bGtvYxX2zZkfI3IdpbpRSmPuBkTxtlV8allzFqQ2r_7UrbEGQqDNc4CSbuDJyc8R-7Gk8HURxG0SgM4iiIxtMePuGkH04Hk-EwnsXhMIzieDIbX3r40_UNBqMgnE5HUTyKZ7ZiNrv8BS9IFR0" alt=""><figcaption></figcaption></figure>

1. **Initialize Connection**
   * **Description**: The process begins with initializing the connection, configuring necessary communication parameters to prepare for establishing a secure communication channel.
   * **Output**: Proceeds to the tunnel establishment stage.
2. **Establish Tunnel**
   * **Description**: Based on the initialized connection, a secure communication tunnel is established to ensure the security of data transmission.
   * **Output**: Proceeds to the TLS handshake stage.
3. **TLS Handshake**
   * **Description**: The TLS protocol is used to complete the handshake process, establishing an encrypted communication channel to ensure the confidentiality and integrity of subsequent data transmission.
   * **Output**: Proceeds to the data transmission and redaction stage.
4. **Data Transmission and Redaction Stage**
   * This stage includes the following sub-steps:
     * **4.1 Segmented Data Encryption**:
       * Data is segmented and encrypted to protect its security during transmission.
     * **4.2 Hide Sensitive Information**:
       * Sensitive information is redacted or hidden to prevent unauthorized access and protect privacy.
     * **4.3 Use TLS Key Update or ZKP**:
       * TLS key update mechanisms or zero-knowledge proof techniques are used to further enhance the security and privacy of data transmission.
   * **Output**: Encrypted and redacted data, proceeding to the transmission record preparation stage.
5. **Prepare Transmission Record**
   * **Description**: A transmission record is generated, containing necessary metadata and encrypted information for subsequent verification.
   * **Output**: Transmission record, proceeding to the claim request submission stage.
6. **Submit Claim Request**
   * **Description**: The transmission record and related claim request are submitted to the verifier, triggering the verification process.
   * **Output**: Proceeds to the verification and signing stage.
7. **Verification and Signing Stage**
   * This stage includes the following sub-steps:
     * **7.1 Verify Tunnel Parameters**:
       * The communication tunnel parameters are checked to ensure the connection's security and consistency.
     * **7.2 Compare Transmission Record**:
       * The submitted transmission record is compared with expected data to confirm data integrity.
     * **7.3 Decrypt Data**:
       * Encrypted data is decrypted for further verification.
     * **7.4 Call Service Verification Function**:
       * A specific service verification function is called to check the data's validity and legitimacy.
   * **Output**: Verification result and signature, proceeding to the result return stage.
8. **Return Result**
   * **Description**: The verification result (including the signature) is returned to the requester, completing the process.
   * **Output**: Process ends, returning the verification result.

***

### UML Sequence Diagram

<figure><img src="https://mermaid.ink/img/pako:eNqNVE2P2jAQ_SuWT1sJEEkIy_qwF1i1hx4QoD1USKtRPASriZ2OHVqK9r_X-QJ2WdjmFM_Me2_mjZMDT4xELrjFXyXqBGcKUoJ8rZl_CiCnElWAdmyaKdTuMv6MpDYK6TKz-r58WZVaY3aZWyLtVIIvczI7JSt0U9Oo9B8fO1rhS7VkSiu3qFq0bQtdvu9rG5BgC3Ql6bbWFkZb_Iw3IQSHTZf_y_8Wc0XnNLxgc6SNobwyhH0DLe0WfmJTfyo7F5oavVEecCz2kbzI0CmjbyrVMz3phPaFQ8lm4IDdLTHNfSnKL7c0F5ig2iFbAaXYLAiJXZ3v_QJ905BlrTetk8wZ9hU1kg_VvTQc76EfWFw37of3ZwlJNTabm0wl-0_3mYHK36yT3f1WbstWBNrmytqKy89qqLPjuOlzsvptzxomNgf_SaBDsjcgM6xtr9uu1gV0PvQZ5Ip1YC2Se4ZMyS5T76Rw1207qbfGNYEEXDOmLTPXWXbjRi9Vqv11mVbmMUPsicgQ7_GUlOTCUYk9niPlUB35oeJbc7fFHNdc-FeJG6iU-Fq_epj_wn8Yk3dIMmW65WIDmfWnspD-OrS_mWOU_PKQpqbUjoswqDm4OPA_XATjySCKwygahUEcBdF40uN7LvrhZHA_HMYPcTgMozi-fxi_9vjfWjcYjIJwMhlF8Sh-8Aif-gcC9649" alt=""><figcaption></figcaption></figure>

1. **Initialize Connection**
   * **Description**: The Client sends an `initRequest` to the Verifier to start the interaction process.
   * **Verifier Response**: The Verifier returns an `initResponse`, confirming initialization completion.
   * **Output**: Proceeds to the TLS tunnel creation stage.
2. **Create TLS Tunnel**
   * **Description**: The Client sends a `createTunnelRequest` to negotiate the establishment of a TLS tunnel.
   * **Verifier Response**: The Verifier returns a `createTunnelResponse`, confirming the tunnel creation parameters.
   * **Output**: Proceeds to the TLS handshake stage.
3. **TLS Handshake**
   * **Description**: The Client performs a TLS protocol handshake with the TLS Tunnel to establish a secure encrypted communication channel.
   * **TLS Tunnel Response**: The TLS Tunnel returns a handshake completion confirmation, indicating the channel is ready.
   * **Output**: Proceeds to the encrypted data transmission stage.
4. **Encrypted Data Transmission**
   * **Description**: The Client sends segmented encrypted data (`Encrypted Data (Segmented)`) through the TLS Tunnel.
   * **TLS Tunnel Response**: The TLS Tunnel receives the target server's response and returns it to the Client.
   * **Output**: Proceeds to the data generation request stage.
5. **Generate Data Request**
   * **Description**: The Client sends a `createRequest` to the Service Provider to generate data.
   * **Service Provider Response**: The Service Provider returns the generated data along with a `Redaction Policy` to guide data processing or privacy protection.
   * **Output**: Proceeds to the claim request submission stage.
6. **Submit Claim Request**
   * **Description**: The Client sends a `claimTunnelRequest` to the Verifier, including the transmission record (`Transmission Record`).
   * **Output**: Triggers the verification process.
7. **Verification Process**
   * **7.1 Verify Tunnel Parameters**:
     * The Verifier checks the TLS Tunnel parameters to ensure the connection's security and consistency.
   * **7.2 Decrypt and Compare Data**:
     * The Verifier decrypts the received data and compares it with the transmission record to confirm data integrity.
   * **7.3 Call Service Verification**:
     * The Verifier calls `assertValidProviderReceipt` on the Service Provider to validate the data's legitimacy.
     * The Service Provider returns the verification result (`Verification Result`).
   * **Output**: Verification result, proceeding to the result return stage.
8. **Return Result**
   * **Description**: The Verifier returns a `Signed Claim` or an error message to the Client based on the verification result.
   * **Output**: Process ends.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.orangeprotocol.io/orangepass/introduction/proxy-mode.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.