Palo Alto EDU-110: Decryption

Objectives:

Describe the benefits of decrypting traffic

Define the three decryption types that can be configured at the firewall

Describe how a certificate chain of trust is used to authenticate a device, service, or person

Configure an SSL Forward Proxy

Review Traffic logs to determine whether SSL sessions are being decrypted

Why decrypt network traffic?

More traffic is being encrypted. Palo Alto firewalls offer the capability to decrypt and inspect network traffic for visiblity, control, and granular security. Decryption on a Palo Alto networks firewall includes the capability to enforce security policies on the decrypted traffic, where otherwise the encrypted traffic would not of been blocked since it could not be inspected. Decryption on a firewall can also prevent malicious content from entering the organisations network or preventing sensitive information from leaving the ogranisation as encrypted traffic.

The Palo Alto fireweall can decrypt both SSHv2 and SSL/TLS inbound and outbound traffic.

SSL/TLS Overview

The SSL/TLS protocol encrypts an HTTPS connection between a client and a server where no pre-existing secure channel was previously present.

The client requests an SSL connection to the server, the server responds with it’s certificate that ther client P.C. then verifies. The client uses that public certificate to send an encrypted session key, and the server begins encrypted server communications with the client.

The communication between the two devices may periodically need to re-establish the connection and rekey the communcation.

Perfect Forwarding Secrecy, PFS, prevents former sessions from being decrypted if the private key is discovered.

Support for the Palo Alto firewalls to inspect PFS traffic on SSL Forward Proxy was introduced on version 7.1 of PAN-OS, and SSL Inbound Inspection was added in PAN-OS 8.0

Firewall Decryption Types

SSL Forward Proxy (Outbound)

The SSL Forward Proxy on the firewall decrypts SSL traffic between an internal host and the external web server.

The firewall acts as an SSL proxy essentially.

A connection is formed between the internal client and the firewall, and a seperate SSL connection is formed between the firewall and the exteral web server.

SSL Inbound Inspection

SSL Inbound inspection decrypts SSL traffic coming from external users to internal servers

The administrator must have access to the servers private key and certificate

The firewall decrypts and inspects only the traffic flowing through it

SSH Inspection

SSH Decryption decrypts outbound and inbound SSH traffic.

if an SSH tunnel, port forwarding, is discovered the SSH conenction is blocked to ensure it is not being used to tunnel disallowed applications and content

A decryption policy can be attached to security policy rules to control normal, non-port forwarded SSH traffic.

Public Key Infrastructure

The PKI solves the problem of verifying the identity of a public key owner.

PKI is the set of hardware, software, policies, and standards used to create, manage, distribute, and revoke public keys and digital certificates. A PKI digital certificate is a method of packing and distributing publuc keys in a way that proves identity of their owners. Palo Alto supports X.509-format certificates

A PKA certificate authority provides serviers that can authenticate people, devices, and services by issuing the certificates that can confirm their identity and public key.

Certificate Authoritys are arranged in a heirarchical order, similar to a file system. The root CA’s form the top level of the hierarchy and the intermediate CAs form the second and lower levels.

An intermediate CA is certified by a root CA to issue certificates or certify additional lower level intermediate CAs. Each CA has a database of certificates that stores certificates, revokes certificates, stores certificate requests and issues certificates.

Devices use their own certificate store to keep their private keys and certificates they have been issued. They can also maintain a list of trusted certificate authorities here. This list of trusted authorities can be updated by a user of it a device recieves new trusted certificate authorities via a software update.

If the certificate of the issuing certificate authority is not trusted by a client device, the client will recieve a warning message when it sees a certificate verified by that untrusted certificate authority.

Certificate Train of Trust

• Root CA
  • Intermediate CA
    • Device Certificate

The Root CA certificate is always signed by the root certificate authority itself.

The device can verify the owner of a public key if the devices list of trusted certificate authoritys includes a root certificate authority in the chain of trust

Certificate Facts

An issuing CA computes a hash value of the critical information in a certificate and that includes the hash value in the certificate.

The receiving entity can recompute and compare the hash value to ensure the certificate has not been tampered with by a malicious third party

The prevent tampering of the hash value and other critical information, the issuing CA encrypts the information with its own private key. The receiving device uses the issuing CAs public key to decrypt this information to recompute and calculate the hash value. Because only the issuing CA themselves only know their private key, the encryption of the digital certificate information is the act of digitally signing the certificate.

Palo Alto Features using certificates

• SSL/TLS decryption
• Management interface user authentication
• Global Protect
  • Portal Authentication
  • Gateway Authentication
  • Mobile Security Manager authentication
• Captive Portal user authentication
• IPSec VPN IKE authentication
• High availability authentication
• Secure syslog authentication

Certificate and Revocation Checking

All certificates in a chain of trust must be checked before an SSL/TLS connection can be considered to be secure

1. Determine the certificate chain of trust
2. Validate each certificate
   1. Signature valid?
   2. Date range valid?
   3. Not malformed or corrupt?
3. Check the revocation status

If the signatures are valid, check the revocation status of each certificate in the chain using CRLs and OCSP.

The certificate may be revoked before it’s intended expiration date because the certificate owners private key might have been compromised, hostname or username of the certificate owner may of also changed. The host could of been retired, a user left the company, or a counterfeit or leaked key may need to be invalidated.

Certificate Signing Request Process

1. Applicant creates public and private key pair
2. Applicant signs (encrypts) identity information using the private key
3. Applicant sends signed information and public key
4. CA returns the signed certificate

Advantages of this setup is the private key never leaves the device, and the device is part of a chain of trust.

The disadvantages to this setup is the device needs to be capable of generating a CSR, plus there is some administration overheads.

Certificate Management in the Web Interface

The web interface gives several options for certificate management:

• Generate certificates
• View certificates
• Modify certificate use
• Import and export certificates
• Delete certificates
• Revoke certificates

Firewall CA Certificate Deployment Choices

Each certificate can be authorised for different uses. A signing certificate must be a CA certificate. The firewall requires a signing certificate to support features such as SSL Forward Proxy or GlobalProtect.

Option 1.

You can obtain the firewall certificate from a third party CA.

Advantage:

The third party CA certificate is more than likely already signed by a trusted root CA, that will work with clients without error

Disadvantage:

Most third party CAs do not issue signing certificates, and signing certificates are required for SSL operation

Option 2.

If you already have deployed an internal CA, you can issue a signing certificate to the firewall.

The advantage here is the end devices in the enterprise likely already trust the CA certificate since it’ll be added to their stores

Option 3.

If a self-signed CA certificate is generated, the firewall can generate any other required certificates.

The disadvantage here is the self signed CA cetificate will not be trustedf by any of the end clietns until the CA certificate is added to their trust stores.

There are automated methods that exist to distribute CA certificates to multiple clients

Generate a CA certificate using CSR

If an internal CA is present, it can be used to help sign a firewalls certificate.

To creat the public and private key, plus CSR using the web interface, ensure the External Authority (CSR) is selected in the Signed By field.

If the certificate will be a certificate capable of signing over certificates, then select the Certificate Authority check box.

The common name must be the FQDN or IP address of the firewall.

An OSCP responder can also be set for the certificate, and a variety of certificate attributes can be set to further identify the owner of the certificate.

Once all the fields have been filled out as required, click the generate button. A new but unsigned certificate will appear in the certificate management window.

Export the certificate in it’s csr file form, and import to your CA.

The CA will sign the file and return it in a .pem format, import this into the Palo Alto firewall with the same name as the existing .csr file to replace it

Import a CA certificate

A firewall CA certificate and public/private key pair can be created on an internal CA and imported into the firewall.

Use the import button the certificates page to import a CA.

A PKCS12 file contains both the certificate and private key in the same file.

A PEM file containing the certificate will not contain the private key, and may need to be uploaded from a seperate file.

Certificate Hierarchy

PAN-OS organises the certificate lists as a hierarchical list, to help simply administration

Forward Proxy Decryption

SSL Forward Proxy decryption decrpyts and inspects SSL/TLS traffic from internal users to external web servers

It prevents malware concealed as SSL encrypted traffic from being introduced to an organisations network

The firewall dynamically chooses a key size to use to establish an SSL foreward based session for a client. A static key size can be configured for SSL Forward Key sessions between the firewall and the clients regardless of the key size used on the destination server.

Be aware of the validity date on the firewall certificate is taken from the validity date on the server certificate. The firewall acts a proxy for the SSL connection, but not the underlying traffic.

Packet capture functionality executes before decryption, which means the packet capture file will contain encrypted data.

Forward Trust and Forward Untrust Certificates

If a server certificate is trusted, the firewall signs a copy of the server certificate with a forward trust certificate.

If the server certificate is untrusted, the firewall signs a copy of the server certificate with a forward untrust certificate.

This is the workaround to if a user visits a site with an invalid SSL certificate

Configuring Forwarding Certificates

The first step to configure SSL forward proxy is to configure a forward trust certificate on the firewall.

The forward trust cetificate needs to be signed by an internal CA or a firewall CA.

The firewall can also create a self signed forward trust certificate, but every client will need to have a copy of the self signed CA cert in their trusted store.

Configuring a Forward Untrust Certificate

A forward untrust certificate is recommended, and should not be trusted by SSL clients.

It shouldn’t be issued by a trusted CA, nor copied to a SSL clients certificate store.

A quick way to get a cetificate matching these requriements is generate a new self signed certificate on the firewall.

Configuring SSL Forward Proxy Policy

The rules are parsed from top to bottom, in the section Policies -> Decryption

When traffic matches a particular rule, the actions defined in that rule are taken and the processing through the list of rules is stopped.

Not all traffic should be decrypted, some legally should not be decrypted, depending on local laws and regulations concerning health records, financial records and other privacy concerns.

Forward Proxy Decryption Profiles

The firewall prcoesses and inspects HTTP/2 traffic by default.

The application layer protocol negotiation, or ALPN, is used secure HTTP/2 connections.

If no value is specified for the ALPN TLS extension, the firewall downgrades the HTTP/2 traffic to HTTP/1.1 or classifies the traffic as unknown

HTTP/2 inspection can be disabled by slecting the Strip ALPN check box

The decryption profile enables checks to be performed on the decrypted traffic and specify traffic that is to be excluded from decryption.

The decryption profile allows the administrator to block sessions using unsupported protocols, cipher suites, or sessions that require SSL authentication.

The sesions can be blocked based on certificate status, for example the certificate has expired or signed by a non trusted CA.

Sessions can also be blocked if resources are not available or if the hardware security module is not available to sign certificates

Creating security policy rules

Create two rules, one that allows web-browsing and the other that permits ssl.

Once allowed through and decrypted, the firewall may identify the ssl application as some other application, such as web-browsing.

The web-browsing rule should be specified to allow access over both ports 80 and 443. The application default port for web browsing is just ports 80 and 8080.

SSL Inbound Inspection Overview

The Palo Alto firewall can inspect inbound SSL traffic for potentional threats from external hosts to internal SSL enabled servers

The session can be controlled with security policy rules and security profiles

The administrator just needs to import the same certificate and private key as the server into the firewall.

The firewall can listen in to the secure session since it has the same private key and certificate as the internal server.

Unsupported Applications

Some applications may not work with SSL Forward Proxy

Such as:

• applications that use client-side certificates
• Non-RFC compliant appliactions
• servers that use unsupported cryptographic settings

The applications that detected as unsupported, fail into an excluded cache so decryption is not attempted again until 12 hours after the first occurance.

You can display items in this cache, by using the CLI command:

show system setting ssl-decrypt exclude-cache

The command output will give a reason too on why the decryption had failed

Decryption Port Mirroring

This feature will export decrypted flows out of a dedicated interface on the firewall.

The uses include network forensics and data loss prevention. Tools such as NetWitness or Solera.

Decryption port mirror is only available on the PA-3000 Series, PA-5000 Series, and PA-7000 series and requires a free PAN-PA-DECRYPT licence to be installed for it to be enabled.

Decryption Broker

The firewall can also provide a central point for decrypting all of the network traffic.

The decryption broker allows the firewall to forward plain, cleartext traffic to a security chain for additional enforcement.

Providing a clear visiblity into network traffic.

The securitry chain is a set of inline, 3rd party appliances dedicated to perform specific security functions such as IPS. A single firewall can distribute decryption sesions of up to a maximum of 64 security chains. The firewall can monitor these to ensure they are processing traffic.

The security chain can return the allowed traffic back to the firewall.

The decryption broker is only supported on PA-7000 Series, PA-5200 series, or the VM-Series devices.

Hardware Security Modules

Hardware Security Modules are devices designed to safeguard security keys.

It generates, stores, and manages digital keys, providing logical and physical protection of the firewalls private keys from nonauthorised use.

Dedicated hardware security modules can be used to manage certificate signing functions for SSL Forward Proxy, SSL Inbound Inspection, and master key storage

HSM support is generally required when FIPS 140-2 level 3 protection for CA keys is required

Palo Alto firewalls can be used with SafeNet Luna SA 5.2.1 or Thales nShield Connect

Hardware Security Module use is supported on the PA-3000, PA-5000, PA-700 Series firewalls. This includes the VM series firewalls too.

It’s supported on the Panorama VM, and Panorama M-100 and M-500 devices too.