SSL forward proxy with real certificate

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

SSL forward proxy with real certificate

L0 Member

I have gone through some topics related to SSL decryption with forward proxy.

 

Here is something that I need to learn how to resolve. We need to decrypt everything for PC/laptop/mobile.

With wireless, if we have 1 SSID, then the laptop & phone can be used then we can assign our generated root cert from Windows Server to the laptop & PC without any issues.

 

Now this is something very challenge

 

1. If we have xxx number phone, then it can become forever if we need to install root cert into the phone manually
2. Let's say we separate 2 SSID, 1 for phone and the other for laptop, and we accept that give up decrypting on the network attached to the phone SSID
- What if the laptop joins to the phone SSID then we lose the decryption policy we must apply? Does PA have any solution on this?
- If the phone joins to the laptop SSID then yes, they need to add root cert, which is ok.

If PA has a solution to use the real cert that buys from some company like GlobalSign of Geotrust and make it forward proxy then i think it can resolve my case easily

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

@HiepDuong,

You have multiple different options:

 

1) If the phone is issued by your company or otherwise a part of a BYOD policy, you should be managing the endpoint with some sort of MDM. All of them can push a trusted certificate which would eliminate the issue that your seeing with the certificate. Keep in mind that most mobile applications utilize certificate pinning.

 

2) Create an Issued SSID and a Personal device SSID. In general this is just good practice so you don't have someone's personal device sitting with devices you've issued out. On the laptop side of things utilize group policy and deploy a 'Wireless Network (IEEE 802.11) Policy'  and add the SSID you've deployed to the phone use as a blocked network. This will prevent anyone from joining that SSID (or any named to match your SSID) from being used on anything pulling group policy. 

 

3) Configure an Always-On GlobalProtect connection and it won't matter what SSID your laptops utilize. If they connect to anything not managed by you it'll just connect via GlobalProtect back to your environment and you can decrypt all of that traffic without issue. 

 

I personally think it sounds like you need to do a couple of things. If you aren't segmenting issued device traffic from a device your coworker is just bringing in and connecting to wireless I'd consider that a big issue. Your issued devices should all utilize one SSID authenticated preferably through certificates or configured with a PSK unbeknownst to your end user. The personal devices should all use a completely separate SSID that puts them on an isolated network segment to prevent pollution of clients.

When it comes to your laptops, they should be connecting to GlobalProtect whenever they leave your internal network. This way it doesn't matter if the laptop joins the personal SSID or not, because if they join the wrong one it's just going to VPN back to your firewall and be treated as a connected endpoint. If they complain about the speed of the connection you can point out that they're on the wrong SSID. The always-on connection is something I would deploy regardless, but this configuration does potentially allow you to keep a single SSID and you can just treat every single device like a personal endpoint since the laptops will all VPN back in.

Lastly 802.11 policies are often overlooked on smaller networks, but if you're already using group policy they just make everything easier. Pre-specify every SSID you know that they'll need to connect to, block SSIDs you don't want them connecting to if you have any, and stop giving people the password to your internal SSID. 

View solution in original post

3 REPLIES 3

Cyber Elite
Cyber Elite

@HiepDuong,

There's no way around installing the certificate for decryption. Nobody is going to sell you a CA or sub-CA certificate that would be just trusted by a random client, nor should they as that's incredibly insecure for devices you don't actually own or manage. That would allow anyone running a network to just MiTM all of your traffic without the end device ever seeing it's happening; that's why the certificate import process is required.

 

Do you own the phones and laptops in question? If you do, an MDM or in the case of Windows Active Directory and Group Policy would take care of this issue for you. If you don't own the devices in question, installing the root certificate would be a prerequisite of using the network that you could detail in a captive portal on the SSID if you wanted to. 

L0 Member

@BPry 

 

Thank you for your feedback. I understand MiTM and just try to find if any better idea. As said, we dont see any issues with laptop / desktop cause we can apply from Windows AD Group Policy.

 

The problem is the phone.

 

I think we have to build 2 SSID where 1 for laptop and the other for the phone then we decrypt for SSID where the phone is. However, if the phone join to laptop then they cannot access it until we install the root cert. However, I still dont know how to block laptop if they access phone SSID. Is that something that PA can handle or we need other NAC solution?

 

Thanks
 

Cyber Elite
Cyber Elite

@HiepDuong,

You have multiple different options:

 

1) If the phone is issued by your company or otherwise a part of a BYOD policy, you should be managing the endpoint with some sort of MDM. All of them can push a trusted certificate which would eliminate the issue that your seeing with the certificate. Keep in mind that most mobile applications utilize certificate pinning.

 

2) Create an Issued SSID and a Personal device SSID. In general this is just good practice so you don't have someone's personal device sitting with devices you've issued out. On the laptop side of things utilize group policy and deploy a 'Wireless Network (IEEE 802.11) Policy'  and add the SSID you've deployed to the phone use as a blocked network. This will prevent anyone from joining that SSID (or any named to match your SSID) from being used on anything pulling group policy. 

 

3) Configure an Always-On GlobalProtect connection and it won't matter what SSID your laptops utilize. If they connect to anything not managed by you it'll just connect via GlobalProtect back to your environment and you can decrypt all of that traffic without issue. 

 

I personally think it sounds like you need to do a couple of things. If you aren't segmenting issued device traffic from a device your coworker is just bringing in and connecting to wireless I'd consider that a big issue. Your issued devices should all utilize one SSID authenticated preferably through certificates or configured with a PSK unbeknownst to your end user. The personal devices should all use a completely separate SSID that puts them on an isolated network segment to prevent pollution of clients.

When it comes to your laptops, they should be connecting to GlobalProtect whenever they leave your internal network. This way it doesn't matter if the laptop joins the personal SSID or not, because if they join the wrong one it's just going to VPN back to your firewall and be treated as a connected endpoint. If they complain about the speed of the connection you can point out that they're on the wrong SSID. The always-on connection is something I would deploy regardless, but this configuration does potentially allow you to keep a single SSID and you can just treat every single device like a personal endpoint since the laptops will all VPN back in.

Lastly 802.11 policies are often overlooked on smaller networks, but if you're already using group policy they just make everything easier. Pre-specify every SSID you know that they'll need to connect to, block SSIDs you don't want them connecting to if you have any, and stop giving people the password to your internal SSID. 

  • 1 accepted solution
  • 2010 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!