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:
- Client requests an SSL connection to the server
- The SSL server sends the client it’s server certificate
- The client verifies this SSL certificate against it’s own trusted store of root certificates
- The client sends an encrypted session key to the SSL server
- The server uses it’s own private key to decrypt this session key
- 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
- Buy a CA-signed certificate and public-private key pair from a public CA
- Disadvantage is cost
- Limitation in that public CA’s do not sell signing certificates, required for SSL Forward Proxy description
- Get a CA-signed certificate and public-private key pair from an internal CA
- Advantage is usually free
- Can be a signing certificate to be used with SSL Forward Proxy decryption
- Create the certificate and public-private key pair on the CA server
- Create a certificate and public-private keys
- Import certificate and public-private keys onto the firewall
- 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:
- Generate a CSR and public-private keys, export the CSR file
- Sign and return the certificate in a file
- 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:
- Is the certificate signature valid?
- Is the date range presented by the certificate valid?
- 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 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 *
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
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
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.