SSL, or Secure Socket Layer, was first developed by Netscape in the mid-1990's to address the growing need to be able to securely transmit data. It protects data, verifies legitimacy of a website, and is supported by all major browsers. When you log into a banking website, your computer is sent a file called an "SSL certificate" which contains the following data:
Based on the certificate's info, your browser decides whether or not to trust the certificate. This is possible because it uses third-party data, already in your browser, to confirm the certificate wasn't sent by a hacker. Once the certificate is received, the browser checks that the certificate was issued by a trusted third party known as a certificate authority. The browser then uses the public key to encrypt a random, symmetric encryption key and sends it to the server. The web server then decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and the HTTP data. Finally, the browser decrypts a response from the server using the symmetric key and displays the information.
Due to the nature of the Internet, the path the content follows between a server and a web browser is not secure. There is always the possibility someone is using a "packet sniffer" to capture data as it passes through a network or, if you're wireless, right out of the air. This is where encryption comes in. Originally, SSL used 40-bit encryption, meaning the value of the key used to decrypt data was selected from 1 out of 1,099,511,627,776 possible values. Today, that level of encryption can be broken almost instantly; so, a 128-bit encryption is commonly used which means 340,282,366,920,938,463,463,374,607,431,768,211,456 possible values; increase it to 256 bits for more security and you have the theoretical number of atoms in the universe. Even with millions of today's top-of-the-line computers working together, brute-force decryption simply takes too long if data is encrypted properly. That said, it's always best to be paranoid because future technologies like quantum computing may render conventional encryption obsolete.
If a brute-force attack won't work, how else can SSL be compromised? No matter how air-tight a security system is, all that work is pointless if users trusted with access have weak passwords or can be tricked into providing their passwords. Although not SSL-specific, it's vital best practices are used to prevent non-technical, "social engineering" attacks.
There is also the possibility that browser and/or server flaws could be exploited. A good way to minimize the risk of a hacker taking advantage of exploits is to subscribe to twitter feeds or blogs related to web security. This way, vulnerabilities can be fixed shortly after they're made public. Another approach would be to establish a list of supported browsers so that you can block or redirect users whose browsers aren't secure.
Flaws in SSL itself could potentially be identified and exploited. SSL supports multiple types of encryption and, in 2008, researchers were able to spoof a certificates by exploiting md5 encryption. This was done with an array of 200 PlayStation 3's and it was made possible because some certificate authorities relied on md5 alone. So, the reliability of an SSL certificate is directly related to the reliability of its certificate authority. If a certificate authority issues an SSL to a hacker's site, users could be fooled into thinking they are on a legitimate site due to successful SSL authentication. Furthermore, some authorities use better encryption methods than others. You can get a certificate from GoDaddy for $70/year or you can spend at least $695 at Symantec. Guess which business takes security more seriously!
First, there's a yearly cost associated with SSL which must be weighed against the security benefit. Is there any data on the site that any hackers might use or is there any motivation for your site to be hacked more than another site? If you're doing financial transactions then you pretty much have to use SSL or users will not feel secure, not to mention it would be an obvious target for hackers. That said, if your site only contains openly shared data and is backed up regularly, the biggest risks might be that an admin's password could be captured or that users might use the same password on other sites that do contain sensitive data.
SSL also uses additional server resources encrypting and decrypting content. Although the difference is minor due to processing power of today's servers, it can be noticeable on high-traffic sites. If you want to mix secure and non-secure content on the same page then users may get a browser warnings, so this limits the ability to host some content elsewhere; for example, a content distribution network. Finally, extra time is needed to purchase the certificate, set up the server, configure the website, and test.
Sometimes SSL is a given, but it can be more of a qualitative question based on the balance between practicality and ideology. Yes, any unencrypted login is vulnerable to attack, but what are the chances? The best thing do is weigh the overall cost of SSL against how sensitive your content is and what might happen, worst case,if it is compromised. If you're not sure whether or not to use SSL but you have the money and don't see any major technical obstacles then go ahead and use it.
A less expensive alternative might be to integrate a service like PayPal that handles authentication outside your website. On the other hand, if SSL's authentication and encryption aren't enough, consider using physical tokens. A physical token is a device that assists with authentication. For example, the device may periodically display a different value used to log in based on the current time. This approach removes the reliance in the certificate authority and allows more control over who has access. It can even be used to establish a VPN connection to the server before the website can be accessed.
When configuring Drupal to use SSL, a good place to start is the Secure Pages modules which lets you define which pages are secure and handles redirects from or to secure pages as needed. If you're using Secure Pages with Drupal 6 then the Secure Pages Prevent Hijack module should be installed to prevent hijacked sessions from access SSL pages. Also, the Auth SSL Redirect module can be used to redirect authenticated users to SSL and it will work in conjunction with Secure Pages. If you're using Ubercart and want to either secure the whole site or just Ubercart pages then another option is Ubercart SSL and it can be extended to secure additional pages. In general, these modules help manage transitions between secure and insecure pages.
[Updated based on comment feedback.]
What do you think, what approaches do you recommend, and what do you recommend against?