Created On 02/08/19 00:06 AM - Last Updated 02/08/19 00:06 AM
We know that SSL decryption is supposed to give us visibility of traffic that would otherwise be encrypted. Therefore, we'd expect decrypted traffic to be identified as the underlying applications, such as web-browsing, facebook-base or other, but not as SSL. However, in some scenarios, seeing application SSL as decrypted is expected behaviour. This article covers one such scenario and explains why a decrypted SSL session identified as application SSL is, in this case, considered OK.
In the below example, we were trying to access the following website:
start time : Tue Jun 21 11:37:52 2016 timeout : 15 sec total byte count(c2s) : 796 total byte count(s2c) : 4759 layer7 packet count(c2s) : 8 layer7 packet count(s2c) : 8 vsys : vsys1 application : ssl rule : Trust 2016 To Internet session to be logged at end : True session in session ager : False session updated by HA peer : False address/port translation : source nat-rule : NAT Trust 2016 To Internet(vsys1) layer7 processing : completed URL filtering enabled : False session via syn-cookies : False session terminated on host : False session traverses tunnel : False captive portal session : False ingress interface : ethernet1/3 egress interface : ethernet1/6 session QoS rule : N/A (class 4) tracker stage firewall : TCP FIN tracker stage l7proc : proxy timer expired end-reason : tcp-fin
When the session is decrypted, App-ID lookup is triggered on the decrypted flow to help identify the session application. The firewall needs to read enough data packets in order to identify the application. After the SSL handshake is completed, we would need to read a maximum of 2000 bytes of data to determine if the application is unknown or not. When the decoder is detected, e.g. web browsing, it may take more than 5 packets to determine the actual application. In most cases, the application will be recognized before receiving that amount of data.
Looking at the packet capture output below, we see that the communication ended prior to the exchange of application data that would have enabled the firewall to identify the application.
This would also apply if regular tls/ssl is wrapped around some custom app: the underlying app would be "unknown-tcp" if it weren't encrypted, but because of the encryption, app-ID has already identified ssl and will keep that as the app.
We hope you find this information useful. Please leave a thumbs up or a comment in the section below.