ssl decrypt exempt and C2C

[MP18]

we need to do do ssl decrypt exempt for number of domains.
this we are doing as per vendor requirement so that application can run without ssl decrypt 

1>Need to know if traffic is not decrypted and end user pc gets infected
can c2c in url filtering profile can block this traffic?
we have action of c2c as block right now.

2>if for example the domain live.com is not decrypted and say
someone puts bad data in that domain example like gambling or malware etc

will PA url filtering block the gambling data if url filtering is set to block?

if this pc gets infected will 2c block the in fected pc traffic back to internet?

[BPry · Accepted solution]

---

@MP18 wrote:

we need to do do ssl decrypt exempt for number of domains.
this we are doing as per vendor requirement so that application can run without ssl decrypt 

1>Need to know if traffic is not decrypted and end user pc gets infected
can c2c in url filtering profile can block this traffic?
we have action of c2c as block right now.

2>if for example the domain live.com is not decrypted and say
someone puts bad data in that domain example like gambling or malware etc

will PA url filtering block the gambling data if url filtering is set to block?

if this pc gets infected will 2c block the in fected pc traffic back to internet?

---

1) Only if the traffic can actually be identified via the information the firewall can see in a non-decrypted traffic session. So if example.com is labeled as c2c then yes it will be blocked as even unencrypted traffic we can get the domain from the certificate. 

An example of where this wouldn't work is if example.com/malware was labeled as c2c. The only thing the firewall can see with unencrypted traffic would be example.com, so you'd miss that one and the traffic would be allowed. 

2) URL Filtering will only see live.com and not necessary the content from anything actually served by the URL in question as it doesn't get the full path.

Essentially encrypted URL Filtering the firewall only has limited visability into the URL information. Usually only the server certificate that is passed to the client during the handshake is analyzed as that's the only visible part of the traffic. So while it would be able to see example.com, it wouldn't be able to see example.com/malware. 

[atul.srivastava]

Multiple points for consideration:

1.

Usually PA will block the URL you are planning to add in no decrypt policy if it marked as malicious/threat by URL database in PA FW. Moreover if a Company security policy allowing this which means its a allowed legitimate domain or unless some home grown application is cultured by your company for its customised testing and implementaion.

Lets assume the Domain you are about to include in "no-decrypt" policy is not legitimate and somehow bypassed the access profiling of your network and HIPS and caused end device compromised.

Now for any C2C operation, the malware will try to connect to public domain for further action at some stage. Their are multiple checks in place in PA FW when it comes network traffic profiling, DNS Sinkholing config is one of the example.

As long as necessary Virus, spyware, fileblocking and wildfire profiles are in place for the traffic reaching out to Internet and Saas/DC environment, it should be okay.

2.

 PA FW will not block the URL "without decryption" provided:

-URL is not in block list in FW url database and is not reported malicious by Wildfire

-URL is not blocked in custom "BLACKLIST-URL" list

Moreover any malicious site comes with some bad intention of malign purpose. Though the URL wont be dropped at PA firewall level but the moment this traffic decrypted at user computer, action will be blocked at that level depend upon the user action related to that site and security parameters in place.

Thanks

[MP18]

thanks for great explanation.

one follow up is why PA can not block example.com/malware?

is this because PA can only see example.com in the certificate?

[BPry]

@MP18,

Correct, the handshake only exposes the server certificate, it does not expose the exact URL the endpoint is visiting. 

[atul.srivastava · Accepted solution]

PA FW method of dealing any  packet is very impressive. The moment PA see the traffic as tunneled SSL traffic and found that Content inspection is not allowed(as no-decrypt is configured), it wont care the payload inside the establised encrypted SSL connection. From PA point of view, it just see the layer 3 and layer 4 information and not even care of the certificate since the client server authetication establishment is already done between client browser and the server hosting the webpage. The entire path is now encrypted between client machine and server. PA will check the server trusted digital signature and will take appropriate action if its performing SSL forwarding or SSL inbound inspection between Client and destination domain.

Hence for your question, PA will only see IP address of example.com in this case and nothing else. It can only see any extention if it can check the content.

Thanks