It’s my understanding that the way HTTPS works is that the server provides a public key to any browsers requesting content. A man-in-the-middle could not view data transmitted to the server because the private key would be required to decrypt it. Would it not be the case that data sent back to the browser could be decrypted because anyone can find out the public key?
Thanks,
Rob
No. Assuming that the server has a certificate and the client doesn’t, the client can create a session key and encrypt that with the public key of the server’s certificate. Then only the server can decrypt it with its private key and thus the only two systems who know the session key are the client and the server so they can use a simple/fast symmetric cipher (i.e., a crypto algorithm with one key that must remain secret) to encrypt the actual data.
Public keys are only used for encrypting and authenticating. The private key is needed to decrypt.
As iljitsch says, the public/private keys are used only at the beginning to negotiate a temporary shared key for the session. That’s what is used to encrypt and decrypt messages. Negotiation could in fact be done without needing public key crypto at all - the main reason for all the public key stuff is not encryption but authentication, to prevent a MITM from impersonating the real server.
Having just gone through a thorough security audit, there are some encryption schemes used in older SSL versions that have weaknesses making them relatively easy to crack. Capturing enough traffic will allow the private key to be cracked. For security, these can be disabled on the server side as they have been superceeded by stronger encryption.
There are also some MITM attacks named BEAST and CRIME that target SSL. The server has to be hardened to mitigate these attacks.
If you want to see how sites you use do, you can try this out: