A browser sends a request to gmail.com, gmail sends the cert with the pub key. if cert is intact and is verified from gmail, then client and server communicates. But whether a client C which knows gmail's public key can eavesdrop the data from gmail? Because the data from server is signed with the private key, Does anybody with the public key can eavesdrop it?
marked as duplicate by Thomas Pornin, Polynomial, Terry Chia, dr jimbob, Rook Nov 30 '12 at 18:01
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
You can get more details from Thomas Pornin's link, but the short answer is that the client uses the public key to make a new key and encrypts it with the public key so that only gmail can decrypt it. It sends this back and the two can start communicating. Since the legitimate client expects communication to use the key that only it and gmail can know, the man in the middle can't break it without knowing Gmail's private key which is not disclosed.
You're misunderstanding a few points, methinks.
X.509 certificates use RSA encryption, which is asymmetrically-keyed; one key is used to encrypt, the other to decrypt. Which one is "public" and which is "private" depends on the exact model used; all that matters is that for one keypair, one of the halves is kept secret, and that each half is always used to do the same thing (to encrypt or decrypt). What's often confusing is that in an X.509 certificate, there are two keypairs in play, and in one pair, the encryption key is private while in the other it is public.
The first pair belongs to the certificate authority or CA. It keeps the encryption key private, and publishes the decryption key as part of an "issuer certificate". Clients who trust this CA have a copy of this issuer certificate and use it to verify server certificates issued by that CA.
The second pair is used by the site to establish secure communication with clients contacting it. It is also generated by the CA, but the private key, used to decrypt data encrypted with the public key, is also known to the server. A certificate has all the information uniquely identifying the server (IP, domain, owning business entity, issuer information, and "handshake" public key), plus a message digest. This digest contains all the same information (including the site's public key), hashed using a "secure" algorithm (though MD5, with known vulnerabilities, is still popular), and then encrypted using the CA's private key.
To verify a certificate, the client takes all the information in the certificate except its signature and signature algorithm, and hashes it using the hash algorithm specified in the signature. It then gets the public key from the issuer certificate in the client's store, and decrypts the signature of the server certificate, producing the digest computed by the CA. If they match, the plaintext information of the certificate has not been tampered with since the certificate was generated by the CA (if the plaintext information had been changed, the hashes would not match, and only the CA has the private key that would correctly re-encrypt a tampered hash), and therefore the client should be able to trust it. That includes the fact that the public key on the site certificate has not been altered; therefore the only entity that should have the private key matching the public key is the server (the CA does not store these keypairs after generating certificates; it's trivial and in fact preferred for the CA to just generate an entirely new certificate with a new keypair if there are any suspicions about the key's integrity).
Once verified, the client can generate its own key (usually for a symmetric algorithm, like AES, as a block cipher is faster than RSA and only requires exchanging one key instead of the server needing to transmit yet another public key just for the session), use the server's public key to encrypt its own (along with information about the algorithm it wishes to use), and sends it to the server. If the server can use that method, it will set it up and respond appropriately, and from then on the two parties will use this negotiated secure tunnel for communication.
The upshot is that the only information an attacker can ever know is how to encrypt a message intended to negotiate the secure tunnel with the server. The attacker never sees the key(s) used for further communications between client and server. The only attack this allows is a DoS, where the attacker can pose as the client and request re-negotiation of a new channel; the server may then close the old one, shutting out the legitimate client. The attacker cannot compromise any information sent between client and server, which is the intent of the model (maintaining uptime is another area of system administration entirely).
To break this model and view secret information, an attacker must do at least one of the following, all of which are believed to be "difficult" (as in doing so would take longer than the information would remain secret and/or useful anyway).