- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Certificate pinning was developped to help prevent man in the middle attack.
But what is the Certificate Pinning?
Traditionally, SSL Handshake consists on the validation of the server’s certificate, let’s say collab.com. The validation is done using the CA’s certificate located in the certificate store of the web browser.
The certificate store contains several CA Certificates, may be more than 100.
If at least one CA delivers by mistake or more likely to conduct an attack a valid certificate for example *.collab.com, attackers are able to launch a Man In The Middle Attack.
in order to prevent this attack, it is possible to use the SSL protocol in another way, by creating an association between the domain name of a site (www.collab.com) and the certificate or certification authority expected. Thus, only the a certificate (of collab.com) signed by one of the specific certification authorities will be accepted and if the certificate of collab.com signed by another CA is presented, it is not trusted.
Certificate pinning can be explained with a simple words: Is this connection secure with a valid certificate and is it signed by the CA I’m expecting?.
Some applications use a technique referred to as TLS/SSL pinning or certificate pinning, which embeds the fingerprint of the original server certificate in the application itself. As a result, if you configured a TLS/SSL rule with a SSL Forward Proxy action, and this rule matches this traffic, when the application receives a resigned certificate from Palo Alto Firewall the validation fails and the connection is aborted.
In the capture wireshark from the client side connection or the application you can detect this failed validation with the TLS alert message , The Alert Message indicates the spoofed re-signed certificate is not recognized by the application because the application is expecting to receive and validate only server certificate signed by a specific CA (Certification Authority) but it is receiving the server certificate signed by the Firewall, finally a TCP Reset is sent by the application to close the TCP connection.
If your browsers or your applications uses certificate pinning to verify a server certificate, you cannot decrypt this traffic by re-signing the server certificate.
To allow access to the website that uses a certificate pinning, you can add the hostname of the server in the SSL Decryption Exclusion List. The hostname is compared to the SNI in the Client Hello Message and the Common Name in the Server Certificate, if a match is found the firewall excludes the traffic from decryption.
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!