How does SSL encrypt data from server to client?

21
votes

Most of the wiki articles describe how client browser uses the public key (certificate) encrypt sensitive data (such as username/password) and send this encrypted data to server. Server will use private key to decrypt it. I get this part. But no clear information saying how server encrypt data and send back to browser.

Use my online banking as example:

(0) I already accepted trusted certificate (public key) from my online-banking.

(1) Through SSL URL, My browser visit https://myonlinebanking.com

(2) I typed username/password to login. These data are encrypted, so the man-in-middle can only see meanless data.

(3) Bank web server received my encrypted data, and use its private key to decrypt it and authenticate my account successfully.

Now here are my questions:

How bank sends back my data? Bank encrypt the response data by what key? If bank encrypted with "public key", the man-in-middle can see it just as I can see it. So the man-in-middle doesn't know my username/password, but he can still see my account balance?

Thank you for your help.

2
encryptionssl-certificate
This is off-topic. If you have programming questions then stackoverflow is perfect. If you have security or cryptography questions then there is a stackexchange site for your needs. You don't mention what wiki articles you have been reading, but the Wikipedia article on TLS certainly answers your questions. - President James K. Polk
@Simon this is the perfect question which I was intended to ask (it in fact looks like the question I asked). But I didn't quite understood the answer you accepted actually answered your question "If bank encrypted with "public key", the man-in-middle can see it just as I can see it. So the man-in-middle doesn't know my username/password, but he can still see my account balance?" If you get it correct, Can you help me explaining the following statement from the answer? "your browser checks whether the certificate is bound to the exact host it is talking to." - Darshan

2 Answers

10
votes

You have some wrong assumptions:

  • The HTTP data is not always encrypted with public key of the Server, in order to send it to the Server.
  • The public key of the Server is just used in the beginning (handshaking protocol) to establish a secure key, for Secure key encryption (Symmetric encryption).
  • All the communication is over Secret key or Symmetric Key encryption, where the client (browser) and the Server use the same secret key to encrypt and decrypt data.

TLS (Transport Layer Security) protocol uses a combination of Asymmetric encryption (Public key) and Symmetric Encryption (Secure Key). The main communication with your bank is using symmetric encryption, for which the session keys (secure key) is established safely during TLS handshaking, using asymmetric encryption.

It is all in the TLS (Transport Layer Security) handshake, which is very well explained in this link.

8
votes

The TLS handshake process sets up a symmetric key between both parties, potentially using asymmetric cryptography in the process (the details depend on the exact algorithms that were negotiated between client/server). This way, the communication is encrypted on both ways, not only one-way.

The thing that ultimately protects you from a MITM, though, is the fact that your browser does some form of hostname validation. The certificate presented by the server in the handshake is first checked for its validity. If that succeeds, your browser checks whether the certificate is bound to the exact host it is talking to. If this check would be omitted, a MITM attack would still succeed, even if the rest of the communication strictly followed the protocol, including all the cryptographic elements. The attacker could simply pretend to be any host and execute the rest of the protocol dutifully, you wouldn't know the difference.