Security

Great question. Modern encryption schemes are usually composed of a handful of primitives. If we consider something like HTTPS it uses both asymmetric and symmetric parts.

Asymmetric encryption is the "magic" that you are missing. Asymmetric encryption algorithms create a keypair, one half of this is the "public key" which can be used to encrypt messages that can only be decrypted by the "private key". This means that even if the public key is public (as the name suggests) the messages can't be decrypted without the public key.

You can think of this as giving someone an open padlock. They can put something inside a box and lock it using the padlock, but they can't open it without your key.

Using this you could come up with a very simple protocol for establishing a secure channel:

1. The server sends you their public key, along with a certificate that proves that it belongs to them.
2. The client then uses this public key to encrypt a key for symmetric encryption.
3. The client sends this encrypted key to the server.
4. The server decrypts the key.
5. Now the client and server can both use the shared key to communicate.

(Note: There are many missing features from this system, but I think it illustrates the point. Don't design your own crypto.)

For encryption, the client and server need to share their private keys.

This is incorrect, for asymmetric (public-private) encryption. You never, ever share the private key, hence the name.

The private key is only used on your system for local decryption (someone sent a message encrypted with your public key) or for digital signature (you sign a document with your private key, which can be validated by anyone with your public key).

For the server, they are signing their handshake request with a certificate issued by a known certificate authority (aka, CA, a trusted third party). This prevents a man-in-the-middle attack, as long as you trust the CA.

The current gap is in inconsistent implementation of Organization Validation/Extended Validation (OV/EV), where an issuer will first validate that domains are legitimate for a registered business. This is to help prevent phishing domains, who will be operating with TLS, but on a near-name match domain (www.app1e.com or www.apple.zip instead of www.apple.com). Even this isn’t perfect, as business names are typically only unique within the country/province/state that issues the business license, or needed to be enforced by trademark, so at the end of the day, you still need to put some trust in the CA.

Certifying Authority ensures secure connection establishment. If CA is corrupt, your system will work.

Why are they sharing private keys?

The point of the system is you share public key so others can encrypt data and the you use your private key do decrypt it.

You've missed a key detail in how asymmetric encryption works:

• For asymmetric encryption algorithms, you essentially have two keys - a "private" key, and a "public" key
• If you know the private key it is trivial to calculate the public key, but the reverse isn't true - just given the public key, it is essentially impossible to calculate the private key in a reasonable amount of time
• If you encrypt something with the public key you must use the private key to decrypt it, and if you encrypt with the private key you can only use the public key for decryption
• This means that my server can advertise a public key, and you can use that to encrypt the traffic so that only the server that knows the private key can decrypt it

This is the video that finally explained it in a way that I totally understood.

TLDW: the actual key exchange works by using massive exponents that are very fast to run to get a result, but very hard to use that result to get the exponent you started with

Great question: it's called asymmetric cryptography for a reason.

The key pair is built by the person wanting to receive private messages. The public part is made public an can be used to encrypt messages to the owner of the private key. Without it you cant read the contents.

As this method is not really performance friendly, thus method is usually used to establish a symmetric encryption key for both parties that can't be intercepted this way.

In fact: if the attacker can switch out the public key for his own during transfer, he can use it to decrypt the messages and relay them to the first party, thereby revealing all the messages. This is called a man-in-the-middle attack. This is why authentication of the key is so important. This is usually done via a trusted third party.

Sorry to be so short, I hope I have given you enough words to Google for further reading.

The beauty of a private key is that it doesn't need to be shared to be used

Diffie Hellman key exchange (video)