Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Decrypted SSL to web-browsing question

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

Decrypted SSL to web-browsing question

L4 Transporter

I've been playing around with a new service we're bringing online that has an Internet facing site using our public cert.  I decided to go ahead and stick Inbound decryption on it and, of course, this means my SSL now looks like web-browsing over TCP 443.

 

What I'm not sure on is what the actual best practice is here.  I know this has been a long standing issue from people to Palo Alto about doing something better here as it seems like you pretty much have to create multiple security policies (i.e. one that has application-default for any of the other apps the server will accept and a second one for web-browsing over TCP/443 service) per server you want to apply inbound decryption to.

 

Is it possible to just make a custom app for "secure web-browsing" and have it remain generic enough that it could apply to any traffic where we're using decryption to get visibility into SSL or would we have to apply signatures that would pretty much mean we'd need one custom app per server?

 

I did try creating a custom app with TCP/443 and applying web-browsing as the parent app but I don't think it works without any custom signatures (traffic is still identifying as web-browsing).

 

Thanks!

3 REPLIES 3

Cyber Elite
Cyber Elite

@jsalmans,

I've never been able to get them to give a best-practice for this, other than creating two seperate policies. We talked about it at length last Ignite and it was basically stated that they couldn't easily do anything about it due to technical limitations of how the app-id process works. 

@BPry,

 

Well that's a bit annoying.  I wish applications could simply have a second behavoir set/rules if the traffic was decrypted first.  I.E. web-browsing is only allowed over tcp/80 except for if the traffic it was contained in was decrypted and would then be allowed over tcp/443 instead.

 

Alternatively it would be nice to be able to assign services to specific applications when building a Security Policy instead of the services being allowed for every application allowed in the rule.  I just hate having to do multiple rules when one will do.

 

So I guess the two options are:

  • Make a separate rule for every decryption situation that decrypts to web-browsing to allow it over tcp/443
  • Create a custom application per service/server with parent app web-browsing and with signatures that will contrain it to that specific service/server

One solution means more security policy rules, the other means a bunch of basically duplicated custom applications for "secure web browsing" but with small changes in signatures per whatever service or server they're running against.

@jsalmans,

Your not wrong, one of the pain points of getting people setup on SSL-Decryption correctly is trying to explain this point to them as it's rather counter intuitive. Of the two options that you mentioned in your post, option two would obviously be what's going to be your best practice in this particular position. 

I've seen a lot of people simply allow apps [ ssl web-browsing ] and setting the service as [ service-http service-https ] so they don't have to setup an additional policy. This would allow the traffic to pass over 80 or 443 as long as it's identified as ssl or web-browsing. NOT the best solution, but it works. 

  • 2475 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!