How is SSL secure from MITM attacks?

This question already has an answer here:

  • SSL and man-in-the-middle misunderstanding 5 answers

  • As for faking a public key by MitM - that's why certificates are used. A certificate ties a public key to its owner, which in case of a website is its domain name. So if you enter ab.com, you will get a public key with a certificate for ab.com from the server (if not, the browser will complain). If there was a man in the middle, they would have to have a certificate issued for ab.com, which is not (easily) possible, but see CA hacks, where attackers exploit certificate authority flaws to issue fraudulent certificates.

    Also SSL handshake is much more complex than that, one part of it is called key exchange, and is about coming up with session keys to be used for traffic encryption based on the previously agreed algorithms. Note that there are multiple algorithms for coming up with session keys (generating it on the client and sending it encrypted with the public key is a very naive approach), and also multiple algorithms for using such keys for encryption.

    A "cipher suite" used during an SSL/TLS session is practically the list of algorithms chosen for different purposes.


    The client sends a (probably unencrypted, since the client has no information to encrypt with) request to the server, to asking for the public key (which is easily accessible to the MITM), which the server sends back to the client.

    No. The server sends a signed certificate back to the client, which contains its public key, along with a signer, and a digital signature using the server's private key.

    The client generates a random password that's never shared with anyone and encrypts it with the public key (which can only be used to encrypt data) and then sends this encrypted password to the server. The server decrypts the encrypted password with its private key (which only it knows, and can only be used to decrypt data), thus getting the client's password, without letting the MITM get it because he doesn't have the private key.

    Only in some cipher suites. Not all.

    Somehow, this is used to transfer sensitive information between the client and server (I'm not sure what the random password is used for.

    It isn't used at all except in some cipher suites. Regardless, a symmetric seesion key is negotiated by both peers and never transmitted at all.

    Couldn't all sensitive information just be encrypted with the public key?).

    No. You also have to establish identity, ie authenticate.

    I'm wondering why the MITM couldn't do this to decrypt the sensitive information:

    Because the MITM can't forge the digital signature over the certificate. Otherwise you're holding a secret conversation with .... anybody.

    Redirect all traffic from the client to a site owned by the MITM. This includes the client's request for the public key which will be replaced with the MITM's server's public key. Also, the replies should be disguised as replies from the real server.

    Not possible, see above.

    The MITM's server will decrypt this traffic with its private key, thus revealing the sensitive information. This sensitive information can then be encrypted with the real server's public key and sent to the real server so the client gets whatever it asked for.

    Not possible, see above.

    Your understanding of TLS and PKI is severely flawed.

    链接地址: http://www.djcxy.com/p/21732.html

    上一篇: 禁用CURLOPT的安全后果

    下一篇: SSL如何从MITM攻击中获得安全保护?