TLS man in the middle security certificates

 

First of all, I apologize for sending yet another question about this seeing as there are so many related posts. After reading through them and related sites I'm still not clear on a few points.

  • Browser connects to server through secure socket
  • Server responds with its public key with its certificate. This is the step I have the most trouble with. In this message from server to client, can the certificate be easily separated from the server's public key? If it's a root certificate (one which is already included in the browser) then a man-in-the-middle can't fake it, but what if it's not? Can't whatever this online mechanism the client uses to verify the certificate be hijacked? Furthermore, if the client's computer is compromised, the root CA's can be compromised, right? Any steps that avoid this? One last thing: It is said that a certificate is insecure until signed. I can't figure out what this means, especially since a certificate can sign itself. I think it's supposed to mean that someone is assuring the authenticity of the message, so a certificate signing itself sounds insecure ("Are you a REAL certificate?"..."ummm, sure, sure I am"). If the mechanism for authenticating a certificate is the internet, I'm wondering how is that secure. Is signing a certificate the same as thing (literally) as saying the client verifies the certificate?
  • Session key is encrypted with public key and sent to server. This session key is a symmetric key that both server and client will use for remainder of encrypted communication.

    • I must say, most information online is so vague. So many holes in explanations and hand-waving going on. My guess is that very few people know the actual mechanisms very well?

    You've left out several steps. One of them is that the server sends a digital signature over the entire handshake so far, signed with its private key. Only the server can do that, with its own certificate. Nobody else's. The client verifies the digital signature using the public key in the certificate that was sent. That proves that the server owns the certificate. It also proves that the server is the same entity that sent all the other handshake messages.

    BTW your step 3 is imaginary. The session key is never sent at all. It is computed independently at both ends.

    EDIT Comments on your answer:

    Server (from JoesGoods) gets a certificate from the CA via?

    Usually via an Internet browser.

    Can this be hijacked?

    No more than any other secure SSL session can be.

    The certificate is "signed"

    Correct.

    which means a bit of it is encrypted using the CA's private key.

    No. You made that up.

    Specifically the bit that has the web server's info (JoesGoods' server info)

    No. You made that up.

    The entire certificate is signed, and that does not mean 'encrypted', with the CA's private key.

    Bob's browser connects to server through a secure socket and sends a "hello" packet.

    The socket isn't secure at this point. It's just plaintext.

    The server sends its public key and certificate to Bob.

    No. The server sends its certificate. The public key is already inside the certificate.

    the browser checks that the webserver (JoesGoods) matches what's in the signed portion of the certificate

    The entire certificate is signed. The client checks that the server it is connecting to matches the subjectDN of the certificate.

    The webserver's public key is also signed with the CA's private key

    Because it's in the certificate. Otherwise there is no other way this can be accomplished. That's why it isn't sent separately, and it's also why the entire certificate is signed, not just the bits you like.

    The browser sends a client key exchange packet to the webserver (JoesGoods) using the webserver's public key included in step (2).

    This part is cipher suite-dependent. What you have described applies to RSA cipher suites. Diffie-Hellman is a different story, and there is room for expansion to include others.

    This client key is used to generate symmetric keys to conduct the remainder of the exchange. This client key is called a "premaster secret" and is a random key. Since the symmetric keys are created using this key, I wonder why not just send the symmetric key itself since the connection is encrypted and validated at this point.

    Because it wouldn't be nearly as secure.

    You also have some of these steps out of order.

    I really don't see the point of enumerating all these steps informally when they are already completely specified in RFC 2246. There's enough misinformation about TLS floating around the Internet already, such as this piece of unmaintained drivel.

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

    上一篇: SSL公共私钥逻辑

    下一篇: TLS中间人安全证书