By Charles Buege, Fuel User Group Member | Tuesday, November 14, 2017

My name is Charles and I’ve been trying to implement SSL Decryption for eight months. I’m likely one of many who has encountered issues, and I’d like to share my story so you know you aren’t alone.

When we first implemented Palo Alto Networks (a pair of PA-3020’s setup in high availability), a plan was created for SSL Decryption from day one. We knew we’d implement it eventually and put a decryption rule in place for three URL categories to be bypassed for SSL Decryption: Banking, Health, and a Custom URL category that we would maintain.  

We didn’t want to run the risk of anyone thinking our company would collect this data, so we wanted this ignored before we did any testing. After those three URL categories, everything else would be decrypted. The firewall was ready to start doing SSL decryption, so we’d see what was needed to implement it.

A little background before I proceed. 

My company has been around for over 75 years. They can be “old school” in many ways, but realize when it comes to computers, the internet, and viruses and security, there are plenty of bad things out there. 

Additionally, my users have a wide range of experience. Some use green screens all day and wouldn’t notice if they had a 10MB network connection or not. On the other end, if some don’t have a ping time to the internet of less than 20ms, they tell IT “the internet is slow again.” 

They also like doing what makes their lives easiest, including bringing in personal equipment like laptops, phones, or tablets. This is usually done with little to no notification to IT until that resource is needed for work with access at home.

Due to my company’s “old school” mentality, IT has to support a variety of platforms, systems, and users who know just enough about technology to be very dangerous.

Perhaps most importantly, this has taken so long due to being a small company. We have about 500 employees, roughly 300 of which are computer users and the rest are manufacturing personnel on our shop floor. Our IT staff has eight employees – three developers, two support personnel, a program manager/Google administrator and developer, a Director of IT, and me.

So why does IT let our users bring in personal equipment? The truth is we don’t have a real security policy, usage policy, or BYOD policy in place. The good news is my team and I are developing these policies, but for the time being I can’t do much. I just have to deal with it.

What does this have to do with SSL Decryption?  

When I first looked into implementing SSL Decryption, I thought: if we have problems, we’ll handle them one by one. It was quickly discovered that, before I turned it on, there were several impediments to getting this rolled out.

In my small test environment of four or five dummy VMs, I was able to use group policy objects (GPOs) to deploy our Palo Alto Networks’ root certificate authority (CA) to my users, which worked with Chrome and Internet Explorer. We were migrating from Lotus Notes to Google Mail, so our recommendation to users was the adoption of Chrome as the primary browser. This was fine, but we needed to support Firefox, too, as some did not want to leave Firefox. This was stumbling block number one.

I started researching how Firefox handled certificates and discovered the version most were using at the time (48, 49, and a few at 50) did not support reading the Windows certificate store, which meant each Firefox user needed Palo Alto Networks’ CA installed.

I read Firefox was looking to move from their own certificate stores to reading the OS’s certificate store, but that was under development or in beta. That meant one of two things: we needed to create instructions for more experienced users on importing the CA themselves or, for our less tech-enabled users, a way to “auto-magically” import the CA into Firefox. Then, I realized something else – we were getting more and more Mac users.

A solution would be needed for these users. How could I get the CA deployed to the Macs? They were not part of the Windows domain, so I couldn’t do anything with GPO to get those deployed. Could I use something in Google’s infrastructure to deploy the CA to our users? What about Firefox for Mac? For Safari, I got lucky and found it read the same certificate store as Chrome, so if I could get Google to deploy the CA, I would be fine.

But, wait! Weren’t our engineers using Linux? My suspicion was confirmed: not only were they using Linux, but several different distributions of Linux. Fedora, CentOS, Ubuntu, and Debian, to name a few.

We also have Chromebooks on our physical network that aren’t members of our Google infrastructure. While most of these never go to the internet, some send data directly to our customers via RESTful APIs. 

Another complication

We wanted to implement auto-connect, full tunnel VPN connectivity. A number of our users now VPN into work with their own machines at home, because we haven’t refreshed our entire user fleet of partial remote users yet to get them laptops. Does this mean we insist they have the CA installed at home? If they want to VPN from there, yes, it would be needed. Is this right? Do we want home users’ machines to come through the VPN and track their internet traffic, minus the banking and health sites, of course?

When I realized the need to install Palo Alto Networks’ CA on the Macs, I reviewed what I had found thus far with my IT director. We discussed my concerns about moving forward and what should be done before moving further with this SSL decryption project.

Here is what we determined:

• SSL Decryption is on hold for now.
• We need a Written Information Security Policy (WISP).
• We must have our executive team’s support for developing, deploying, and enforcing the WISP and subsequent policies, including internet usage, BYOD, security, and others.

Without the support of the executive team, any IT policy written and deployed will have the following problems:

• The policy will be utterly toothless.
• Anything IT tries to implement will be a hindrance to our employees getting work done.
• We will leave ourselves open for more security issues as attacks become more nefarious.

After much deliberation, we decided we are going to subnet our network. For us, it will be pretty easy – just a few changes to the DHCP configuration on our network and we should be set. Devices that can't easily have the CA installed onto it without our IT support personnel touching each system will be in a subnet that won't have the SSL Decryption enforced until we can either figure a way to get it to those machines automatically or have our IT Support personnel manually install it on those systems. After that, as each subnet has been fully 'patched' to include the CA, we will roll those subnets into the SSL Decryption policy and be off and going.

Thank you for reading my story. Best of luck to you in your implementations and may your systems be as secure as possible!

Do you have thoughts on Charles’s story or similar experiences? Share your comments and post a discussion to connect with other Fuel User Group Members.