Reg HTTPS man in the middle

Question

Possible Duplicate:
How is it possible that people observing an HTTPS connection being established wouldn’t know how to decrypt it?

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?

Answer 1

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.

Answer 2

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).

• Compromise the CA's private key. Key length and certificate lifetime are related at some level; keys are designed to be long enough that they can't be brute-forced with any current methods within the timespan that the certificate is valid. But, keys can be stolen, and the pace of technology is exponential (with some significant quantum leaps such as the advent of GPU-based parallel attacks). If the key is compromised either way, an attacker can create server certificates at will, impersonating any legitimate server. This is a CA's worst nightmare, and it has happened.
• Compromise the server's private key. Again, these keys are at least long enough that current hardware can't break them during the life of the certificate. If compromised, a man-in-the-middle attack on that server becomes feasible until the server owner requests a new certificate from the CA. This is a sysadmin's worst nightmare, and it has happened.
• Forge a server certificate. This is believed to be difficult by design in modern implementations, but successful attacks have been demonstrated on older versions of hashing and encryption algorithms like MD5, that have been and sometimes still are used for certificate generation.
• Convince the client's user that any problem with a bad certificate is minor and can be safely ignored. The reality is that no problem with a certificate can be safely ignored; if the certificate presented by a server is expired, doesn't match the actual server presenting it, wasn't issued by a trusted authority, or doesn't match its digest, it is potentially (probably?) compromised. However, companies, even reputable ones, don't always keep their certificates up to date, and certificates aren't always backed by a trusted CA. The smart user should discontinue use of such sites and inform the company of the lapse, but we're human, and that doesn't always happen either.
• Convince the client that the attacker is a trusted CA. This sidesteps the entire process; if the client machine or its user comes to trust the attacker, the attacker can then issue certificates identifying servers they control as being anyone the attacker wishes, servers that the client will then also trust.