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

PAN-OS 7.1 - SSL Decryption Issues

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

PAN-OS 7.1 - SSL Decryption Issues

L4 Transporter

I recently upgraded from PAN-OS 7.0.6 to 7.1.0 on a lab PA-200 appliance to start to test some of the features.  Right off the bat there seems to be an issue with SSL Decyrption.  As I stated in another post, I'm having issues with sites such as banking establishments, google earth, bing maps, etc. where the browser (chrome, edge, and IE tested) will hang, partially display data, and continue to load after the page is presented.   Disabling decryption immeidately resolves the problem.  Mind you, on 7.0.6, decryption is working without issue.

 

Anyone else that is testing PAN-OS 7.1 run into this issue?  

 

-Matt

13 REPLIES 13

L6 Presenter

Hi...There is a change to the policy behavior in 7.1 described here:  https://live.paloaltonetworks.com/t5/PAN-OS-7-1-Articles/PAN-OS-7-1-Policy-behavior-change-applicati...

 

Please double check your policy & maybe we just need to add port 443 to the security policy or not use Application=any.  

 

Thanks,

by mlinsemier a moment ago

I read this, but I don't see, in this case, how it is applicable.

 

I have a global rule it looks like this:

 

Rule: Allow Inside --> Outside : Application:any Service: application-default

 

This means that ssl traffic (https) generated from the inside network to the outside network is only allowed over of the application-default port of ssl, which is 443.  I dont see why I would need to adjust this rule as the internet sites are not using non standard web-browsing and SSL ports.

 

Additionally, if i disable encryption, the rule above works without issue.  It's specifically decryption related and there is no way to select application when configuring an SSL Forwarder.  

 

-Matt

Let's say the traffic is HTTPS where the PA would decrypt the SSL and we have web-browsing running on port 443.  Your rule is allowing web-browsing on the default port, tcp/80, so it would not match the decrypted traffic, web-browsing on tcp/443.

I'm wondering if there is any plan to add port 443 to web-browsing default port list aswell. SSL decryption is so common nowadays that to create specific policy for that to allow web-browsing on 443 is kind of stupid.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

I get what you're saying @Raido_Rattameister, but there's also an application "SSL."

 

Personally I'd rather be able to control policy down to the minute detail that I want to allow "Web-Browsing" w/o allowing access to "SSL" site.

 

So personally I don't mind where Palo is going here.

If in security policy you allow application web-browsing to specific site and don't add ssl then right after 3 way handshake Palo will identify what application it really is and no ssl is permitted if you have not specified so.

 

Currently minimum ruleset needs to be
application - any / service - application-default

application - web-browsing / service - tcp443

 

Adding 443 to web-browsing default port list would get rid of need for second rule.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

 

 

I guess I am confused.

 

My rule above, with decryption disabled, functions perfectly.  No traffic is dropped, all websites are working, etc.  This to me proves that the App-ID is properly identifying the traffic and that the traffic on application-default ports are fine.

 

As decryption is global, and is not applied to a specific security rule, how does the rule above suddenly stop working when encryption is enabled?  I dont see why I would have to add addtional rules with addtional service ports when the existing rules are already working.

 

Again, this seems pretty cut and dry to me that decryption is not working as intended.  I've had similar issues in 7.0.1 etc that acted the same way, all of them were resolved in 7.0.4+ and were decryption engine bugs.  


Perhaps you could give me an example of how I would configure it differently in 7.1 vs 7.0.6.

Can you add a new rule to allow web-browsing on port 443 to confirm please:

 

any any app=web-browsing service=tcp/443 action=allow

<your existing app=any service=app-default>

 

Let's find out if that works or not and we can discuss further.  Thanks.

Like i suspected, and kind of was eluding too above, its does not seem to be a rule issue.  It does not even hit the new rule when its created.  Traffic to, in this case www.53.com, is only ssl.  it never hits the web-browsing app-id application, therefore never hits the new rule as it's not detecting web-browsing on 443, its detecting it as ssl.

 

53.jpg

 

In your example, if it was a rule issue with applciation-default of web-browsing not including 443 service, i would have issues regardless or enabling or disabling ssl decryption.  None of my other applications other than ssl are experiencing any types of issues, and ssl is only causing issues when decryption is turned on.

 

I feel like I have things configured how they should be.  It seems as if perhaps the best path is to open a support case with Palo Alto.


Matt

If there's no decrypt policy, the traffic would be identified as app=SSL port=tcp/443 as seen in your log screenshot.  The PA would not be identifying other apps inside of that SSL session so the session stays at SSL.

 

If SSL decryption is triggerred, we would initially see the app=SSL port=tcp/443.  Once decryption occurs, the PA can see inside the SSL session and ID other apps.  However, all apps tied to this session will be running over port tcp/443.

 

I just tested with 7.1.0 and I was able to hit multiples SSL sites (bank, google, yahoo mail, gmail) and the SSL decryption worked for me.  Here's a snapshot of my traffic log where the app web-browsing was discovered after decryption and it occurs over port tcp/443.

 decrypt-log.png

 

Thanks,

Interesting... Can you send me your security rules example? Also, as this also affect other applications that could be wrapped in SSL for this session, does that mean in the case of say, RDP wrapped in SSL for View, will you now have to add 443 to the allow RDP rule? This is going to complicate the simplicity of writing rules for sure.

I will give this a shot again.

-Matt

I ended up deleting my general rule and recreating your suggested rule and my existing rule and this seemed to do the trick.  Not quite sure why this made a difference.  Perhaps I fat fingered the rule before.

 

Ultimately, I feel that something as simple as not having 443 included in the web-browsing app as a potential port is going to cause allot of grief and support tickets.  I appreciate the new method in which the rules are now handled, but we as engineers request that things remain simple.  I'm more concerned that other applications that may get bundled in SSL (but not have SSL in their app-id ports) may also fall victim to this issue.  I'm not quite sure how applications inside something such as a SSL VPN will be handled.


Thanks for the assistance in this, I learned something.

 

-Matt

I had this same issue after upgrade from 7.0.12 to 7.1.7 and so far support has not been able to figure out why my decryption stopped working. I put in a rule for web-browsing for tcp/443 as suggested in this post and my decryption seems to be working again. Great work on this post guys!

-Brad
  • 7009 Views
  • 13 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!