Palo Alto EDU-114: Blocking threats in encrypted traffic

Module objectives:

Create and manage certificates using the web interface

Configure certification revocation checking on the firewall

Configure SSL/TLS decryption on the firewall

Describe the effects of key pinning on firewall Decryption policy

Configure SSH decryption on the firewall

Manage the master key

The importantance of SSL/TLS

Secure Socket Layer / Transport Layer Security secures network communications end to end across a shared network platform. It offers many advantages such as encryption for data privacy, hashes for data integrity, and certificates for authentication.

The Palo Alto next generation firewall offers SSL/TLS decryption to help prevent malware introduction through encrypted channels, and data exfiltration out of the company out encrypted channels.

A quick recap on SSL/TLS operation

An SSL session is established between a client and server as the following:

1. Client requests an SSL connection to the server
2. The SSL server sends the client it’s server certificate
3. The client verifies this SSL certificate against it’s own trusted store of root certificates
4. The client sends an encrypted session key to the SSL server
5. The server uses it’s own private key to decrypt this session key
6. The server and client then begin encrypted private communications between each other using the confidential session key

Palo Alto Certicate Management

The Palo Alto firewall supports two different types of SSL certificate, certificate authority signed certificates and self-signed certificates.

The preferred method for configuration is a CA-signed certificate, which simplifies SSL configuration.

The administrator has a number of options in obtaining a CA-signed certificate

1. Buy a CA-signed certificate and public-private key pair from a public CA
   1. Disadvantage is cost
   2. Limitation in that public CA’s do not sell signing certificates, required for SSL Forward Proxy description
2. Get a CA-signed certificate and public-private key pair from an internal CA
   1. Advantage is usually free
   2. Can be a signing certificate to be used with SSL Forward Proxy decryption
3. Create the certificate and public-private key pair on the CA server
   1. Create a certificate and public-private keys
   2. Import certificate and public-private keys onto the firewall
   3. Disadvantage: A small risk that hte private key transferred over the network would be stolen

On the last point there with the risk of a key being stolen, there is a workaround:

1. Generate a CSR and public-private keys, export the CSR file
2. Sign and return the certificate in a file
3. Import the CA signed certificate from the file

For self signed certificates, a couple of advantages is that they are free and can be obtained in minutes. The self signed certificate can also be used with SSL Forward Proxt decryption. The primary disadvantage is that this self signed certificate would not be trusted by other devices in the organisation.

The administrator could export and install the self signed certificate to the trusted root certificate store on other devices in order for the self signed certificate to be trusted as a work around.

Certificate Creation and Management

Certificate Checking and Revocation

One: Determine chain of trust

Two: Validate each certificate in the chain

Steps to check:

1. Is the certificate signature valid?
2. Is the date range presented by the certificate valid?
3. Is the certificate signature malformed or corrupt?

Three: Check revocation status of each certificate

Compare against the online certificate status protocol (OCSP) first, then the certificate revocation list (CRL)

These lists will return four different statuses:

• Current: valid
• Expired: Cannot trust identity
• Unknown: Cannot establish validity
• Unavailable: OSCP/CRL can’t be contacted

Why would a certificate get revoked?

• The private key has been compromised
• Hostname or username of owner changed
• Host decommissioned, e.g. user left the organisation
• Couterfeit key found

Configuring SSL Decryption Certificate Revocation Checking

The Palo Alto firewall can be configured to verify the revocation status of certificates used for decryption.

This can be set up in Device -> Setup -> Session -> Certificate Revocation Checking

SSL Forward Proxy Review

The firewall uses SSL Forward Proxy to decrypt and inspect SSL traffic when the Palo Alto fireewall does not have access to the SSL servers private key.

The firewall and the SSL server must share a common CA for the firewall to validate the servers identity.

At the other end of the communcation, the SSL client and the firewall must have access to a common certificate authority for the client to validate the firewalls identity.

The SSL session tries to establish a session with the server with a SSL handshake. The Palo Alto firewall intercepts this handset and issues its own handshake between the firewall and the server. The SSL Server responds with a common CA to allow the firewall to validate the servers identity

The firewall copies this servers certificate and signs it with its own forward trust certificate and public key.

A forward trust certificate indicates to the SSL client that hte firewall has verified and trusts the servers certificate. The firewall forwards the newly copied and signed server certificate to the client

The client uses the firewalls forward trust certificate to validate the firewalls identity, using a CA common to both the client and firewall.

The client has now established a secure connection, and the firewall acts a proxy between the client and the server. The firewall can decrypt traffic and inspect it flowing between the client and the server.

If for any reason the server can not verify the servers certificate, it signs the servers certificate with a forward untrust certificate that indicates to the client the SSLs server certificate could not be verified

Configuring a Forward Trust Certificate

Configuring SSL Forward Proxy

Under Objects:

Under Policy Rules:

Configuring SSL Inbound Inspection

This traffic flows originate outside to inside

Note: You load the SSL certificate for the SSL server to the Palo Alto, and use that to decrypt/inspect traffic

So a private key and cert will need to be imported into the server

Identifiying Decrypted Network Sessions

Within monitor -> logs -> traffic, check the column header ‘Decrypted’ for yes or no

With the CLI command:

show session all filter ssl-decrypt yes

Check for the flag *

Decryption Exclusions

Websites with known decryption problems are pre-popualted on this Palo Alto created list.

The exclusion list is updated via content updates, and can also have websites added to it

No Decryption

Even if a website action is set to “no-decrypt”, the decryption profile can still be configured to block sessions with expired or untrusted certificates

Opting out of SSL Decryption

Device -> Response Pages

SSL Decryption Policy Considerations

Key Pinning can affect SSL decryption configuration, it’s purpose is to prevent use of counterfeit man-in-the-middle certificates. There are two types of key pinning, static key pinning and Dynamic Key Pinning (HTTP Public Key Pinning, HPKP)

Static Server Certificate Pinning

The software devceloper writes the code for the SSL server and client. The developer also configures both ends of the client and server to recognise the servers certificate.

The SSL decryption fails here as the client is preconfigured to accept a certain certificate. The firewall re-writes the certificate so the client will fail to validate the certificate presented to it via the firewall.

The same can happen with a certificate authority, where the software developer notes what certificate authority signed the certificate. As the certificate authority will also be different this can cause the client validation to fail.

Dynamic Key Pinning

Dynamic key pinning relies on a HTTP protocol extension called HPKP. A list of acceptable CA certificates and public keys is sent from the SSL server to the client the first time that the client connects to that SSL server.

The acceptable CA certificate information is sent in a HTTP resposne header named Public-Key-Pins. The client must establish at least one HTTPS connection to the server to recieve this list of acceptable CA certificates and public keys

This type of SSL Forward Proxy decryption can fail as the firewall can not perform the decryption unless it modifies the CA signature on the server certificate. The modified signature may not match the list of acceptable server cetificates unless the client is also configured to accept the certifcate and public key of the firewall as an acceptable CA certificate.

Reasons not to configure SSL Decryption

• Prohibited by law or a company policy
• Server requires a client certificate (Forward Proxy)
• New CA can not be added to a client
• Client software requires specific server certificates
• Non-standard SSL implementation in use

SSH Decryption

The Palo Alto firewall can decrypt and inspect SSHv2 traffic, to detect SSH-tunneled applications.

The decryption is unsupported with SSH key passwordless logins.

The Palo Alto firewall uses an automatically generated key to decrypt or encrypt traffic.

The traffic is identified as ethier ssh or ssh-tunnel on the firewall. The traffic can be controlled using Security Policy rules.

Firewall Master Key

The firewall master key is used to encrypt passwords and private keys.

It is good practice to periodically change the master key.

The master key must be the same in a HA pair

Managing the Master Key

All changes must be committed before changing the master key, the master key change does not require a commit after the key has been changed.

An expiration warning is good practice to set to avoid being locked out, an auto-renew can be set as a lockout safeguard to protect against accidental lock-out.

If the master key has expired, firewall access is only available through the console to perform a factory reset.