Management Articles

Featured Article
  Overview SSL decryption gives the Palo Alto Networks firewall the ability to see inside of secure HTTP traffic that would otherwise be hidden. SSL decryption can be used to monitor for any signs that a company's valuable intellectual property might be exiting through their network. Palo Alto Networks firewall is able to perform SSL decryption by opening up SSL traffic through an inspection process.   The following table provides a list of valuable resources on understanding and configuring SSL Decryption: TITLE DESCRIPTION TYPE BASIC     How to implement and test SSL decryption Describes how to implement and test SSL decryption Document Limitations and recommendations while implementing SSL decryption Limitations and recommendations while implementing SSL decryption Document How to view SSL decryption information from the CLI How to view SSL decryption information from the CLI Document List of applications excluded from SSL decryption List of applications that cannot be decrypted by the Palo Alto Networks device Document How to exclude a URL from SSL decryption Details the CLI commands for adding URLs to the SSL exclude list Document SSL decryption certificates How to manage SSL certificates for decrypting and inspecting SSL traffic Document How to temporarily disable SSL decryption How to temporarily disable SSL decryption without modifying the decryption policy Document How to enable/reset the opt-out page for SSL decryption How to enable the opt-out response page Document How to serve a URL response page over an HTTPS session without SSL decryption How to configure a device to serve a URL response page over an HTTPS session w/o SSL decryption Document Difference between SSL forward-proxy and inbound inspection decryption mode SSL forward-proxy and SSL inbound inspection modes Document How to create a report that includes only SSL decrypted traffic Create a report that includes only SSL decrypted traffic Document How to view decrypted traffic View decrypted traffic Document INTERMEDIATE     How to configure a decrypt mirror port on PAN-OS 6.0 Create a copy of decrypted traffic and send to a mirror port Document ADVANCED / TROUBLESHOOTING     Troubleshooting SSL Decryption using Dynamic Address Groups Automation example using the Palo Alto Networks firewall and Dynamic Address Groups (DAGs) Document How to identify root cause for SSL decryption failure issues How to identify decryption failures due to an unsupported cipher suite Document SSL vulnerability non-detection behavior is seen when inbound SSL decryption policy is set Detection of SSL relevant vulnerability by the security profile failed Document Troubleshooting slowness with traffic, management, or intermittent SSL decryption Troubleshooting intermittent SSL decryption Document SSL decryption not working due to unsupported cipher suites After configuration and import of required certificates the inbound SSL decryption is not working Document Unable to post pictures on Facebook after enabling SSL decryption After SSL decryption is enabled, user cannot connect to Facebook using HTTPs Document After configuring SSL decryption Mozilla Firefox presents certificate error SSL decryption on Mozilla Firefox showing certificate error Document SSL decryption policy is decrypting traffic for no-decrypt rules SSL Decryption policy is decrypting traffic for No-Decrypt Rules Document SSL decryption rules not matching FQDN SSL decryption rules not matching FQDN Document Google services do not work in Chrome with SSL decryption Google not working in Chrome with SSL Decryption Document Commit error received after configuring SSL decryption for certificate generation Configuring SSL decryption - commit fails after generating a certificate error Document Inbound SSL decryption fails when SSL compression is enabled Inbound SSL decryption fails Document SSL decryption stops working on Firefox after changing SSL decryption certificate After changing the SSL Decryption certificate, SSL decryption does not work for the Firefox browser Document SSL decryption opt-out timeout Display the opt-out page more frequently Document Wrong certificate used when SSL decryption is enabled Untrusted certificate presented when performing SSL Decryption Document   Note: If you have a suggestion for an article, video or discussion not included in this list please post a recommendation in the comments below and it will be added to the master list  
View full article
‎03-26-2018 02:53 AM
78,949 Views
0 Replies
5 Likes
Issue: SSL inbound policies worked ok when configured on 7.1 but after upgrading to 8.0, the sessions would fail and the logs show decrypt errors. This is seen when the server uses a certificate with an intermediate certificate in the chain.   Cause: Prior to PAN-OS 8.0, inbound inspection was completely passive. In 8.0, with ECC and DHE support it takes a more active role.   Confirmation: A packet capture on the firewall will confirm if the firewall is sending the full certificate chain or only the server certificate to the client. Check the Server hello packet which includes the certificates and if only the server certificate is sent, this may be the cause.   Fix: Re-import of the certificate from your web server to the firewall, make sure you're combining the server cert with the intermediate CA (not the root CA though).   Here are the steps to do so: https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Install-a-Chained-Certificate-Signed-by-a-Public-CA/ta-p/55523   Additional information: https://live.paloaltonetworks.com/t5/General-Topics/Panos-8-inbound-ssl-inspection/m-p/183289
View full article
jarena ‎02-08-2018 05:18 AM
8,706 Views
0 Replies
  This article discusses how PAN-OS can leverage the SNI (Server Name Indication) field to create a custom application.   What is SNI (Server Name Indication) ? SNI is an extension to the SSL/TLS protocol that indicates what hostname the client is attempting to connect to. SNI inserts the requested hostname (website address) within the TLS handshake (the browser sends it as part of ‘Client Hello’), enabling the server to determine the most appropriate SSL certificate to present to the browser.     When to use SNI to create custom applications In cases where the SNI field is consistent, it can be reliably used to identify the application. A custom application can be defined and used to control the SSL traffic without the need for SSL decryption.     Example of creating a custom application   The following example shows how to create a custom application for YouTube where the SNI field is seen as www.youtube.com (as an example only).   Analyze the traffic for consistency of the SNI field in the Client Hello:   Navigate to Objects > Application > Add. 1. Define the general properties of the application:         2. Define the port and protocol as TCP and 443 respectively, since SSL uses protocol TCP and port 443 for communication. Define the other Timeout settings as required:       3. The last and the most important part of application definition is to select the context as 'ssl-req-client-hello' and     define the required pattern as seen in the client hello SNI field:       Note:   We recommend analyzing the traffic thoroughly before creating an application signature to ensure reliability of the custom application. It is possible for the same web service to use different SNIs on different occasions, hence all possibilities must take that into consideration. The SNI field uses the hostname the client is attempting to connect to the server, hence any change in the request from the client may cease to match custom application.  
View full article
syadav ‎11-29-2017 12:28 AM
17,065 Views
4 Replies
1 Like
Overview   When ipsec tunnels terminate on a Palo Alto Networks firewall, it is possible to decrypt the traffic using the keys registered under ikemg.log. This can be very useful for troubleshooting ike, and performance issues with ipsec tunnels such as packet-loss and out-of-order packets.   Details   On this article, we will illustrate how to decrypt ikev1 on main mode and ESP packet using the following topology. The same steps can be used with ikev2. By default, the debugging level of ikemgr is normal. To log the negotiated authentication and encryption keys, we must increase the debugging level to dump.   admin@FW1> debug ike global show sw.ikedaemon.debug.global: normal admin@FW1> debug ike global on dump admin@FW1> debug ike global show sw.ikedaemon.debug.global: dump   Packets can be captured anywhere between FW1 and FW2. On our test setup, we will take packet captures on FW1 following this guide https://live.paloaltonetworks.com/t5/Learning-Articles/How-to-Run-a-Packet-Capture/ta-p/62390. To capture clear and encrypted data between User1 and User2 we are going to use the following filters.   admin@FW1> debug dataplane packet-diag show setting -------------------------------------------------------------------------------- Packet diagnosis setting: -------------------------------------------------------------------------------- Packet filter   Enabled:                   yes   Match pre-parsed packet:   no   Index 1: 192.168.112.104[0]->192.168.125.110[0], proto 0            ingress-interface any, egress-interface any, exclude non-IP            ingress-interface any, egress-interface any, exclude non-IP   Index 2: 10.193.121.91[0]->10.193.121.93[0], proto 0            ingress-interface any, egress-interface any, exclude non-IP            ingress-interface any, egress-interface any, exclude non-IP -------------------------------------------------------------------------------- Logging   Enabled:                   no   Log-throttle:              no   Sync-log-by-ticks:         yes   Features:   Counters: -------------------------------------------------------------------------------- Packet capture   Enabled:                   yes   Snaplen:                   0   Stage receive           :  file rx     Captured:     packets - 0          bytes - 0     Maximum:      packets - 0          bytes - 0   Stage transmit          :  file tx     Captured:     packets - 1          bytes - 0     Maximum:      packets - 0          bytes - 0   Stage drop              :  file dr     Captured:     packets - 0          bytes - 0     Maximum:      packets - 0          bytes - 0    At this point, we need to bounce the ipsec tunnel to start a new negotiation process and log the ipsec phase1 and phase2 keys.   admin@FW1> clear vpn ike-sa gateway TO-FW2 admin@FW1> clear vpn ipsec-sa tunnel To-FW2   Then generate Traffic between User1 and User2 and make sure that the tunnel is up.   admin@FW1> show vpn ike-sa gateway TO-FW2   IKEv1 phase-1 SAs GwID/client IP  Peer-Address           Gateway Name           Role Mode Algorithm             Established     Expiration      V  ST Xt P hase2 --------------  ------------           ------------           ---- ---- ---------             -----------     ----------      -  -- -- - ----- 1               10.193.121.93          TO-FW2               Init Main PSK/ DH2/A128/SHA1    Apr.08 21:57:04 Apr.08 22:03:04 v1 12 4  1   Show IKEv1 IKE SA: Total 2 gateways found. 1 ike sa found.   IKEv1 phase-2 SAs GwID/client IP  Peer-Address           Gateway Name           Role Algorithm          SPI(in)  SPI(out) MsgID    ST Xt --------------  ------------           ------------           ---- ---------          -------  -------- -----    -- -- 1               10.193.121.93          TO-FW2               Init ESP/ DH5/tunl/SHA2 B57366C2 B82D7CDE 547B1BD5 9  1   Show IKEv1 phase2 SA: Total 2 gateways found. 1 ike sa found.   Decrypt ikev1 on main mode.   With ikev1, the identification and quick mode messages are encrypted. Sometimes it is necessary to decrypt them to verify which parameters were exchanged between the two peer.   Here is an example of an encrypted identification message.   To decrypt ikev1 messages, we need two pieces of information.   Initiator’s cookie that corresponds to the Initiator SPI on the packet capture. 294ff0e604e73f31 Encryption key that can be found on the ikemgr.log: Search for “cookie:294ff0e604e73f31” and then scroll through the negotiation messages untill you find the final computed encryption key. 2017-04-08 21:57:04 [DEBUG]: oakley.c:3157:oakley_compute_enckey(): final encryption key computed: 2017-04-08 21:57:04 [DEBUG]: oakley.c:3158:oakley_compute_enckey(): 793f8697 cc0e8cdb 5851496c 0acff14c   Next, go to Wireshark > Edit > Preferences > Protocols > ISAKMP > IKEv1 Decryption Table and enter the Initiator’s COOKIE and Encryption key:       And here is the decrypted identification message:        Decrypt ESP packets.   Decrypting ESP packets follows the same principle as ike, but require more parameters.     Protocol: IPv4 Src IP: The source IP of the ESP packets you want to decrypt. For the example above 10.193.121.91 Dst IP: The destination IP of the ESP packets you want to decrypt. For the example above 10.193.121.93 ESP SPI: You can find it on the packet capture under Encapsulation Security Payload. In our example, it is 0xb82d7cde Encryption and Authentication Algorithm: They are part of the output of ‘>show vpn flow ‘ command. admin@FW1> show vpn flow name To-FW2 | match algorithm         auth algorithm:         SHA256         enc  algorithm:         AES128   Encryption and Authentication Key which can be found on the ikemgr.log: 21.93[500]/0, satype=141 (ESP), spi=, wsize=4, authtype=41 (SHA256), enctype=15 (AES128), saflags=0x0, samode=137 (tunl), reqi d=0, lifetime hard time 180, bytes 0, lifetime soft time 146, bytes 0, enckey len=16 [3d6991e6a0f888d240c8d539a54676a7], authkey len=32 [bbac69f722297906c11d7d9038248ba3b509519a0e1e37bb0652752130c8324c]   Next, go to Wireshark > Edit > Preferences > Protocols > ESP Decryption and select “Attempt to detect/decode encrypted ESP payloads”:       Then edit the ESP SAs.     After that you will see the ESP packets decrypted.  
View full article
imsed ‎04-12-2017 12:03 PM
24,732 Views
4 Replies
4 Likes
This article shows how to fix the problem of web browsing that fails with an error code SSL_ERROR_RX_RECORD_TOO_LONG. We'll use an example of facebook.com.   Cause Errror code: "SSL_ERROR_RX_RECORD_TOO_LONG" means the web server is sending non-secure (HTTP) data where secure (HTTPS) data is expected by the web browser.     Details Security policy on the firewall:  (refers to URL filtering profile facebook test)       URL Filtering profile on firewall: (social-networking category has action of continue)       With an action of continue on the URL category, the firewall will send a redirect message to the client to prompt users to click Continue to proceed to the web page, as follows:     This Continue redirect message sent by the firewall is an HTTP response:      Note: This redirect message shows the URL category and the security policy rule matched by this traffic.     When browsing to www.facebook.com, the browser makes a request for https://www.facebook.com, as below:   In this case, the firewall sending an HTTP redirect message for continue is treated as an invalid response by the browser and it shows an error, SSL_ERROR_RX_RECORD_TOO_LONG.     Solution Either of the two solutions offered can overcome this issue:   Enable outbound SSL decryption on the firewall. For more information on how to enable SSL decryption on firewall, please click here OR   Run the following command on the firewall. This will allow the SSL handshake to complete before sending an HTTP response page to the client. For more information about this command, please click here. # set deviceconfig setting ssl-decrypt url-proxy yes  
View full article
hagarwal ‎11-22-2016 10:20 AM
3,068 Views
0 Replies
Symptoms Google Drive access works using Google Chrome browser based on the cached session.   Scenario   End host has accessed Google Drive or is logged in to the account from home, but when the laptop is enrolled on the office network, the firewall is not able to identify and block the cached session.   Diagnosis When someone is accessing Google Drive via Chrome, we see at least 3 sessions:   google-base (google.com, client.google.com, gstatic.com, etc) (appid 2075) covers others (main page, navigating, listing, etc). google-drive-web (drive.google.com) (appid 1596) this covers login google-docs-base (docs.google.com) (appid 635) covers downloading and editing functionality Solution Even blocking Google Drive based on the URL category will not help, blocking online-personal-storage (drive.google.com, docs.google.com) will not block listing and navigating.   For blocking to work successfully, blocking google-drive is not enough.  We also need to block google-docs.   We can further customize the requirements of the customer to allow users to access google-drive but block uploads and downloads.   The google-docs application is made of other sub-applications listed below. The app names explain their functions: google-docs-base google-docs-editing google-docs-enterprise google-docs-uploading   Note: We will need to have decryption in place for the above functions to work. We should especially decrypt the 'search-engine' category along with the following url's drive.google.com, *.google.com, *.googleusercontent.com, and *.gstatic.com     A screenshot of adding a security policy to allow access to google-drive but deny downloads or editing, and just allow uploading files.       Dependent Issue   Enabling decryption for search-engine might trigger a safe search enforcement from the the url category, which will break the ability to search from the address bar of the Chrome browser.   The search made from the address bar does not include the string " safe=active" when searching, this is seen only when using Google as a default search engine.   As a workaround, we can use the following custom search engine (make it default ) in the Chrome settings:   {google:baseURL}search?q=%s&safe=active   The screen shot is attached for reference.            
View full article
smalayappan ‎09-06-2016 01:50 PM
8,157 Views
2 Replies
1 Like
Overview Consider the following custom application and application override rule.  We have configured a custom application for TCP ports 80 and 443.  Application override is happening for traffic to port 80,443 from DMZ to L3-Untrust.       Consider the following decryption rule: Here we are decrypting all traffic coming from DMZ going to L3-Untrust.     If you try to access some https website you will find that the traffic is not being decrypted because of the application override, even if you are doing decryption for everything.     When application override is configured, the Palo Alto Networks firewall stops processing at Layer 4.  
View full article
pankaku ‎08-17-2016 03:15 PM
1,667 Views
0 Replies
Issue   We know that SSL decryption is supposed to give us visibility of traffic that would otherwise be encrypted. Therefore, we'd expect decrypted traffic to be identified as the underlying applications, such as web-browsing, facebook-base or other, but not as SSL. However, in some scenarios, seeing application SSL as decrypted is expected behaviour. This article covers one such scenario and explains why a decrypted SSL session identified as application SSL is, in this case, considered OK.    In the below example, we were trying to access the following website:  https://my.vmware.com/web/vmware/login   From the session table, we can see that the session is marked as decrypted (*) admin@Faith-PFW-X1> show session all filter ssl-decrypt yes -------------------------------------------------------------------------------- ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port]) Vsys Dst[Dport]/Zone (translated IP[Port]) -------------------------------------------------------------------------------- 25472 ssl ACTIVE FLOW *NS 192.168.16.48[60668]/Zone-Trust2016/6 (10.193.90.32[61785]) vsys1 216.58.212.163[443]/Zone-UnTrust (216.58.212.163[443]) 25475 ssl ACTIVE FLOW *NS 192.168.16.48[60670]/Zone-Trust2016/6 (10.193.90.32[37349]) vsys1 216.58.212.163[443]/Zone-UnTrust (216.58.212.163[443]) 25478 ssl ACTIVE FLOW *NS 192.168.16.48[60674]/Zone-Trust2016/6 (10.193.90.32[43548]) vsys1 216.58.212.163[443]/Zone-UnTrust (216.58.212.163[443]) 25474 ssl ACTIVE FLOW *NS 192.168.16.48[60671]/Zone-Trust2016/6 (10.193.90.32[31994]) vsys1 216.58.212.163[443]/Zone-UnTrust (216.58.212.163[443]) 25479 google-base ACTIVE FLOW *NS 192.168.16.48[60675]/Zone-Trust2016/6 (10.193.90.32[15527]) vsys1 216.58.212.163[443]/Zone-UnTrust (216.58.212.163[443]) 25538 web-browsing ACTIVE FLOW *NS 192.168.16.48[60710]/Zone-Trust2016/6 (10.193.90.32[17185]) vsys1 68.232.35.180[443]/Zone-UnTrust (68.232.35.180[443]) 25473 ssl ACTIVE FLOW *NS 192.168.16.48[60669]/Zone-Trust2016/6 (10.193.90.32[35255]) vsys1 216.58.212.163[443]/Zone-UnTrust (216.58.212.163[443])   A deeper look into the session shows that we have application type identified as SSL.   admin@Faith-PFW-X1> show session id 25473 Session 25473 c2s flow: source: 192.168.16.48 [Zone-Trust2016] dst: 216.58.212.163 proto: 6 sport: 60669 dport: 443 state: INIT type: FLOW src user: unknown dst user: unknown s2c flow: source: 216.58.212.163 [Zone-UnTrust] dst: 10.193.90.32 proto: 6 sport: 443 dport: 35255 state: INIT type: FLOW src user: unknown dst user: unknown start time : Tue Jun 21 11:37:52 2016 timeout : 15 sec total byte count(c2s) : 796 total byte count(s2c) : 4759 layer7 packet count(c2s) : 8 layer7 packet count(s2c) : 8 vsys : vsys1 application : ssl rule : Trust 2016 To Internet session to be logged at end : True session in session ager : False session updated by HA peer : False address/port translation : source nat-rule : NAT Trust 2016 To Internet(vsys1) layer7 processing : completed URL filtering enabled : False session via syn-cookies : False session terminated on host : False session traverses tunnel : False captive portal session : False ingress interface : ethernet1/3 egress interface : ethernet1/6 session QoS rule : N/A (class 4) tracker stage firewall : TCP FIN tracker stage l7proc : proxy timer expired end-reason : tcp-fin   Explanation When the session is decrypted, App-ID lookup is triggered on the decrypted flow to help identify the session application. The firewall needs to read enough data packets in order to identify the application. After the SSL handshake is completed, we would need to read a maximum of 2000 bytes of data to determine if the application is unknown or not. When the decoder is detected, e.g. web browsing, it may take more than 5 packets to determine the actual application.  In most cases, the application will be recognized before receiving that amount of data.   Looking at the packet capture output below, we see that the communication ended prior to the exchange of application data that would have enabled the firewall to identify the application.      This would also apply if regular tls/ssl is wrapped around some custom app: the underlying app would be "unknown-tcp" if it weren't encrypted, but because of the encryption, app-ID has already identified ssl and will keep that as the app.    We hope you find this information useful. Please leave a thumbs up or a comment in the section below.   See also How much data is necessary to recognize an application  
View full article
fmopiy ‎06-28-2016 06:16 AM
15,286 Views
0 Replies
4 Likes
Symptom   When browsing to Google or Yahoo sites with SSL decryption and FIPS mode enabled, the firewall presents the Forward Untrust Certificate to the client.     Explanation   Both Google and Yahoo present root certificates with 1024 bit keys in their certificate chains. Since 2010, certificates with 1024 bit keys are not FIPS-compliant, and therefore, a firewall in FIPS mode will not trust the certificates.   Google's certificate chain   $ openssl s_client -connect google.com:443 CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority   Equifax Secure Certificate Authority   $ openssl x509 -in Equifax_Secure_Certificate_Authority.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 903804111 (0x35def4cf) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=Equifax, OU=Equifax Secure Certificate Authority Validity Not Before: Aug 22 16:41:51 1998 GMT Not After : Aug 22 16:41:51 2018 GMT Subject: C=US, O=Equifax, OU=Equifax Secure Certificate Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit)   Yahoo's certificate chain   $ openssl s_client -connect yahoo.com:443 CONNECTED(00000003) depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Sunnyvale/O=Yahoo Inc./OU=Information Technology/CN=www.yahoo.com i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4 1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4 i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority   Class 3 Public Primary Certification Authority   $ openssl x509 -in Class-3-Public-Primary-Certification-Authority.pem -text -noout Certificate: Data: Version: 1 (0x0) Serial Number: 3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Validity Not Before: Jan 29 00:00:00 1996 GMT Not After : Aug 2 23:59:59 2028 GMT Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit)   Workaround   There is no way to force the firewall to trust certificates with 1024 bit keys when FIPS mode is enabled.   You can exempt Google and Yahoo sites from SSL decryption using the following steps:   1. Create a custom URL Category on the Objects > Custom Objects page that contains the following URLs:   *.google.com *.yahoo.com       2. Create a new decyption policy on the Policies > Decryption page.   a. Set the source and destination to match the existing decryption policy. b. Set the URL Category to the custom category created in Step 1. c. Under the Options tab, select "No Decrypt". d. Place the "No Decrypt" policy above the existing decryption policy and commit.  
View full article
nanderson ‎05-06-2016 03:26 PM
14,817 Views
0 Replies
1 Like
Symptoms With Inbound SSL decryption is enabled for server example.com, the system logs show:   reverse proxy key example.com doesn't match certificate issued to example1.com Diagnosis The above error indicates that the server certificate, including its private key, which was imported into the device for enabling inbound SSL decryption, does not match the certificate presented by the server. In this case, the server presented a certificate with name example1.com. Solution To verify this behavior: Take a packet capture on the client or the firewall for the entire transaction: How to Run a Packet Capture Find the packet which contains the SSL handshake message “Certificate”  (Coming from Server to Client) Expand the packet, locate the certificate/s and take a note of the serialNumber of the Server Certificate. Or you can right click on the certificate that you want and select on Export selected packet bytes and then save it with a name. Match the serial number and validity in this certificate with the serial number/ validity of the certificate loaded into the firewall and used in the decryption policy. NOTE: If you are hosting multiple servers on the same machine 1.2.3.4 (same IP), then make sure that the SSL decryption policies are not configured with IP address as match condition.   For example: SSL Decryption Policy 1 Source : Any Destination : 1.2.3.4 Service : service-https Action : Decrypt with certificate example.com   SSL Decryption Policy 2 Source : Any Destination : 1.2.3.4 Service : service-https Action : Decrypt with certificate example1.com   In this case, if a traffic comes for example1.com, when SSL decryption policy will be looked up, it will always match the first policy, even though the policy is binded to Certificate with hostname as example.com. The certificate is not a valid match condition for firewall for policy lookup.   Thereby when the example1.com will present its certificate it will not match with the certificate loaded which is for example.com   Resolution To avoid this situation, create custom URL categories for each URL and use them in the match conditions.   SSL Decryption Policy 1 Source : Any Destination : 1.2.3.4 Service : service-https URL Category: Category_Example   (contains example.com) Action : Decrypt with certificate example.com   SSL Decryption Policy 2 Source : Any Destination : 1.2.3.4 Service : service-https URL Category: Category_Example1    (contains example1.com) Action : Decrypt with certificate example1.com
View full article
abjain ‎04-11-2016 06:34 PM
13,990 Views
1 Reply
Symptoms Some SSL websites are not opening even after the URL has been included in  ssl-exclude-cert, despite following instructions in How to Exclude a Site from SSL Decryption   The websites' failure to open holds true for implicitly excluded URLs provided by Palo Alto Networks in List of Applications Excluded from SSL Decryption Diagnosis If a URL category is included in the Decryption Rules, when the traffic for a website matching that URL category hits for the first time on the device, even if that website is excluded from Decryption using SSL-Exclude-Certificate settings, the firewall will not skip decryption based on SNI (Server Name Indication) included in Client Hello Packet.   The firewall still does a forward proxy for the connection, and sends a list of Supported Cipher Suites to the server.   If the server accepts the Client Hello proposed by the firewall, and sends a Server Hello / Certificate, the firewall then inspects the Server Certificate for the Common name and matches it against the configured SSL Exclude Certificate Settings. If it matches, then Server  address and TCP port are added to the exclude cache for the particular rule they match. This exclude cache is then used for future connections matching the same parameters and will cause the firewall to even skip the proxy.   In case the server does not support the Cipher Suites send (overwritten) by the firewall, the Server might send an SSL error message or just send a TCP RST to the connection. Solution   If the firewall is sending cipher suites that are unsupported by the Server, even after including the certificate in the SSL-Exclude-Certificate settings, then perform the following steps to resolve this issue.   Inside Objects > URL Category, click Add to create a new custom URL Category - ex ExcludeSSLdescryption, then add the URLs inside this category that you do not want decrypted. Inside Policies > Decryption, Create a No-Decrypt rule above the SSL decryption rule which is being used for decrypting the rest of the traffic. Place the newly created URL Category -  ExcludeSSLdescryption in the URL Category. This way, the traffic for the URL Category will be excluded from the decryption policy. Commit this change for it to take effect.    
View full article
abjain ‎04-11-2016 06:01 PM
9,222 Views
1 Reply
  If a website or destination only supports ECDHE SSL ciphers, then SSL decryption forward proxy will not work. This is attributed to the unsupported ECDHE cipher suites, which is not supported for the forward proxy feature.   Let's take a look how the SSL decryption forward proxy feature handles unsupported SSL ECDHE cipher suites. The client sends an SSL hello to the website or destination host. T he client hello includes all the SSL cipher suites it supports, which include the ECDHE cipher suites.  The Palo Alto Networks firewall intercepts the client hello packet, selects the supported ciphers from this list (removing the ECDHE ones), re-crafts the SSL client hello and proxies it to the website. The website or destination host replies with an SSL HANDSHAKE failure: error code 40- unsupported ciphers, if the wesbite does not support non-ECDHE ciphers. The packet containing 'SSL HANDSHAKE failure: error code 40- unsupported ciphers' is the trigger for the Palo Alto Networks firewall to know that the website or destination host does not support the proposed SSL cipher suites. The Palo Alto Networks firewall gives up decryption for this website and populates its 'ssl-decrypt exclude cache.' From now on, the Palo Alto Networks firewall will not proxy any subsequent connections to this website or destination host. The lifetime of the SSL decrypt exclude cache is 12 hours. It persists as long as there's no change made to the decryption policy.  On collecting another packet capture on the firewall in the received and transmit stage and comparing them you can see that SSL ciphers proposed in the client hello, by the  actual client machine behind the Palo Alto Networks firewall and the one relayed by the firewall are the same.  Thereby SSL decryption forward proxy is bypassed. Beginning PAN-OS 7.0.1 and onwards SSLv3 is the minimum version of SSL protocol that is supported. It is not supported in FIPS mode though. SSL decrypt excludes cache functions in tandem as per the configured parameters.   The server URL/IP, App and decryption profile are put in exclude cache if: Decryption mode is SSL Forward Proxy "Block sessions with unsupported version" and "Block sessions with unsupported cipher suites" are unchecked. The failure is because of the server side, rather than the client side. It's either in the server hello or in an alert from the server.   For example: PA-VM> show system setting ssl-decrypt exclude-cache VSYS    SERVER                     APP    TIMEOUT      REASON                             DECRYPTED_APP      PROFILE 1            91.185.164.129:443    ssl       43186            SSL_UNSUPPORTED        undecided                    Decrypt Stream   In the above output from the command line of the Palo Alto Networks firewall: VSYS: 1 is the id of the default virtual system 1 (vsys1) SERVER: 91.185.164.129 is the IP address of the website / destination host APP: ssl, reflects the ssl application  TIMEOUT: 43186 is the lifetime of the cached entry in seconds. The maximum cache lifetime is 12 hours or 43200 secs REASON-- SSL_UNSUPPORTED: implies unsupported ssl cipher suites and hence an entry in the exclude cache DECRYPTED_APP: undecided, as the website wasn't decrypted so the firewall doesn't know the underlying application  PROFILE: Decrypt Stream is the name of the decryption profile, which is referenced in the ssl decryption policy.   The cache can be cleared using the following CLI options: PA-VM> debug dataplane reset ssl-decrypt exclude-cache + application       application + server server   address and port For example: debug dataplane reset ssl-decrypt exclude-cache application ssl server  91.185.164.129:443   Please refer to the PAN-OS new features guide for the enhancements made to SSL decryption feature for more information. New Features Guide   Read this article for more information about unsupported ssl cipher suits: Unsupported SSL cipher suites for Decryption
View full article
kbiswas ‎02-08-2016 07:24 AM
14,457 Views
3 Replies
1 Like
Overview   The following table provides a list of valuable resources on configuring and troubleshooting App-ID:   TITLE TYPE Configuration   Not-applicable, incomplete, insufficient data in the application field Document Tips & Tricks: How to create an application override Document How to create an application filter to block high-risk applications Document How to check if an application needs explicitly-allowed dependency apps Document How to configure the 'sip-trunk' App-ID Document How to configure a custom App-ID Video App-IDs for SSL-Secured versions of well-known services Document How to request a new App-ID Document Demonstration of Google SafeSearch custom App-ID Video   How to create an application override for FTP Document Tips & Tricks: What is application dependency? Document What is the APP-ID for Palo Alto Networks updates? Document Troubleshooting   How to validate and report application misidentification Document List of Applications Excluded from SSL Decryption Document How to clear cache for App-ID, Proxy certificates, URL, and user Document How Palo Alto Networks identifies HTTPS applications without decryption Document How to verify the application name change from Unknown-tcp/udp to actual App-ID Document Access to external web services required by dynamic updates and WildFire Document   How much data is necessary to recognize an application Document Custom App without signature not matching security rule Document Other Resources   App-ID Admin Guide Guide Applipedia Database   Note: If you have a suggestion for an article, video or discussion not included in this list please post a recommendation in the comments below and it will be added to the master list.   owner: ekampling
View full article
‎01-14-2016 07:11 AM
12,896 Views
0 Replies
Symptoms When trying to use a certificate for SSL decryption, the following error might appear during a commit: Certificate 'cert_name' failed to load: parse tbs certificate not supported algorithm   Issue This error will occur when either the encryption for that certificate is stronger than RSA 3072 or the hash is stronger than SHA 256   Resolution Create a certificate that uses RSA 3072 and SHA 256 or lower   owner: nbilly  
View full article
npare ‎09-09-2015 12:29 PM
4,609 Views
1 Reply
Issue A user has two instances of Panorama in the production network and is preparing to turn on Panorama HA.  The Panorama VM at the primary site has been cloned and brought up on the secondary site,  The MAC address, serial number, and management IP address have been changed. However, the two VMs have the same HA key and get an error when attempting the HA key exchange.  Is there a way to regenerate the HA key in one of these instances of Panorama?   Resolution To regenerate the HA encryption key: Reset the SSH keys on one of the Panorama boxes by using the following CLI command: admin@Panorama97> debug system ssh-key-reset high-availability Resync the keys between the two Panoramas by using the SCP export/import commands: admin@Panorama97> SCP export high-availability-key + remote-port SSH port number on remote host * from from * to Destination (username@host:path) admin@Panorama97> scp import high-availability-key + remote-port SSH port number on remote host * from Source ( username@host:path )   owner: gutierrez
View full article
panagent ‎08-20-2015 01:23 PM
2,927 Views
0 Replies
Ask Questions Get Answers Join the Live Community