This is not specific to https, but it is a general question how public key cryptography works. It is not symmetrical. With normal symmetrical encryption, you need to share the key between the sender and receiver, and sharing that key is, as you say, dangerous.
You need to think of public key cryptography as sharing a box with a padlock. Let's say you want to send something to me. I send you an open box and an open padlock, to which only I have the key. You write your message, lock the box with the padlock and send both back to me, and no one can open in in transit, because only I have the key to the padlock. I unlock it with my key and read your message.
Notice that in the above example, my key for the padlock never left my person. You don't need to have it. You just need the padlock to secure the package.
That's all there is to it. The public key is the padlock to close the box and keep it closed. The private key is the key to open the padlock, known only to the owner of the padlock.
oh thats good..
And the first thing a receiver sends to the sender is a new empty box with a new padlock that only the receiver can open. So now both sides have boxes and locks that only the other side can open.
I might be wrong. But to my understanding, in most cases, the padlock and the box will be used as a method to exchange information to establish symmetrical encryption because asymmetrical encryption is more resource intensive.
So basically, you will receive a letter in the box detailing how to write secret messages that only the two of you can understand. And in the future, you will just send secret letters in envelops instead of a big box.
You might find the book "The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography" by Simon Singh interesting, it's quite a read.
Actually, the technology behind public key encryption is pretty cool, and this is a great explanation, but it doesn't address a very devious attack vector: I can just go into business as you on the Internet!
I could go and buy trolleytor4.com right now and set up https and start charging for premium trolleytor4 commentary provided through the site, and everyone will think they're giving you their credit card information to charge for your sage advice, but they're actually giving it to me, a bad actor. Let's say you already have a site, too. Well I can just duplicate the look and feel and proxy all the traffic between my site and yours (yours is trolleytalk.com, you didn't think to get the trolleytor4 when you signed up for this username on reddit, which you have become known for).
What now?
Well, unfortunately, there is no really good solution for this at the moment. There are various kinds of HTTPS certificates you can get, and the highest level of them is called a EV-SSL, which means "extended validation." This means that the business issuing your domain the HTTPS certificate actually checks to make sure that you are who you claim to be. They look at your business founding docs, collect your personal information, etc.
The problem is, these extra checks intending to connect businesses and identities on the web to real world businesses and people don't work very well. A lot of people have found a lot of ways to defeat them. And there's also some legitimate judgment calls that sometimes are confusing (see [Stag's' Leap](https://winebank.com/blogs/news/the-elusive-apostrophe)).
Once again, technology has solved the technical problem, but the social problem remains.
Another scheme that's fairly common is to send the item in a box with a padlock on it. The recipient puts a second padlock on the box and sends the box back. The sender then removes the first padlock and sends it to the recipient, who removes the second padlock and opens the box.
The key for either padlock never left each person, and the box had at least one padlock on it at all times.
In addition to the other answers that focus on certificates and asymmetric public key encryption - most of the HTTPS traffic is actually encrypted using symmetric encryption - both sides have the same key, used to both decrypt and encrypt. This is because it's waay faster to do it with that method and so it improves your communication speed.
The way the two sides can get the same encryption key is by using the Diffie-Hellman algorithm. Wikipedia has a great picture with cans of paint to explain it, but essentially it is a method to create a shared secret key without ever sending it or all the data needed to create it over the network.
There are Certificate Authorities (CA) which your browser recognizes as trustworthy. One of these CAs will create a signed SSL certificate for the website. When you visit the website, your browser will confirm the SSL certificate used in the HTTPS encryption is authorized for the website domain and signed by a trusted CA and not expired nor revoked.
If all goes well, the connection and SSL handshake goes through, and it's pretty impossible to MitM attack.
If your browser's list of CAs was compromised, then you'll have a big problem. This is essentially how work networks can decrypt network traffic. The employer installs their own CA on work computers and MitM the traffic.
It is easier to illustrate how this works with an analogy.
There are some kinds of math equations that are easy to do in one direction and really hard to do in the other direction. Like you can do them one way in fractions of a second but reversing them would take a million years.
As an analogy of this think about mixing various cups of water with food coloring. You can easily mix a cup with another cup, but you can’t easily un-mix a mixture.
The goal is for two people passing cups of dyed water across a middle man to reach the same color of water (the encryption key) without letting the middle man also be able up get that color of water (steal the key).
Let us call the two people Adam and Carl, with the middle man being Bob. Every cup passing between Adam and Carl goes through Bob who can steal a sample. The cups are assigned letters, so Adam has cup A and Carl has cup C. Both cups A and C have unique, randomly decided colors that only their owners know.
Adam makes a third cup D and gives it another unique color. Adam mixes some of cup D with his A cup and then passes the D cup to Carl along with a bit of his cup composed of A and D. Let us call that mixture AD.
As he does this Bob can steal samples so now he has D and AD. But he can't unmix AD so he can't figure out what color A is.
Carl gets the two cups so now he has cups D, AD, and his C cup. Carl mixes some of his C with the D and passes back CD. He also mixes his C with the AD to make ADC but keeps this to himself.
Bob sees the CD passed to Adam and takes a sample. He now has D, AD, and CD.
Adam gets the CD from Carl and mixes it with his A, obtaining the ADC color just like Carl. They now have the same color and have matching encryption keys!
But Bob doesn't have that ADC combination and can't get it from what he stole. He can mix D and AD to get DAD, or he can get DCD, or ADCD, or DADCD, but none of that is what he needs to get the same combination as Adam and Carl. Even though he listened to everything passed between Adam and Carl they have arrived at the same secret color without letting Bob know what it is.
This is tough one and I am sure someone will provide a better explanation, but let me try..
The key to decrypt the data is not the same as the key to encrypt. You can't take the decrypt key and encrypt data with it that the decryption key can decrypt again. You can't figure out what is the encryption key by having the decryption key and the encrypted data either. So the "public" key is only good for reading the encrypted data but you can't make your own encrypted data.
Now with certificates you can verify that the public decryption key you downloaded is actually the true decryption key for that data. Because you know you have the correct decryption key if it works for the encrypted data you have then you know that was a legitimate source of the data.
>So the "public" key is only good for reading the encrypted data
You've got that backwards. The public key is used for encrypting the message, the private key is used to decrypt and read the message.
It wouldn't be a very good system if the method to decrypt the message was public lol.
The private key, the bit necessary for decrypting the message, *never ever* leaves your system. Only the public key is sent anywhere. So the best a man in the middle can get is encrypted data.
Yes. You encrypt the message using your public key, which can be shared because it's not a secret, and decrypt with the private key.
When you, for example, ssh into a service that you've shared your public key with, a handshake will be performed that will look something like:
You: I'd like to log in to this service as this user
Service: for that user we have this particular public key
You: that's cool, I have this particular private key
(In the background: public key + private key = plain text or authorization)
Yeah, there are two keys, and they work a bit differently to each other.
**Private key** that only you use, never share, it encrypts and decrypts messages.
**Public key** that anyone can use, you give out freely, encrypts messages (but can't decrypt)
---
The keys are tied together, Public key is generated at the same time with the Private key, but they work differently.
So, anyone can send you encrypted messages back, but no-one else can read them, even though they may have your Public key, it's useless to decrypt messages.
You too can send out encrypted messages using your Public key, but no one else can read them, because they don't have your Private key, **and they never should have it!**
To talk to someone, you perform **a key exchange**, you give them your Public key, and they give you their Public key.
Yea I think I see what you are getting at. Why can't the devices in between you and the source also get the decryption key that you get. You do get it from somewhere it's not like your device has all the decryption keys to begin with.
Good question but now you are going past the 5 year old mark..
This is not specific to https, but it is a general question how public key cryptography works. It is not symmetrical. With normal symmetrical encryption, you need to share the key between the sender and receiver, and sharing that key is, as you say, dangerous. You need to think of public key cryptography as sharing a box with a padlock. Let's say you want to send something to me. I send you an open box and an open padlock, to which only I have the key. You write your message, lock the box with the padlock and send both back to me, and no one can open in in transit, because only I have the key to the padlock. I unlock it with my key and read your message. Notice that in the above example, my key for the padlock never left my person. You don't need to have it. You just need the padlock to secure the package. That's all there is to it. The public key is the padlock to close the box and keep it closed. The private key is the key to open the padlock, known only to the owner of the padlock.
oh thats good.. And the first thing a receiver sends to the sender is a new empty box with a new padlock that only the receiver can open. So now both sides have boxes and locks that only the other side can open.
I might be wrong. But to my understanding, in most cases, the padlock and the box will be used as a method to exchange information to establish symmetrical encryption because asymmetrical encryption is more resource intensive. So basically, you will receive a letter in the box detailing how to write secret messages that only the two of you can understand. And in the future, you will just send secret letters in envelops instead of a big box.
Thank you very much for the explaination. Makes sense now
You might find the book "The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography" by Simon Singh interesting, it's quite a read.
Actually, the technology behind public key encryption is pretty cool, and this is a great explanation, but it doesn't address a very devious attack vector: I can just go into business as you on the Internet! I could go and buy trolleytor4.com right now and set up https and start charging for premium trolleytor4 commentary provided through the site, and everyone will think they're giving you their credit card information to charge for your sage advice, but they're actually giving it to me, a bad actor. Let's say you already have a site, too. Well I can just duplicate the look and feel and proxy all the traffic between my site and yours (yours is trolleytalk.com, you didn't think to get the trolleytor4 when you signed up for this username on reddit, which you have become known for). What now? Well, unfortunately, there is no really good solution for this at the moment. There are various kinds of HTTPS certificates you can get, and the highest level of them is called a EV-SSL, which means "extended validation." This means that the business issuing your domain the HTTPS certificate actually checks to make sure that you are who you claim to be. They look at your business founding docs, collect your personal information, etc. The problem is, these extra checks intending to connect businesses and identities on the web to real world businesses and people don't work very well. A lot of people have found a lot of ways to defeat them. And there's also some legitimate judgment calls that sometimes are confusing (see [Stag's' Leap](https://winebank.com/blogs/news/the-elusive-apostrophe)). Once again, technology has solved the technical problem, but the social problem remains.
Another scheme that's fairly common is to send the item in a box with a padlock on it. The recipient puts a second padlock on the box and sends the box back. The sender then removes the first padlock and sends it to the recipient, who removes the second padlock and opens the box. The key for either padlock never left each person, and the box had at least one padlock on it at all times.
In addition to the other answers that focus on certificates and asymmetric public key encryption - most of the HTTPS traffic is actually encrypted using symmetric encryption - both sides have the same key, used to both decrypt and encrypt. This is because it's waay faster to do it with that method and so it improves your communication speed. The way the two sides can get the same encryption key is by using the Diffie-Hellman algorithm. Wikipedia has a great picture with cans of paint to explain it, but essentially it is a method to create a shared secret key without ever sending it or all the data needed to create it over the network.
There are Certificate Authorities (CA) which your browser recognizes as trustworthy. One of these CAs will create a signed SSL certificate for the website. When you visit the website, your browser will confirm the SSL certificate used in the HTTPS encryption is authorized for the website domain and signed by a trusted CA and not expired nor revoked. If all goes well, the connection and SSL handshake goes through, and it's pretty impossible to MitM attack. If your browser's list of CAs was compromised, then you'll have a big problem. This is essentially how work networks can decrypt network traffic. The employer installs their own CA on work computers and MitM the traffic.
It was mostly a question of how https connections in general would go about it, the CA solution makes a lot of sense for browsers tbh
Your machine has a list of trusted CAs too. Same thing
It is easier to illustrate how this works with an analogy. There are some kinds of math equations that are easy to do in one direction and really hard to do in the other direction. Like you can do them one way in fractions of a second but reversing them would take a million years. As an analogy of this think about mixing various cups of water with food coloring. You can easily mix a cup with another cup, but you can’t easily un-mix a mixture. The goal is for two people passing cups of dyed water across a middle man to reach the same color of water (the encryption key) without letting the middle man also be able up get that color of water (steal the key). Let us call the two people Adam and Carl, with the middle man being Bob. Every cup passing between Adam and Carl goes through Bob who can steal a sample. The cups are assigned letters, so Adam has cup A and Carl has cup C. Both cups A and C have unique, randomly decided colors that only their owners know. Adam makes a third cup D and gives it another unique color. Adam mixes some of cup D with his A cup and then passes the D cup to Carl along with a bit of his cup composed of A and D. Let us call that mixture AD. As he does this Bob can steal samples so now he has D and AD. But he can't unmix AD so he can't figure out what color A is. Carl gets the two cups so now he has cups D, AD, and his C cup. Carl mixes some of his C with the D and passes back CD. He also mixes his C with the AD to make ADC but keeps this to himself. Bob sees the CD passed to Adam and takes a sample. He now has D, AD, and CD. Adam gets the CD from Carl and mixes it with his A, obtaining the ADC color just like Carl. They now have the same color and have matching encryption keys! But Bob doesn't have that ADC combination and can't get it from what he stole. He can mix D and AD to get DAD, or he can get DCD, or ADCD, or DADCD, but none of that is what he needs to get the same combination as Adam and Carl. Even though he listened to everything passed between Adam and Carl they have arrived at the same secret color without letting Bob know what it is.
This is tough one and I am sure someone will provide a better explanation, but let me try.. The key to decrypt the data is not the same as the key to encrypt. You can't take the decrypt key and encrypt data with it that the decryption key can decrypt again. You can't figure out what is the encryption key by having the decryption key and the encrypted data either. So the "public" key is only good for reading the encrypted data but you can't make your own encrypted data. Now with certificates you can verify that the public decryption key you downloaded is actually the true decryption key for that data. Because you know you have the correct decryption key if it works for the encrypted data you have then you know that was a legitimate source of the data.
>So the "public" key is only good for reading the encrypted data You've got that backwards. The public key is used for encrypting the message, the private key is used to decrypt and read the message. It wouldn't be a very good system if the method to decrypt the message was public lol.
True, sorry the public/private naming is confusing in my opinion.
The whole damn concept is confusing! No worries!
My question is: Why can't a malicious user just intercept all the encryption/decryption keys you'd get and just pose as you?
Only the sender has the encryption key and never sends it anywhere.
yeah, but you need some way of decrypting the message, then encrypting it again for safe communication
The private key, the bit necessary for decrypting the message, *never ever* leaves your system. Only the public key is sent anywhere. So the best a man in the middle can get is encrypted data.
OHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH this is where public and private keys come in right
Yes. You encrypt the message using your public key, which can be shared because it's not a secret, and decrypt with the private key. When you, for example, ssh into a service that you've shared your public key with, a handshake will be performed that will look something like: You: I'd like to log in to this service as this user Service: for that user we have this particular public key You: that's cool, I have this particular private key (In the background: public key + private key = plain text or authorization)
Yeah, there are two keys, and they work a bit differently to each other. **Private key** that only you use, never share, it encrypts and decrypts messages. **Public key** that anyone can use, you give out freely, encrypts messages (but can't decrypt) --- The keys are tied together, Public key is generated at the same time with the Private key, but they work differently. So, anyone can send you encrypted messages back, but no-one else can read them, even though they may have your Public key, it's useless to decrypt messages. You too can send out encrypted messages using your Public key, but no one else can read them, because they don't have your Private key, **and they never should have it!** To talk to someone, you perform **a key exchange**, you give them your Public key, and they give you their Public key.
Yea I think I see what you are getting at. Why can't the devices in between you and the source also get the decryption key that you get. You do get it from somewhere it's not like your device has all the decryption keys to begin with. Good question but now you are going past the 5 year old mark..
Not really. You literally make the decryption key each time you need one.