title: SSL and man-in-the-middle misunderstanding
body: <p>I've read tons of documentation related to this problem but I still can't get all the pieces together, so I'd like to ask a couple of questions.</p>
  
  <ol>
  <li><p>First of all I'll describe briefly the authentication procedure as I understand it, as I may be mistaken in that regard: A client starts a connection, which a server responds to with a combination of public key, some metadata and digital signature of a trusted authority. Then the client takes the decision if she trusts the server, encrypts some random session key with the public key and sends it back. This session key can be decrypted only with private key stored on the server. Server does this and then the HTTPS session begins.</p></li>
  <li><p>So, if I'm correct above, the question is how the man-in-the-middle attack can occur in such scenario? I mean, even if somebody intercepts the server (e.g. www.server.com) response with public key and has some means to make me think that he is www.server.com, he still wouldn't be able to decrypt my session key without the private key.</p></li>
  <li><p>Speaking about the mutual authentication, is it all about the server confidence about the client identity? I mean, the client can already be sure that she is communicating with the right server, but now the server wants to find out who the client is, right?</p></li>
  <li><p>And the last question is about the alternative to the mutual authentication. If I act as a client in the situation described, what if I send a login/password in the HTTP header after the SSL session is established? As I see it, this information can't be intercepted because the connection is already secured and the server can rely on it for my identification. Am I wrong? What are the downsides of such an approach compared with mutual authentication (only security issues are important, not the implementation complexity)?</p></li>
  </ol>