Traffic Proxy

This chapter covers some aspects related to the service traffic-proxy <id> 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 service traffic-proxy <id> instance:

set service traffic-proxy <NAME> [ ... ]

Where <NAME> 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 traffic policy <txt> 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 Traffic Policy chapter.

Each instance can also be bound to a traffic queue <txt>. 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 Traffic Queue 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:

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:

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:

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:

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:

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 Traffic-Proxy examples page.

Configuration commands

Operational commands