symmetric vs asymmetric encryption
- symmetric
- asymmetric
TLS uses both of the symmetric and asymmetric encryption, why and how?
What TLS provides?
- Confidentiality
- All the data is encrypted and nobody else can eavesdrop on your messages.
- Integrity
- means that the message is not manipulated on the way to its destination.
- identification
- Identification means that I can check that this message is coming from my peer.
- Reorder and Replay Attacks Prevention
- Attackers cannot impact us by resending captured encrypted packets.
- Privacy
- By observing encrypted messages nothing important can be concluded like users behavior.
Confidentiality
The client and the server encrypt the messages only using symmetric key in their session. (but how about public and private keys? I mean how about the asymmetric encryption then?)
I will explain this later but you should know at least that TLS uses asymmetric encryption for exchanging the symmetric key that client and server agreed on.
Anyways …
They just encrypt the messages…
and this encryption provides confidentiality for us.
Integrity
How you should identify that your peer messages are not manipulated?
Well, you can’t identify only with decrypting the messages.
To provide integrity TLS creates message authentication code for every message. message authentication codes (also called authentication tag or digest) are like hashes but they’re not the same because you need a key to create one of them.
TLS uses MAC Algorithms to create digests.
Identification
- Who is that guy behind this cringe message?
- How can you prove that this message is from your mate?
These are questions that TLS can answer.
A digital signature attached to a message can identify the sender.
TLS uses certificates to create chains of trust. We will talk about certificates later.
Reorder and Replay Attacks Prevention
Attackers can capture our packets, and then resend those packets towards us (maybe in random orders). But why?
Because the attackers expect a special behavior. when they resend our packets they can deceive us in some tricky way. We are vulnerable to this type of attack since we don’t provide a mechanism to mitigate this type of attack.
To mitigate this type of attack we can use:
- sequence numbers
- count the messages, store this number in the message, and if someone replied with old one drop that message
Privacy
OK now at least we have Confidentiality and Integrity. If someone eavesdrop on our messages, he cannot read our messages and he cannot change our messages.
But he can understand many things from our encrypted messages and our behaviors.
Solving the privacy problem is hard. but there are some efforts. Our goal is to provide some randomness into the messages, thus concluding anything from our encrypted packets are hard.
There are ways to provide some levels of privacy.
- Nonce
- (number used one; it’s just a random number) , we add this nonce to our messages
- initial vector
- (I don’t know how it works :D, If you know please ELI5 it to me)
- periodic key revoke
- (This one should confuse the eavesdropper)
- …
but still privacy is a concern
Timing correlation [WIP]
- nsa vs tor
- matching relevant users of signal using time correlation
There are some mitigations but with a penalty:
- random delays
- fake traffic between nodes
Forward Secrecy problem [WIP]
What if they (NSA/FBI/(… to be filled by Terry a Davis)) can decrypt our messages in the future?
They are storing our TLS packets everyday.
So can you guarantee ?
TLS handshake [WIP]
search about key exchange algorithm.
- Client Hello
- send a list of SSL/TLS versions and encryption algorithms
- Server Hello
- choose the best SSL/TLS version and encryption algorithm
- I reply with my certificate, which includes my public key, so they can verify who I am
- Client Key Exchange
- I check server’s certificate to make sure they are legit.
- I generate a ‘pre-master key’ so we can both use it later when we generate a unique key.
- I encrypt that pre-master key with server’s public key and then send it to him.
- Change Cipher spec
A fancy word for the encryption algorithm list is ‘cipher suite’.
Certificates
A certificate authority (CA) is a third-party organization with 3 main objectives:
- Issuing certificates.
- Confirming the identity of the certificate owner.
- Providing proof that the certificate is valid.
Becoming a CA is an intense task of security requirements and audits.
You need to be trusted to be accepted into a root store. A root store is basically a database of trusted CAs. Apple, Windows, and Mozilla run their own root stores that they pre-install in your computer or device.
Which certificate should you buy? You have basically 3 flavors.
Domain validated. The certificate just verifies the domain name, and nothing else. You probably need this one. Organization validated. The certificate requires the validation and manual verification of the organization behind the certificate.
Extended validation. The certificate requires an exhaustive verification of the business.
When a CA issues a certificate, they sign the certificate with their root certificate pre-installed in the root store.
Most of the time it’s an intermediate certificate signed with a root certificate.
If a catastrophe would occur and the root certificate is compromised, it’s easier to revoke the intermediate certificates, since the root certificates are installed on each device.
The entire certificate chain is trusted, and thus the site certificate is trusted as well.
Self-signed certificates can be forged. Basically, they say 'Trust me, it's me, I promise!'.
A trusted certificate says: 'Trust me, an authority verified me'.
Attack scenarios [WIP]
FAQ
- Difference between SSL and TLS?
- They are different things refer to the same protocol. TLS is the newer version of SSL.