Tls Deep Dive Part Three

A lot of we have discussed so far seems to overlap, the purpose of this post is to delineate what we have learned so far so that you understand how all the parts fit together in TLS. consider this a mini-review.

The above diagram is very helpful in clearing the confusion, as you can see hashing provides integrity and authentication, symmetric encryption provides confidentiality, and asymmetric Encryption provides all three, namely integrity, authentication, and confidentiality (if you are not sure how? go read the last post in the series).

But the question is which one to use?

The better question is when to use which one? as I wrote in the last post hashing and symmetric encryption are better for bulk data to provide integrity, confidentiality, and authentication, whereas asymmetric encryption is suitable for **_limited data _**to provide all three services.

Let’s Deep Dive

suppose the client and the server want to exchange bulk data and to make sure the confidentiality and integrity of that data they need to establish a mutual secret key.

Well secret key is a small amount of data, the prudent thing to do here would be to use asymmetric keys to exchange this secret key between the client and the server. and after the key exchange, the client and the server start to exchange data.

There is a problem though, anyone on the internet can generate a pair of asymmetric keys, even you sitting on your computer can generate a pair using OpenSSL, it will hardly take 30 seconds, so how to make sure that the server you are talking to is blue.com or google.com and not someone else masquerading as them?

Public Key Infrastructure

This is the point where a certificate authority comes in, it’s an entity that the client and the server both trust.

A certificate authority simply links asymmetric key pair to a specific identity, It provides a certificate that proclaims that the private key associated with the public key in this certificate is blue.com or google.com.

But how do we know that the certificate is legit? and that it is generated by the authority we trust.

well, that’s easy, the CA will digitally sign the certificate and if the client would be able to decrypt the certificate with the public key that it trusts, it would know that the certificate is legit.

as you can see in the diagram above, this communication scenario creates a triangle, with the client, the server, and the CA on the vertices, this triangle of trust is known by a fancy name Public Key Infrastructure.