Certificate Pinning vs E2E Encryption

Question

I see that there are some APIs which exchange some sort public keys to secure the content of https connection using asymmetric encryption. Is there any added benefit to this? As far as I know, it should be impossible to man in the middle a tls connection which have certificate pinning.

The benefit of end to end encryption is clear when the content is sent from an end user to another end user, making the backend server unable to read it. But I have seen some example where it's just sending data to the backend (end client to end backend), but some kind of asymmetric encryption was applied.

For example AWS S3 allows client to encrypt data before sending it. I read somewhere that Akamai might also encrypt the content. I have also seen some institutions which needs to use their card/keys to encrypt the content.

So back to my question, is there actually any benefit of encrypting content using some means (either RSA, or some device), and sending it over TLS with certificate pinning?

Answer 1

I see that there are some APIs which exchange some sort public keys to secure the content of https connection using asymmetric encryption. Is there any added benefit to this? As far as I know, it should be impossible to man in the middle a tls connection which have certificate pinning.

Have a read of how the whole TLS protocol works, it's a great article available here: How does SSL/TLS work?

In a nutshell public keys are used to allow content that has been encrypted using symmetric keys (keys derived as part of the protocol handshake) to be authenticated.

Man in the middle attacks are not always mitigated due to certificate pinning. For example if the browser has never visited the site before a man in the middle attacker could return their certificate that mentions nothing about pinning.

The benefit of end to end encryption is clear when the content is sent from an end user to another end user, making the backend server unable to read it.

No. It only protects the data in transit, when it arrives at the server anything on that server could in theory see the data.

But I have seen some example where it's just sending data to the backend (end client to end backend), but some kind of asymmetric encryption was applied.

For example AWS S3 allows client to encrypt data before sending it. I read somewhere that Akamai might also encrypt the content. I have also seen some institutions which needs to use their card/keys to encrypt the content.

S3 allows client side asymmetric encryption. Which means your local machine is encrypting the data before sending it on to AWS. This only means you, not even AWS, can see the contents of the files. This is for protection of data at rest, not data in transit.

So back to my question, is there actually any benefit of encrypting content using some means (either RSA, or some device), and sending it over TLS with certificate pinning?

It depends on your risk acceptance and compliance requirements. But yes encrypting data does not authenticate the data on its own. If you send someone an encrypted file, how do they know it actually came from you? Someone could have used your key. SSL/TLS encrypts but also authenticates the connection, so you know you really are 'talking' to the end point in which you started the communication. The certificate pinning adds assurance that you are indeed getting the same certificate that you did last time, and therefore less likely to be involved in a man in the middle attack.

Answer 2

I like to this of this problem in layers. TLS being where we’re using Pinning to ensure we only trust a specific server certificate is the highest of the layers (session/transport essentially) and we’re ensuring the non-repudiation of the server’s keypair. Eg. We know that the key pair we trust is the key pair we’re connecting to as well as the usage of the traditional chain of trust (verifying the signing CAs.) One could say it’s irrelevant to check the chain of a pinned cert, but we’ll ignore that for now as it doesn’t change the model significantly.

The Certificate itself is needed by the service providing TLS termination for the session, in most implementations outside of development/individual use we often see Web Servers/LBs that terminate TLS connections living separately from the Application servers that are responding to dynamic requests from end users.

The application server/processing is where the data that is inside of the TLS tunnel is going, but it’s not guaranteed to be controlled by the same person/organization that you are trusting by pinning the certificate. Adding additional encryption on top of the session layer (on the data itself) can provide additional confidentiality if that set of keys are controlled separately from the TLS server certificate (e.g. if you encrypted the data using your own symmetric keys.)



If we are talking about asymmetric encryption you could use a separate key pair to ensure identity on the client side (if the client has a keypair where the public aspect has been shared with the destination server) you could then encrypt data using your private key to demonstrate non-repudiation of you (who controls your client certificate) inside the TLS tunnel, allowing for confidentiality of the transaction and non-repudiation of the server, and after verification non-repudiation of the client.