Introduction to Public Key Certificate
A digital certificate is a data file that allow, on the one hand, the non-repudiation and the integrity of data, and on the other hand, to identify and to authenticate a person or an organization and also to encode communications.
A digital certificate includes several information, as:
- A public key
- Authentication information
- A validity time
- An issuer that signs the certificate
This last point is crucial to verify the trustworthiness of a certificate. For this, when a certificate is received, a chain of trust is built to a certificate authority.
To explain the working of the chain of trust, let’s present some notions:
A certificate authority (CA) is a trusted third party that issues digital certificate and also provide people a way to verify the issued certificate.
It is thanks to the certificate authority that we can know if a certificate has been revoked or is valid.
A root certificate is a digital certificate self-signed that identifies a certificate authority. Modern browsers and operation systems include a root certificate roots, and therefore a list of certificate authorities.
For example with Firefox, we can see the list of certificate authorities in:
Preferences > Privacy & Security > Certificates > View certificates
Chain of trust
To establish a chain of trust, it only needs to look at the certificate issuers until getting to a root certificate.
Then, if this one is included in the browser or the device, the chain of trust is established.
Let’s take for example https://vaadata.com/
We can see that the certificate has been delivered by Sectigo RSA Extended Validation Secure Server CA. It is then a certificate authority (visible with the CA). The chain of trust with Vaadata has been established.
To sum up, a certificate is considered valid when:
- The certificate has not expired, i.e. we are within the validity period
- A chain of trust has been established
- The certificate has not been revoked
However, one of the weak points of this process is that, if one element of the chain of trust is compromised, fraudulent certificates can be delivered.
An encrypted connection is established as following:
- The browser asks for a secure connection to the server
- The server sends its certificate to the browser
- The browser verifies the certificate
- If it is valid, the browser sends a unique encryption key to the server, key that is encoded with the public key that the server has in the certificate.
- The server decrypts the unique key with its private key
- The server and the browser now have a unique key that enables them to encrypt and decrypt their communications with the unique key.
Let’s place ourselves now in the case of the use of a proxy (for example Burp) or of a Man-in-the-Middle attack.
- 1. The browser asks for a secure connection to the proxy
- 2. The proxy sends its certificate to the browser
- 3. The browser verifies the proxy’s certificate
- 4. If it is valid, the browser sends a unique encryption key to the proxy, key that is encoded with the proxy’s public key in the certificate
- 5. The proxy decrypts the unique key with its private key
- 6. The proxy and the browser now have a unique key that enables them to encrypt and decrypt their communications with the unique key
- 7. The proxy asks a secure connection to the server
- 8. The server sends its certificate to the proxy
- 9. The proxy verifies the certificate
- 10. If it is valid, the proxy sends a unique encryption key to the server, key that is encoded with the public encryption key the server has in the certificate
- 11. The server decrypts the unique key with its private key
- 12. The proxy and the server now have a unique key that enables them to encrypt and decrypt their communication with the unique key
For this use case to work, it is necessary that the proxy or the attacker has a valid certificate. In the case of a proxy, we can for example install a root certificate certifying the proxy.
In the case of an attacker, he might have a valid certificate if a link in the chain of trust has been compromised. The attacker can also find a way to install a root certificate that he would have generated on the computer of its target.
Certificate Pinning, Key Pinning and Hash
To be sure to communicate securely with the right server, and therefore to protect oneself against a man-in-the-middle attack, some methods exist. We describe them below:
When the application receives the certificate sent by the server, it compares it with the certificate that it has inside.
If the comparison between the two certificates is different, the encrypted communication fails.
The use of certificate pinning is, most of the time, observed in the case of a mobile app, as it is easy for the developer to include the expected certificate.
When the certificate arrives to expiration, the app has to be updated to insert the new valid certificate. This is the disadvantage of this method : if a service regularly changes its certificate, the app has to be updated regularly.
Public Key Pinning
This method consists in pinning a public key instead of a certificate. Then the public key pinned is compared to the public key extracted from the certificate.
Another method is to compare information hashes instead of the certificate, or of the public keys. This process has many advantages, such as:
- Hashing allows to anonymise hashed information, indeed it is theoretically impossible to find back information from a hash (provided to use a good hash function such as sha256 or sha3).
- Easy to use, many libraries provide digital fingerprint certificate.
The methods described above enable to strengthen the encrypted communication security. However, they are far from being infallible. Indeed, many tools exist to easily bypass them. For example, there is the ssl-kill-switch app on iOS. On Android, it is possible to use Frida scripts.
Implementation costs of these solutions appear as relatively high for the security advantage they bring. These protections concern rather applications manipulating sensitive data, such as banking applications.