Starting from Junos OS release 18.2R1, unified policies are supported on SRX Series devices, which enables granular control and enforcement of dynamic Layer 7 applications within the traditional security policy. However, when you configure unified policies with SSL proxy in order to block a particular application, for example Facebook chat/messenger traffic on the Facebook website, the chat or messenger messages are not prevented from being sent but are prevented from being received.

The article demonstrates that this behavior of the device is expected as per Junos design.

Consider the following example in which unified policies are deployed with SSL proxy as shown below:

root@jtac-SRX340-r019# show security policies
from-zone trust to-zone untrust {
    policy test {
        match {
            source-address any;
            destination-address any;
            application any;
            dynamic-application [ junos:FACEBOOK-CHAT junos:FACEBOOK-MESSENGER junos:FACEBOOK-FARMVILLE junos:FACEBOOK-MOBILE-CHAT junos:FACEBOOK-SUPERPOKE junos:FACEBOOK-WINDOWSLIVEMESSENGER ];
        }
        then {
            reject {
                ssl-proxy {
                    profile-name test;
                }
            }
            log {
                session-init;
                session-close;
            }
            count;
        }
    }
    policy permit-all {
        match {
            source-address any;
            destination-address any;
            application any;
            dynamic-application any;
        }
        then {
            permit;
        }
    }
}

root@jtac-SRX340-r019# show services
application-identification;
ssl {
    proxy {
        profile test {
            trusted-ca all;
            root-ca 1;
        }
    }
}

Now when you log in to the Facebook website and send a message to a friend, you will find that the peer can receive the messages. However, when the peer replies with a message, you are not able to receive them. It appears from this test that the SRX device blocks the message that is received but does not block the message that is sent.

root@jtac-SRX340-r019> show services application-identification statistics applications |grep FACEBOOK
                  FACEBOOK-ACCESS                599           82208949           No
               FACEBOOK-MESSENGER               9678           38702180           No    
                   FACEBOOK-VIDEO                 21            3298173           No

root@jtac-SRX340-r019> show services application-identification statistics applications |grep FACEBOOK
                  FACEBOOK-ACCESS                607           82251051           No
               FACEBOOK-MESSENGER               9678           38702180           No    <---- Increasing
                   FACEBOOK-VIDEO                 21            3298173           No

Each time you send a message to your friend, a different source address and port are used, and on the SRX device, a different session is created for each message even though you are sending them in the same chat window.

The first time you send out a message, a connection is established. Then after the appid (with SSL proxy) is recognized as FACEBOOK-MESSENGER or FACEBOOK CHAT , the packet will hit the policy "test" and get rejected followed by the session being closed. This is the reason that the peer cannot communicate with you from outside.

Now with the closure of the first session, there's no usable session present between your peer and you. So when you send out a second message to the same person on the same chat window, a new connection will have to be established, which is again closed for the same specified reason. A similar process occurs for all subsequent sessions.

When the first message is sent, the unified policy has to wait to get the FACEBOOK-MESSENGER or FACEBOOK-CHAT appid to do a lookup and identify the appid , which is possible only after several required packets are permitted by the JDPI module. For example, the traffic will be recognized in the following flow: UNKNOWN > SSL > FACEBOOK-***. This process would require several packets to be parsed, which is the primary reason for the leakage and for the user to be able to send out a message to a peer, but not receive a reply from the peer.

This is expected behavior as per design and there is no known workaround available.

2021-03-02: Minor non-technical edits; content is valid and accurate.