Technical Tip: A situation where the 'Decrypted Traffic Mirror' on FortiProxy may not work

A feature called 'Decrypted Traffic Mirror' is intended to decrypt encrypted traffic and send them via an intended interface to a remote server.

Even though FortiProxy is well configured with 'Decrypted Traffic Mirror', there is a situation where it may not work.

Since traffic is expected to go through multiple policies on FortiProxy to match the best policy, TLS handshake tends to start with the very first policy that partially matches traffic.

1. If the very first policy where TLS starts is enabled with 'Decrypted Traffic Mirror', then FortiProxy can send decrypted via an intended interface to the remote server.

Example:

• All traffic heading to 'IP_kakaocorp.com', 'IP_line.me' and 'IP_news.-line.me' first hit policy #32 where TCP and TLS handshake initially start. Then traffic finally matches the policy #28.
• The reason why TCP and TLS handshake start at policy #32 is that FortiProxy is not able to validate the proxy address until data starts getting transmitted.
• Policy #32 and Policy #28 both have a 'Decrypted Traffic Mirror'.

2. If the very first policy where TLS starts is NOT enabled with 'Decrypted Traffic Mirror', then FortiProxy is NOT able to send decrypted via the intended interface to the remote server.

    

Example:

• All traffic heading to 'IP_kakaocorp.com', 'IP_line.me' and 'IP_news.-line.me' first hit policy #32 where TCP and TLS handshake initially start. Then traffic finally matches the policy #28.
• The reason why TCP and TLS handshake start at policy #32 is that FortiProxy is not able to validate the proxy address until data starts getting transmitted.
• Policy #28 only has 'Decrypted Traffic Mirror'.
• The reason is that it is too late for policy #28 to decrypt traffic because TLS handshake already starts at policy #32 where 'Decrypted Traffic Mirror' is NOT enabled.