How does SSL actually work?

Question

Whenever I see it being talked about, it sounds like one simply 'turns on' SSL and then all requests/responses to/from an online server are magically secure.

Is that right? Is SSL just about code - can I write two apps and make them communicate via SSL, or do you have to somehow register/certificate them externally?

Answer 1

For the most part you need to buy and register a certificate externally.

Answer 2

Turning on TLS (colloquially "SSL") does not make your site magically secure. You may still be vulnerable to application-level vulnerabilities like stack overflows, SQL injection, XSS, and CSRF.

As other answers have explained, TLS only protects against a man in the middle. Traffic between a client and a properly-configured TLS server cannot be intercepted or modified, and the client can reliably confirm the identity of the server by validating the X.509 certificate. This prevents an attacker from impersonating your TLS server.

Answer 3

Secure web pages are requested on port 443 instead of the normal port 80. The SSL protocol (plenty complicated in and of itself) is responsible for securing communication, and using the certificate information on both the SERVER and the BROWSER to authenticate the server as being who they say they are.

Generating an SSL certificate is easy. Generating one that is based on the information embedded in 99% of web browsers costs money. But the technical aspects are not different.

You see, there are organizations (Verisign, Globalsign, etc...) that have had their certificate authority information INCLUDED with browsers for many years. That way, when you visit a site that has a certificate that they produced (signed), your browser says:

"well, if Verisign trusts XYZ.com, and I trust Verisign, then I trust XYZ.com"

The process is easy:

Go to a competent SSL vendor, such as GlobalSign. Create a KEY and Certificate Request on the webserver. Use them (and your credit card) to buy a certificate. Install it on the server. Point the web-browser to HTTPS (port 443). The rest is done for you.

Answer 4

Yes and no. You should self-sign a certificate and test the site with SSL internally before deploying it with SSL, first of all. To make the public site secure under SSL, you will need to purchase a certificate from one of any number of certificate providers. Then you will have a certificate signed by a trusted third party, tied to your domain name, so that users' browsers won't complain that the certificate is invalid, etc. Turning SSL on is pretty much just flipping a switch, otherwise.

Answer 5

SSL actually does two things:

1. Encrypts the communication so that an observer seeing the data stream will not be able to read the conversation.
2. Guarantees that you are talking to who you think you are talking to.

It is only for #2 that you need to get official certificates. If you only care to encrypt the communication without setting up a trust relationship, you can use self-signed certificates or you can use an algorithm that does not require certificates (i.e. Diffie-Helman).

Answer 6

SSL is not, in itself, a magic bullet that makes everything secure. Security has no such things.

SSL is, however, an already-designed, ready-to-use system for solving a common problem: secure stream communication over a network connection.

There are two things you need to do to secure your application with SSL:

• Modify the application's code to use SSL.
• Determine the certificate trust model (and deploy and configure the application respectively).

Other answers and documentation provide better answers to how to do each of these things than I could provide.