The SSL protocol aims to provide solutions to two simple security problems:
How can we securely transmit data between two parties in such a way that only the two parties can read it?
How can one (or more) of the parties involved prove that they are actually the entity we want to grant the ability to decrypt our encrypted transmission?
SSL’s answer to the first question is encryption. Before transmitting any data, the sender encrypts its message, and the receiver must in turn decrypt the message before processing it. The encryption and decryption is accomplished through a method called “public key encryption.”
SSL’s answer to the second question is also part of the answer to the first question. In order for public key encryption to provide secure communication, one more more of the communicating parties must have some way of proving to the other that they are, in fact, who they claim to be. SSL provides this proof by requiring that one or more of the parties present a digital certificate into the initial negotiation of the connection, prior to the transmission of any encrypted data.
HTTPS vs. HTTP
The most common way that SSL is integrated into Internet communications is through the HTTPS protocol. Calling HTTPS a “protocol” is not entirely accurate, as it is simply a combination of the HTTP and SSL protocols. When we say a message was sent using HTTPS, what we are actually saying is that the message was first encrypted using SSL, transmitted and received using normal HTTP protocol, and then decrypted by the receiver, also with SSL.