Home Decryption on a PA-220.

[Gareth.Doyle]

I have a PA-220 at home and want to use it to obviously protect my home, but also to help prevent my children from accessing things I feel inappropriate. 

Obviously with encrypted traffic from things like gaming consoles and phones this is harder to do and decryption is required. 

My question is, what is the best way to implement decryption on traffic from these devices without breaking connectivity due to MITM issues? Can I get a cert from a CA and use that as the proxy forwarding certificate or is there something in particular I need to do to implement this?

Thanks!

[aleksandar.astardzhiev]

Hi @Gareth.Doyle ,

The short answer is no, you cannot "ask for cert from CA". But I want you to think about why is not possible, because this is common misunderstanding of how the SSL certificates and decryption are working.

- When you want to establish encrypted connection to web server, you need to make sure that the server you are talking to is the correct server and not some imposter.

- For that purpose the web server send you its SSL certificate, which contains some information that it can be used to validate the identity of the server.

- But what is stopping me from pretending that I am the real server, by sending you a peace of paper that says "I am google, you can trust me".

- Here comes the Certificate Authorities (CA). CA are responsible to validate the information on this peace of paper and if the information is correct, they will sign it as proof that is real.

- Every browser/application/device has "certificate store" that contains a list of CAs that this app/device will trust. If you receive certificate from web server that is signed by CA in your cert store you know that this information is correct and you connect to the real web server.

(This is very brief and simplified explanation of who your device is evaluating the web server certificate)

- When you want to inspect the traffic between the web server and the client, you need to decrypt it, but this is not really possible if you only sitting in between, because the keys used for encryption/decryption are never sent through and only the endpoints know what is the key.

- For that reason any modern network security device is actually creating two connection - one from client to device and one from device to server. For the client (end user) it believes it is communicating with real sever the whole time, and for the web server it believes the network device is the actual client.

- This also means that network sec device (lets call it firewall) will create two encrypted connection, but for each it will act as client and of the other as server.

- Because firewall needs to "pretend" it is the real server it needs to "forge" SSL certificate that it will use to communicate with the client (end user). It cannot use its own cert (putting its own name), because this will be very confusing (you open google.com, but receive reply from myfirewall.local).

- Forging SSL cert, means that firewall will create this certificate on the fly (in the moment you want to communicate with the web server), and put details to impersonate the web site.

- As mentioned above, every server certificate must be signed by CA. And your device/application must trust this CA, or it will figure out that the received certificate is forged and not from the real web server, but created from imposter that cannot be trusted.

- Here comes the self-signed CA or internal PKI. For home or lab it is most common to use self-signed CA (CA that you have created on your firewall or on any other device with OpenSSL tools). But this means that you must install that CA to every certificate store that your devices are using.

- But think for a moment, when you visit web page (encrypted), you will receive different cert (for google, facebook, etc) and firewall will use the same CA to sign them.

Now lets get back to your question - Imagine just for a moment, that publicly trusted CA gives you their signing certificate, so you can install it on your firewall...Now you can decrypt any web site, without installing self-signed CAs on your devices (great), BUT....this also means that everybody in the world will trust any certificate that is created and signed by you...Which means you can decrypt everybody's traffic, what can stop you from doing this (only that you promise to not use is for bad thinks). Basically you are asking publicly trusted CA to handover to you their authority and their business, nothing is stopping you from selling certificates the same way like any CA.

I hope you can understand my explanation, why you cannot use public CA for forwarding proxy, so if you really want full decryption there is no workaround for that - you need self-signed CA, that must be installed on all of your devices.

If there are devices that you cannot install your CA on it, there are still some level of protection:

- First you can still apply Decryption rule, but with action no-decrypt. This will not decrypt the traffic, but will apply the decryption profile, which will block sessions with invalid certificates, or such that are using weak encryption. Not sure if this will bring you any real benefit in home environment

- Even with no decryption, you can still apply URL filtering. Firewall will not  be able to look at the actual data to see the full URL/URI, but it will see the Common Name (CN) and Subject Alternative Name (SAN) from the server certificate so it can still have some idea what resource might be requested. For example, if you open https://fun.com/guns (just example), it will see that server cert is for fun.com and categorized as appropriate, but it will not see that you are looking at violent content on that site. So it will rely on more general categorization (for the whole domain, not particular content).

- And because CN and SAN are part of the ssl/tls certificate, URL categorization/filtering will work even for non web-based traffic, as long as it is using SSL/TLS encryption and SSL certificates. So you should be able to create custom URL categories with list of FQDNs and use it as matching criteria for your security rule (to allow traffic only to specific list of hosts), or you can add it to URL filtering profile and allow/block traffic based on URL categories.

[Gareth.Doyle]

Hey, I appreciate that long reply! I understand how the process works, but typically I work in an Enterprise environment where we use our Enterprise root certificate and install that cert chain on all pertinent devices and key stores. I didn't want to install a public cert, I wanted to get my own cert from a CA and use that as the decryption cert to create the proxied connection.  

I haven't tried the URL filtering.to resolve blocking YouTube and those types of things from the gaming consoles, I'll give that a try. 

[OtakarKlier]

Hello,

An inexpensive solution would be to create a self signed certificate and install it onto the devices.

Regards,

[Gareth.Doyle]

Yeah, I thought about that, but from the cursory lookups I did I don't think there's a way to do that on consoles like Xbox and PS4.

[OtakarKlier]

Hello,

I would probably not decrypt that data if its going to gaming sites. It might break it or put a huge load onto the PAN that gameplay might be horrible.

Regards,

[aleksandar.astardzhiev]

---

@Gareth.Doyle wrote:

 I wanted to get my own cert from a CA and use that as the decryption cert to create the proxied connection.  

---

 @Gareth.Doyle 

Either I am not able to understand you, or you still mixing SSL Inbound decryption and SSL forwarding proxy decryption. For inspecting outbound traffic, firewall need CA certificate that it will use to sign the certificates that are created on the fly, during decryption for outbound traffic. For outbound traffic decryption firewall will act as CA in order to sign the "fake" certs used for connection between user and fw.

There is no public CA that will give you CA certificate that is signed by them (because you again can do bad thinks with it). So public CA will sell/give/issue you only server certificate. Such certificate you can use only for inbound decryption (if users from internet are connecting to your server behind the fw).

The only option you have is to use internal CA, this includes self-signed CA or Internal PKI (Enterprise root cert). But this means that your devices needs to have this internal CA installed. Palo Alto firewall allows you to create self-signed CA (Device -> Certificates -> Generate -> enable the check for CA), after that you have to install it on all devices.

To sum up - you have to use self-signed CA, that must be installed on all devices for decrypt outbound traffic. There is no way around this.

As @OtakarKlier suggest it is good to take a step back and reconsider which traffic do you want to decrypt. What is your goal for decrypting traffic from gaming consoles?

I would suggest you to take the "whitelisting" approach - enable decryption for all outbound traffic (this includes installing CA cert on all devices where possible). After that you can start creating decryption whitelisting/bypassing for traffic that cannot be decrypted but you know that it should be allowed.

[Gareth.Doyle]

The URL category did not work. I'm not sure what URLs the gaming console is reaching out to, but none of them are similar to what typical computer connectivity uses. I'm going to block QUIC traffic and that might help some, it definitely will for decryption as QUIC traffic cannot be decrypted. 

I don't want to decrypt game traffic, only things from the gaming console such as YouTube and internet browsing traffic. This the decryption is needed.

[BPry]

@Gareth.Doyle,

You can't install a certificate on an Xbox (I would assume Playstation as well) which means you won't be able to inspect this traffic at all. I would setup a reservation for the gaming systems and exclude them from decryption (the performance hit on gaming would also likely be pretty bad). 

[Gareth.Doyle]

---

@BPry wrote:

@Gareth.Doyle,

You can't install a certificate on an Xbox (I would assume Playstation as well) which means you won't be able to inspect this traffic at all. I would setup a reservation for the gaming systems and exclude them from decryption (the performance hit on gaming would also likely be pretty bad). 

---

Yeah, unfortunately that is the only traffic I want to decrypt, haha. I might try it and see what the results are anyway.

[aleksandar.astardzhiev]

@Gareth.Doyle 

---

@Gareth.Doyle wrote:

The URL category did not work. I'm not sure what URLs the gaming console is reaching out to, but none of them are similar to what typical computer connectivity uses.

---

Create URL Filtering profile and set all categories to "alert", except for those you definately want to block - those you can directly put with action "block". Put this profile on rule that is allow traffic form your consoles to Internet.

This will make sure that your firewall create a log for any URL that is able to recognize from SSL certificate. Go to Monitor -> URL logs and search with source IP address, you if you see any entries, that firewall is able to grab fqdn from the SSL certificate. As I mentioned this will be true as long as firewall is identifing the application as "web-browsing" or "ssl". Without decryption most of the traffic that is using SSL/TLS encryption will be categorizes as "ssl".

Probably "URL category did not work", because consoles are using QUICK. So you can block QUICK to force them to falback to standard TCP and check the URL logs again.

"I'm not sure what URLs the gaming console is reaching out to, but none of them are similar to what typical computer connectivity uses" - I am not sure what you mean by that, but it is irrelevant if the firewall is not able to grab the fqdn from server certificate.

[Gareth.Doyle]

While it isn't the exact behavior I want, I determined that if I added 1e100.net and *.1e100.net to the custom URL category I created, then add that to the block rule, it blocks all youtube traffic. Granted, this will also block any google related traffic, but it is configured just for the gaming console sources, so I'm not concerned at this point.