03-23-2021 06:30 PM
We have an issue with a thick client application (AWS Workspaces client) connecting successfully to the AWS workspace over the internet. The palo alto firewall logs shows the traffic is allowed but the type is 'deny' instead of 'end'. Also session end reason is "decrypt error". Now we think we understand that the URL’s the client application is trying to connect to is failing to be forward proxy decrypted by the firewall because the client itself doesn't have a certificate for the firewall to validate. We believe the client itself does not use the user/computer certificate store but rather uses a certificate built in to the client directly. Hence the reason why the decryption is failing. We would like to understand how best to treat this issue i.e.
1) do we try and request the certificate from AWS (vendor) and import onto the firewall? Will that work?
2) Do we add the URL’s to a no decryption exception list so that they don’t attempt to get decrypted. In which case the second part of my question will be, how do I get the URL’s this client is using so that they can be excepted? we already tried a packet capture and looked into the TLS section with the Server Name Information and excepted those. However, it still failed to work.
I know its decryption, because when I allow everything from a specific PC to not be decrypted, it works fine. However I can’t allow a blanket rule for no decryption from users, as that would defeat the purpose of having decryption enabled.
03-24-2021 06:33 AM
I can't speak specifically for AWS Workspaces, but most VDI clients like that would utilize certificate pinning so that they can't be proxied. So the client is looking for a very specific certificate when it attempts to decrypt the traffic, and if it's not matching what is expected it won't form a connection.
As for getting the URLs, there's a few ways to do this. One is to use WireShark or something similar and attempt to get all of the SNIs, and the next is to simply create a URL Filtering profile to alert on all of your categories on a test client so that it gets fully recorded in your URL logs.
03-24-2021 06:33 AM
I can't speak specifically for AWS Workspaces, but most VDI clients like that would utilize certificate pinning so that they can't be proxied. So the client is looking for a very specific certificate when it attempts to decrypt the traffic, and if it's not matching what is expected it won't form a connection.
As for getting the URLs, there's a few ways to do this. One is to use WireShark or something similar and attempt to get all of the SNIs, and the next is to simply create a URL Filtering profile to alert on all of your categories on a test client so that it gets fully recorded in your URL logs.
03-26-2021 02:31 AM - edited 03-26-2021 03:35 AM
The other option is just to see the IP addresses and domains that Amzon workspace wants to be allowed by any proxy or firewall and add them manually or using EDL:
https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
