As promised, today we are going to look a bit more in depth into how SSL/TLS works. In order to do so we will need to talk about cryptography.
Cryptography is the practice of securing communications against potential adversaries — people who might want to interfere with the communication, or just listen in.
TLS is a protocol that is most often used to implement secure HTTP connections (ie HTTPS). It uses multiple crypto paradigms:
Let’s look into each of them and explain a bit better how and why they work.
Public Key Encryption
Public key encryption is a type of cryptographic system where each party has both a private and a public key, which are mathematically linked to each other. The public key is used for encrypting plaintext to “ciphertext”, while the private key is used for decrypting. As the name suggests, the public key can be given to anyone freely without compromising the security of the private key. The only party able to decrypt a message sent with the public key is the one having the private key. Let’s imagine the following scenario. A owns a private key and publishes its public key. B and C are both able to read it so B decides to cypher a message with A’s public key. If for any reason C happens to read B’s message, even having A’s public key, he will not be able to decrypt it. The only party able to do that is A.
The main benefit of public key cryptography is that two parties with no prior knowledge of each other can create a secure connection while communicating over an insecure connection. One of the most common way this exchange is performed is by using a Diffie-Hellman key exchange. Once this initial exchange takes place, the resulting shared secret can be used to encrypt further communications in that session using a much simpler symmetric key encryption.
Symmetric Key Encryption
This public key exchange only needs to happen once per session, the first time the client and server connect. Once they’ve agreed on a shared secret, the client and server communicate using a symmetric-key crypto system which is more efficient. With the shared secret they agreed upon earlier, the client and server can now communicate securely, encrypting and decrypting each others’ messages using the shared secret.
Everything seems to work perfectly so far, but there is still an issue.
Let’s get back to our scenario where B wants to comunicate with A using its public key. What happens if in the very first stage someone exchanges A’s public key with its own letting be believe that it is A’s? As you can see this is a potential risk. How can we make sure that A is A and not someone pretending to be A? This type of attak is also know as “Man in the middle” since the attacker is literally getting between A and B.
To solve this authentication problem, we need a way to make sure that entities are who they say they are. This is achieved by using Certificates. In the next article we will give a look into what they are and why they are so important.
If you want to learn more about the security level of Cloud solutions offered by Criticalcase contact us: one of our expert will help you to find the right solution for you.
Fill out the form and one of our experts will contact you within 24 hours: we look forward to meeting you!
Via Chambery 93/107-V 10142 – Torino, Italy
+39 011.5097366 | info@criticalcase.com
Via Industria 31/A, 6987 Caslano, Switzerland
+39 011.5097366 | info@criticalcase.com
124 City Road London, EC1V 2NX, London, United Kigdom | info@criticalcase.com
Compila il form e un nostro esperto ti ricontatterà entro 24 ore: non vediamo l’ora di conoscerti!
Iscriviti alla nostra newsletter per restare aggiornato sulle novità dell’universo Criticalcase
