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 ?
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.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
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:
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.
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.