- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Application control detects encrypted traffic
Hi experts,
How can Application Control detect applications over encrypted traffic? I am using Application Control and works fine, I can block youtube videos, facebook and so on, over HTTPS, so the traffic is encrypted. But I am not enabling deep inspection and it can detects applications anyway. How can Application Control do this without enabling deep inspection?
Regards,
Julián
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Additionally, Application Control probably looks at the Server Name Indication (SNI) header at the start of the TLS handshake process and tags that TLS stream accordingly. The SNI (usually the domain name of the server. eg. "www.google.com") is normally passed unencrypted during the initial handshake process. You can see this in Wireshark. Look under "Extension: server_name" in a Client Hello packet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Julián,
As previous posts have pointed out, not all data in a SSL session are encrypted. The SSL handshake messages are plaintext and readable. The SNI extension in "Client Hello" msg tells where the traffic goes to, thus it can be used by APPCtl to do the basic checking. The 'deep-inspection' offers more. If you want to see the content of pages and check them more subtly, then you have to use it.
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi guys,
Any idea? The question is short, how can FortiGate recognise application patterns within the traffic when this is encrypted? Deep inspection is not being used.
Regards,
Julián
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
URL's and ip-ranges already reveal a lot, I guess.
Maybe packet headers also contain very specific things.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi dieter,
It could be, but Application control doesn't work with URL's as Web filtering does. According to NSE4, it matches patterns in the entire byte stream of the packet, and then looks for patterns, and not only works with the packet headers.
Regards,
Julián
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Additionally, Application Control probably looks at the Server Name Indication (SNI) header at the start of the TLS handshake process and tags that TLS stream accordingly. The SNI (usually the domain name of the server. eg. "www.google.com") is normally passed unencrypted during the initial handshake process. You can see this in Wireshark. Look under "Extension: server_name" in a Client Hello packet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jacob,
Then you mean that Application Control looks at the SNI and according to that SNI category it blocks or allows the traffic?
Regards,
Julián
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Julián,
As previous posts have pointed out, not all data in a SSL session are encrypted. The SSL handshake messages are plaintext and readable. The SNI extension in "Client Hello" msg tells where the traffic goes to, thus it can be used by APPCtl to do the basic checking. The 'deep-inspection' offers more. If you want to see the content of pages and check them more subtly, then you have to use it.
Regards
