Decrypted SSL Session Marked as Application SSL

Issue

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: 

https://my.vmware.com/web/vmware/login

From the session table, we can see that the session is marked as decrypted (*)

admin@Faith-PFW-X1> show session all filter ssl-decrypt yes

--------------------------------------------------------------------------------
ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port])
Vsys Dst[Dport]/Zone (translated IP[Port])
--------------------------------------------------------------------------------
25472 ssl ACTIVE FLOW *NS 192.168.16.48[60668]/Zone-Trust2016/6 (10.193.90.32[61785])
vsys1 216.58.212.163[443]/Zone-UnTrust (216.58.212.163[443])
25475 ssl ACTIVE FLOW *NS 192.168.16.48[60670]/Zone-Trust2016/6 (10.193.90.32[37349])
vsys1 216.58.212.163[443]/Zone-UnTrust (216.58.212.163[443])
25478 ssl ACTIVE FLOW *NS 192.168.16.48[60674]/Zone-Trust2016/6 (10.193.90.32[43548])
vsys1 216.58.212.163[443]/Zone-UnTrust (216.58.212.163[443])
25474 ssl ACTIVE FLOW *NS 192.168.16.48[60671]/Zone-Trust2016/6 (10.193.90.32[31994])
vsys1 216.58.212.163[443]/Zone-UnTrust (216.58.212.163[443])
25479 google-base ACTIVE FLOW *NS 192.168.16.48[60675]/Zone-Trust2016/6 (10.193.90.32[15527])
vsys1 216.58.212.163[443]/Zone-UnTrust (216.58.212.163[443])
25538 web-browsing ACTIVE FLOW *NS 192.168.16.48[60710]/Zone-Trust2016/6 (10.193.90.32[17185])
vsys1 68.232.35.180[443]/Zone-UnTrust (68.232.35.180[443])
25473 ssl ACTIVE FLOW *NS 192.168.16.48[60669]/Zone-Trust2016/6 (10.193.90.32[35255])
vsys1 216.58.212.163[443]/Zone-UnTrust (216.58.212.163[443])

A deeper look into the session shows that we have application type identified as SSL.

admin@Faith-PFW-X1> show session id 25473

Session 25473

c2s flow:
source: 192.168.16.48 [Zone-Trust2016]
dst: 216.58.212.163
proto: 6
sport: 60669 dport: 443
state: INIT type: FLOW
src user: unknown
dst user: unknown

s2c flow:
source: 216.58.212.163 [Zone-UnTrust]
dst: 10.193.90.32
proto: 6
sport: 443 dport: 35255
state: INIT type: FLOW
src user: unknown
dst user: unknown

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

Explanation

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.

See also

How much data is necessary to recognize an application