I know that HTTPS helps to ensure security when data is being transferred from A to B, what I don’t understand is why an attacker can’t intercept the data is just decrypt it as HTTPS sounds to me as something “public”, wouldn’t that mean decryption is also publicly accessible?
In: 6
HTTPS uses a form of decryption known as asymmetric encryption. The key used to encrypt something is different from the key used to decrypt it. So you can publicize and share the public key with someone, allowing them to encrypt something and share it with you, but no one else will be able to decrypt it unless they have the private key, which only you have.
Think of it this way (oversimplified):
If I want to transfer data from me to you, we could both have a key that fits a really secure padlock (that we exchange when we meet).
But how do we do that if we never meet? If I have the padlock and the (secret) keys, how do I get one of the keys to you, or vice versa?
Well what if some really smart people came up with a special kind of padlock, which uses different keys to lock and unlock?
The key to lock the padlock can be made public. It can be sent through the regular mail.
So you just send me your locking key and the lock, I lock up the data, and now it can’t be unlocked by anyone who doesn’t have the unlock key – and only you have that.
This is “public key cryptography” oversimplified. This is how you communicate securely over the internet with servers over HTTPS.
HTTPS is a *method*, an eavesdropper doesn’t have the *key* to decrypt the data. Everyone knows how a standard lock works but knowing how it works doesn’t mean they know the key bitting for your front door.
There are also encryption methods with “public” and “private” keys. With this kind of encryption someone can encrypt a message with their private (secret) key and it will be able to be decoded with the public key. This shows people that the message came from the holder of the private key but doesn’t tell them what that key is.
One of the most widely used forms of encryption – PGP or Pretty Good Privacy – is 30+ years old. The methodology for using it is well understood and well implemented worldwide.
It hasn’t been broken yet, despite literally thousands of people trying over the years.
Good encryption doesn’t depend on the methodology being secret. It depends on the methodology being sound.
HTTPS is secure because encryption is secure, basically.
Encryption refers to a vast number of ways to establish some way of encoding text so that only a very limited number of people can read it. If you’ve seen ciphers or the enigma machine, encryption is effectively that. TLS (the encryption suite used by HTTPS) has a variety of ways to encrypt data, but they all boil down to “make a math problem so hard that you can’t solve it in a reasonable amount of time”.
The first problem we generated is around prime numbers. If I ask you what the factors of 59052041 are, you’ll have trouble working it out. Throw it into a computer, and it’ll try numbers until it tells you that 5039 and 11719 are the only factors. In encryption, we start dealing with numbers that are 600 digits long or more (2048 bit numbers). That makes it impossible to just try all the possible factors. So long as everything else around the encryption is secure, it’s highly unlikely that it gets broken. This method is known as RSA encryption. There’s a bunch of other methods and add-ons for extra security, but it all comes down to “it’s really easy to make really hard math problems, and the only way to solve them is by being the one who created the problem, being given the answer or the creator messing up”.
Now, does this mean all encryption is secure? No, but when a given form of encryption is found to have a vulnerability, it typically stops being used.
imagine you have a briefcase, and it has two spots to attach a standard padlock. You attach a padlock you have and lock it, keeping the key. Then you send the briefcase to the other person, the other person doesnt touch your lock, but instead attaches their own padlock and locks it, keeping their key. Then they send it back to you.
You now have a briefcase with two locks. You unlock your padlock, then send it back to the other person. they unlock their padlock, and now they can access the contents.
This is a basic understanding of encryption.
The attacker can’t decrypt without the decryption key, which they don’t have.
HTTPS works because of two ideas: [key agreement schemes](https://en.wikipedia.org/wiki/Key-agreement_protocol) and [digital signatures](https://en.wikipedia.org/wiki/Digital_signature)
A key agreement allows two parties to agree on a secret encryption key while an eavesdropper viewing the exchange learns nothing.
A digital signature allows someone to “sign” a piece of information using a *private key*. This signature can be verified by anyone using the corresponding *public key*. The public and private key are mathematically related, and only someone with knowledge of the private key can produce a valid signature.
HTTPS uses both of these to establish a secure connection.
The exchange between your browser and the HTTPS website roughly goes like this:
1. Browser makes a request containing a list of encryption algorithms it can support
2. Server responds with a signed message. Your browser verifies the message and the server’s identity.
3. The browser and server perform a key exchange
4. Now that both the browser and server know the secret key, they can send encrypted messages back and forth.
Any attacker watching the exchange learns nothing about the encryption key, and cannot decrypt any of the traffic. Any attacker trying to impersonate the server (i.e. a [man in the middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)) will fail because they cannot produce a valid signature.
A server has a public key. Anyone going to that website has access to the public key. The public key is meant for the client to be able to encrypt a message to the server that the server can only decrypt with its private key. That’s the beginning of the conversation.
Meanwhile the client has checks in place to make sure that the public key actually belongs to the server and that it’s valid. There are several checks, the least of which is that the server’s public key must be signed and endorsed by a well known certificate authority. The certificate must also be current (both a valid start and end date), not revoked, and the name of the website in the certificate must match the name of the server.
If any of these checks fail, your browser presents a message warning you and prevents the site from being displayed without your consent.
To that, there is an attack known as Man-in-the-Middle in which a bad actor acts as a middle man between you and the server, presents its own certificate as if it was the site you were visiting, and acts as a go-between, giving it access to your otherwise-encrypted information. Again, your browser will warn you unless you are in an environment such as a corporate one where your computer trusts a corporate proxy server inherently. This allows your employer to police encrypted web traffic and you would only know by looking at the details of the certificate.
Once the browser decides the public key belongs to the server and everything about it is kosher, the client and server then generate their own special key that all the actual web traffic will be encrypted with.
TL;DR: your encrypted web traffic is protected by a unique key that is only agreed upon after your browser makes sure your communication with the server is safe and that the server is who it says it is.
Latest Answers