SSL is a mechanism for securing a communication channel, a method of verifying the identity of the key owner. Why aren't passwords enough for that?
Passwords are a means to authenticate a user to see if he is who he claims to be. If the channel on which the password is communicated is not secure, however, it can be intercepted and the identity of the user compromised, permitting someone else to authenticate as that user.
While setting up an HTTPS connection to a server, the server's public key is given to my browser and they shake hands over the strongest common algorithm encryption algorithm is accomplished between them (my browser and the server) to create a symmetric key both of us can use for encryption and decryption.
My browser encrypts a message using the algorithm and the shared key with the server's asymmetric public key and sends it back to the server.
The server decrypts it with its private key and now both know the algorithm to use and the shared symmetric key for encryption and decryption.
A TCP socket connection is established and communication over this socket is henceforth encrypted using that shared key
How is the identity of the server verified? (Also important!)
There are four states to check in validating the server's key.
It's possible for a hacker to fake who he is.
This still does not guarantee you have the right server if the other conditions are not met. This is where signatures come into play.
How to solve this?
There's something called certificate authorities that check out companies and individuals requesting formal certificates—before issuing them. (These cerficates cost big money.) Examples of these companies are Verisign, Thawte and Digicert. (There are more.)
When these companies issue certificates, they sign them using their own certificates thereby vouching for the authenticity/identity of the individual or company requesting the certificate. These certificates are "trusted" something that most operating systems and virtual machines are able to detect. Also, browsers will present a modal dialog to the user when they encounter a certificate that is not trusted. The user then accepts responsibility for continuing on against the browser's advice against using it.
Back to the example, if the server (I want to connect to) presents a certificate that's been signed by one of these authorities, my software knows that certain checks were carried out. If not (as the case with the second server), then my software (or I) must reject it.
Beyond this, expired certificates are checked and also the expiration dates of other certificates in any chain must also be checked. A "chain" of certificates can arise when software encounters a certificate whose services lead to the use of another certificate, etc. An expired certificate may indicate that a software producer is out of business or some other reason and it's not a good idea to accept that certificate. There is also the positive case of a revoked certificate, one from an origin that's known to be bad and whose revocation is included in the certificate repository available to operating systems. There do exist "zero-day bugs" and other border cases, but usually the verification as it stands is reliable.
What's just been covered is server authentication. There also exists client or mutual authentication in more peer-to-peer situations.
There are two types:
How does symmetric encryption work?
Imagine a night safe at a bank. You can:
In practice, you can give out your public key so that anyone wanting to send you information (deposit cash/encrypt the information) can do so, but only you can decrypt it (retrieve the information).
You must keep your private key safe. Once it gets out, everyone can decrypt information.
When you connect via your browser to a site using HTTPS, the server passes your browser its public key (and information about the cryptographic algorithms it supports). With this information, your browser creates a symmetric key which it encrypts using the public key the server offered, then sends it to the server specifying the algorithm it chose (from among those the server said it can handle) to be used with the new key. Once done, both the client browser and the server have a shared, symmetric key with which they can exchange information (by encrypting and decrypting each other's communication).