CODEWITHSUNDEEP
encryptionssl-certificate
Simon
Simon

Reputation: 413

How does SSL encrypt data from server to client?

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.

Upvotes: 23

Views: 15510

Answers (2)

kapil
kapil

Reputation: 851

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.

Upvotes: 10

emboss
emboss

Reputation: 39620

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.

Upvotes: 11

Related Questions