When an SSL socket is connected, it joins an SSL session. Every SSL socket belongs to one SSL session. If there are many connections between a client and server they may share an SSL session, but there is no programmatic way to determine which sockets are attached to which sessions. From our perspective, the SSL session is just an object that allows us to retrieve certain information about a particular SSL connection. Specifically, the SSL session allows us to perform a necessary (but often ignored) step in the verification of an SSL peer.
In our first example, the server has sent its certificate to the client. If the client recognized the CA that issued the server’s certificate, we allowed communication to proceed. However, as we’ve mentioned before, just because someone has a valid certificate does not necessarily mean that they can be trusted. I can get a valid certificate for www.myevilenterprise.com and then spoof your DNS server so that when you attempt to connect to shopping.oreilly.com, you get connected to me. Just because I present a certificate to you is no assurance that I am authorized to take your credit card information.
So when you make an SSL connection, you should verify that the server certificate contains the information you expect. Typically, this means that the name within the certificate should be the domain name of the machine to which you’re connecting. If your server requires clients to authenticate themselves, the server should follow this ...