Say Alice wants to open up an HTTPS connection to Bob through a proxy named Earl.
What prevents Earl from reading alices request, opening a connection pretending to be bob, and then opening a https connection with bob pretending to be Alice , and snooping on the traffic as it passes through ?
Certificates and four-way handshakes.
The handshake is done in a way that nobody could intercept it. Both parties have undisclosed secrets.
The certificate is signed by a trusted authority, which can be verified with a certificate from the authority who signed it. Nothing can be forged without private keys, which are never transmitted.
My company uses a proxy which breaks end-to-end encryption and intercepts/forwards everything without either end party being aware. This is done by manually installing an authority certificate on every client in the office, and the server dishes out forged certificates for every connection. The clients explicitly trust the forgery.
This is why I prefer to work from home, with a personal PC next to me on my own network. I refuse to browse the web on company hardware.
Oooh that makes alot of sense, thanks and thanks everyone. So https cant be used for peer to peer , you need a server with a certificate from a trusted authority…
Right. You’ll get a warning otherwise. If you’re setting up a lab for yourself, though, you can set up your own trusted authority and use that to issue certificates and it ends up very much like
within your lab.
When Bob sets up an HTTPS web site (call it
bob.com), he creates a public/private key pair, and has the public key signed by a certificate authority (CA) such as Let’s Encrypt, generating a public key certificate. The certificate says that this key was signed forbob.comon a particular date.Before issuing the certificate, the CA verifies that Bob is actually in charge of
bob.com. This is important! They can do this, for instance, by asking Bob to put a particular file on thebob.comserver, in a place that’s publicly accessible. This proves that Bob actually has control over thebob.comdomain.Bob then puts the key pair and certificate into his web server configuration. Neither the CA, nor anyone else but Bob, have access to the private key; it only lives on Bob’s servers.
When Alice’s browser connects to
bob.comit gets the public key certificate, and can check that it was signed by a trusted CA. If Earl injects a different public key, it won’t be signed tobob.comand so Alice’s browser will reject it. And without access to Bob’s actual private key, Earl can’t eavesdrop on the session.If the CA is corrupt or incompetent, and issues
bob.comcertificates to people other than Bob (such as Earl), that’s a problem! That has been a problem before. There have been CAs that have been “cancelled” for issuing wrong certificates; they are no longer trusted by browsers. Major web companies have put together Certificate Transparency to keep a public log of what certificates have been seen on the web, which makes it possible to at least notice if someone other than Bob is generating certificates that say they’re forbob.com.This is a good question, I dont know who would downvote that.
ELI5: Alice and bob have an aunt that knows them both and has an unfakeable voice recognition service that allows both to verify who they really speak to.
The security of HTTPs relies on public key certificates.
I recommend reading up on it here: https://en.m.wikipedia.org/wiki/HTTPS#Overview
Especially the part after this segment:
Web browsers know how to trust HTTPS websites based on certificate authorities that come pre-installed in their software.
This is about PKI. An HTTPS server has a TLS cert, and that TLS cert is signed by / created by a certificate authority (or CA). When you connect to a service over HTTPS, a TLS handshake happens. The handshake starts by the client asking a server to setup a session, and the server hands back it’s certificate. This certificate can be used to encrypt traffic, but not decrypt it. The client makes sure the certificate is signed by a CA it trusts (such as let’s encrypt).
Once the client has this certificate, it sends a key to the server in encrypted form, and the server decrypts it. They both now use this key to communicate.
The MITM server can’t compromise the session because: If it swaps the certificate (or in other words, the encryption key the server sent), that key won’t be trusted because it isn’t signed by a CA the client trusts.
If the MITM tries to send its own shared key signed by the servers certificate - it doesn’t really matter since it can’t read the clients messages anyways to get the shared key from the client. If it forwards it, then you effectively have two separate https sessions with their own keys, and the server will treat them as distinct.