============= Traffic Proxy ============= .. sidebar:: Contents .. contents:: :depth: 2 :local: This chapter covers some aspects related to the :osdx:cfg:`service traffic-proxy *` tool, which allows you to configure one or multiple **SSL Proxy** instances in OSDx. The traffic-proxy service can be used to intercept and proxy SSL traffic. This feature can be used to play the role of *man-in-the-middle*, allowing the inspection of encrypted traffic. Configuration ============= Each instance can be bound to a different **local port**, where the incoming traffic, originated on the client side, is received, mangled and diverted to the server. Upon receiving the packets back from the server, the traffic proxy re-encrypts and sends them to their original destination. This is the syntax to create a :osdx:cfg:`service traffic-proxy *` instance: .. code-block:: none set service traffic-proxy [ ... ] Where ```` represents the name of the instance. When you configure a new instance, you need to specify at least the following parameters: * ``mode``: SSL proxy operating mode. It accepts the following values: * ``http`` or ``https``: to decode plain or secure HTTP connections. * ``pop3``, ``pop3s``, ``smtp`` or ``smtps``: to decode plain or secure POP3 or SMTP connections. * ``ssl`` or ``tcp``: to not decode connections, but treat the decrypted content as an opaque stream of bytes. * ``autossl``: to not decode connections, but work as protocol-independent STARTTLS. * ``x509 ca-cert`` and ``x509 ca-key``: path to PEM CA certificate and key. * ``port``: local port that will be used to intercept traffic. .. warning:: Make sure to **select the appropriate mode**. If you need to decrypt multiple kinds of protocols, you can always configure several instances. Take into account that if you configure, for example, ``https`` or ``ssl`` mode and the service intercepts ``plain http`` traffic, it will reject the connection sending an abort response. By default, the generated traffic is not VRF-aware, which means that the ``main`` VRF will be used. The instances can also be configured to use a **specific VRF**, using the ``local-vrf`` field. Intercepting and analyzing traffic ================================== In order to intercept traffic, you need to create a :osdx:cfg:`traffic policy *` and configure it to proxy the traffic to the aforementioned local port. Then, you should attach that policy to an interface or configure it globally. Further information about traffic policies can be found at the :doc:`/articles/routing/traffic/policy/index` chapter. Each instance can also be bound to a :osdx:cfg:`traffic queue *`. Although this is not required, it's very useful to configure a traffic queue to be able to analyze the decrypted traffic; for example, using a firewall instance. Further information about traffic queues can be found at the :doc:`/articles/routing/traffic/queue/index` chapter. Simple example ============== Imagine that you want to configure the traffic-proxy service to intercept and decrypt SSL traffic destined to another server; e.g., HTTPs traffic. Preparing the device -------------------- First, we need to have, at least, a valid x509 certificate and private key. We can generate them using an OSDx device: *Example:* .. code-block:: none admin@DUT0$ pki generate private-key running://test.key rsa Generated private key at 'running://test.key' admin@DUT0$ pki generate certificate running://test.crt x509 private-key running://test.key days 3650 subject "/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*." Generated X.509 certificate at 'running://test.crt' Configuration commands ---------------------- Now, we can create a new service instance and bind it to a local port. *Example:* .. code-block:: none set service traffic-proxy TRAFFIC_PROXY mode https set service traffic-proxy TRAFFIC_PROXY port 3128 set service traffic-proxy TRAFFIC_PROXY x509 ca-cert running://test.crt set service traffic-proxy TRAFFIC_PROXY x509 ca-key running://test.key Then, we need to create and attach a traffic policy to intercept the traffic: .. code-block:: none set traffic selector TCP_TRAFFIC rule 1 protocol tcp set traffic selector TCP_TRAFFIC rule 1 destination port 80,443 set traffic policy TPROXY rule 1 selector TCP_TRAFFIC set traffic policy TPROXY rule 1 action proxy tcp 3128 set interfaces eth0 traffic policy in TPROXY set interfaces eth1 traffic policy in TPROXY We have created a new traffic selector to match all TCP traffic with destination port equals to 80 or 443 (normally these ports are used for HTTP and HTTPs respectively). Then, we have assigned that traffic selector to a new traffic policy that proxies the traffic to our local port. Finally, we have attached the traffic policy to the incoming hook of two physical interfaces: ``eth0`` and ``eth1``. Monitoring commands ------------------- We can run the command ``service traffic-proxy TRAFFIC_PROXY show connections`` to display the latest connections that were intercepted. *Example:* .. code-block:: none admin@DUT0$ service traffic-proxy TRAFFIC_PROXY show connections 2023-09-21 21:08:09 UTC CONN: ssl 10.0.0.2 1234 192.168.1.2 443 sni:- names:Server sproto:TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 dproto:TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 origcrt:188178F6F7097DC76C12FB0330D1629EBE357D78 usedcrt:D79EB0BA11576DB6233725C8E3A7807642F0F31F user:- We can see that a SSL connection that was started in 10.0.0.2:1234 and destined to the server 192.168.1.2:443 was intercepted at 2023-09-21 21:08:09. There's more information like the TLS version that was used in both connections, the encryption algorithms, etc. We can also configure the option ``set service traffic-proxy TRAFFIC_PROXY logging content`` and then run the command ``service traffic-proxy TRAFFIC_PROXY show content`` to display information about the decrypted session. *Example:* .. code-block:: none admin@DUT0$ service traffic-proxy TRAFFIC_PROXY show content 2023-09-21 21:08:10 UTC [10.0.0.2]:1234 -> [192.168.1.2]:443 (18): Hello from client 2023-09-21 21:08:10 UTC [192.168.1.2]:443 -> [10.0.0.2]:1234 (18): Hello from server 2023-09-21 21:08:10 UTC [10.0.0.2]:1234 -> [192.168.1.2]:443 (EOF) More **traffic-proxy** examples are available in the :doc:`/examples/service/traffic-proxy/index` examples page. .. osdx:cmdtree:: cfg :maxdepth: 5 service traffic-proxy .. osdx:cmdtree:: op :maxdepth: 5 service traffic-proxy