Session SSL décryptée marquée comme application SSL

Demande client

Nous savons que le décryptage SSL est censé nous donner la visibilité du trafic qui serait autrement crypté. Par conséquent, nous nous attendons à ce que le trafic déchiffré soit identifié comme les applications sous-jacentes, telles que la navigation sur le Web, Facebook-base ou autre, mais pas comme SSL. Toutefois, dans certains scénarios, voir application SSL comme déchiffrée est un comportement attendu. Cet article couvre un tel scénario et explique pourquoi une session SSL décryptée identifiée comme application SSL est, dans ce cas, considérée OK. 

Dans L'exemple ci-dessous, nous avons essayé d'accéder au site Web suivant: 

https://My.VMware.com/Web/VMware/login

À partir de la table de session, nous pouvons voir que la session est marquée comme décryptée (*)

admin @ Faith-PFW-x1 > Show session tous les filtres SSL-décrypter Oui

--------------------------------------------------------------------------------
ID application État type Flag SRC [Sport]/zone/proto (traduit IP [port])
VSys DST [dport]/zone (traduit 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 flux actif *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 flux actif * 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 navigation sur le Web flux actif * 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])

Un regard plus approfondi dans la session montre que nous avons le type d'application identifié comme 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
État: init type: Flow
src utilisateur: Unknown
DST utilisateur: inconnu

S2C Flow:
source: 216.58.212.163 [zone-non-Trust]
DST: 10.193.90.32
proto: 6
sport: 443 dport: 35255
État: init type: Flow
src utilisateur: inconnu
DST utilisateur: inconnu

heure de début: Mar Jun 21 11:37:52 2016
timeout: 15 sec nombre
total d'octets (C2S): 796 nombre
total d'octets (S2C): 4759
layer7 de paquets (C2S): 8
layer7 de paquets (S2C): 8
VSys: Vsys1
application: SSL
règle: Trust 2016 à
session Internet pour être connecté à la fin: vraie
session en session Agere: false
session mise à jour par ha Peer: false
Address/port traduction: source
NAT-règle: NAT Trust 2016 à Internet (vsys1)
layer7 traitement:
filtrage d'URL terminé activé: false
session Via syn-cookies: false
session terminée sur l'hôte: false
session traverse tunnel: false
captive Portal session: false ingresse
interface: ethernet1/3
sortie interface: ethernet1/6
session règle de QoS: N/A (classe 4)
Firewall étape Tracker: TCP FIN
Tracker étape l7proc: proxy Timer expiré
fin-raison: TCP-fin

Explication

Lorsque la session est décryptée, la recherche d'ID app est déclenchée sur le flux déchiffré pour aider à identifier l'application de session. Le pare-feu doit lire suffisamment de paquets de données afin d'identifier l'application. Une fois la poignée de main SSL terminée, nous devons lire un maximum de 2000 octets de données pour déterminer si l'application est inconnue ou non. Lorsque le décodeur est détecté, par exemple navigation sur le Web, il peut prendre plus de 5 paquets pour déterminer l'application réelle. Dans la plupart des cas, l'application sera reconnue avant de recevoir cette quantité de données.

En regardant la sortie de capture de paquets ci-dessous, nous voyons que la communication a pris fin avant l'échange de données d'application qui aurait permis au pare-feu d'identifier l'application. 

Cela s'appliquerait également si le protocole TLS/SSL standard est enroulé autour d'une application personnalisée: l'application sous-jacente serait "inconnu-TCP" si elle n'était pas cryptée, mais en raison du cryptage, app-ID a déjà identifié SSL et gardera cela comme l'application. 

Nous espérons que vous trouverez cette information utile. S'il vous plaît laissez un pouce vers le haut ou un commentaire dans la section ci-dessous.

Voir aussi

Combien de données est nécessaire pour reconnaître une application