This discussion is solely on SSL and its requirement for the protection of the valuable information that your site contains. This post also focuses on the fact that some sites are really more vulnerable as compared against others depending on the data they contain, and this is the determining factor of whether or not to have SSL on a site.
Secure Socket Layer (SSL), was first developed by Netscape in the 1990's to cater to the growing requirement of transmit data in a secure way. SSL guards data, verifies legitimacy of a website, and it is supported by all major browsers. Suppose when you log into a banking website, then your computer is sent a file called an SSL certificate which contains the following data:
- The website's domain name.
- The website or associated business name.
- A public key which is a string of characters used to encrypt data.
- A private key which is used to decrypt data.
It depends on your browser decision whether or not to trust the certificate, based on the certificate's information. This is feasible as it uses third-party data that is already present in your browser, to confirm that the certificate wasn't sent by a hacker. After the certificate is received, the browser ensures 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. After this, 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. Lastly, the browser decrypts a response from the server using the symmetric key and displays the information.
Because of the characteristic of the Internet, the path that the content has to follow between a server and a web browser is not secure. There is always the risk of someone using a "packet sniffer" to capture a piece of data as it travels through a network or, in case you're wireless, even out of the air. This is where encryption comes into action. Initially, 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. At present, that level of encryption can be broken right away; so, a 128-bit encryption is commonly used; 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-notch computers working together, powerful decryption simply takes too long if data is encrypted properly. That being said, perhaps it's always better to be rather paranoid because of the future technologies such as quantum computing, as it may make conventional encryption obsolete.
If a powerful attack won't work, then how else can SSL be compromised? It doesn’t matter much how lethal a security system is, because all that work would go in vein if users trusted with access have weak passwords or can be tricked into leaking their passwords. Although not SSL-specific, its vital best practices are used to prevent non-technical, "social engineering" attacks.
It is also possible that browser or server flaws could be exploited. A solid way to considerably reduce the risk of a hacker taking advantage of exploits is to subscribe to twitter feeds or blogs related to web security. In this process, vulnerabilities can be solved soon after they're made public. Another way would be to set up a list of supported browsers, so that you can block or redirect users whose browsers are not secure.
then again flaws in SSL itself could potentially be identified and exploited. SSL supports multiple types of encryption and researchers were able to establish a certificate 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 consistency of an SSL certificate is directly related to the dependability of its certificate authority. If a certificate authority issues an SSL to a hacker's site, users could be tricked into thinking they are on a legitimate site due to successful SSL authentication. Moreover, some authorities use better encryption methods than others.
So, why is SSL not added to all websites?
Firstly, there's an annual cost associated with SSL which must be weighed against the security benefit. So, you need to know yourself whether or not there is any motivation for your site to be hacked more than another site. So, 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 obviously more attractive to hackers. Having said that, if your site only contains openly shared data and is backed up regularly, then the greatest risks might be that an administrator's password to 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 negligible due to the processing power of today's servers, it can be noticeable only on high-traffic sites. If you want to mix secure and non-secure content on the same page then users may get a browser warning. This limits the ability to host some content elsewhere; for instance, a content distribution network. Finally, extra time is needed to purchase the certificate, setting up the server, configuring the website, and for testing.
How to decide whether or not to use SSL on a site?
Sometimes SSL is really mandatory, but it can be more of a practical question based on the fact of practicality and sheer ideology. Indeed an unencrypted login is vulnerable to attacks, but what is the real susceptibility? The best thing do is to weigh the overall cost of SSL against how sensitive your content is and what could possibly happen, consider the worst case scenario if you choose not to have it. Then again, if you're not too certain whether or not to use SSL but you do have the money and don't see any major technical obstacles then move on to use it.
While configuring Drupal to use SSL, a proper place to start with would be the Secure Pages modules. This lets you define which pages are secure and handles redirects from or to secure pages as needed. Suppose you are using Secure Pages with Drupal 6 then the Secure Pages Prevent Hijack module should be installed to prevent hijacked sessions from access SSL pages. Then again, the Auth SSL Redirect module can be used to redirect authenticated users to SSL and it will work together with the Secure Pages. In case you are using Ubercart and want to either secure the whole site or just the Ubercart pages, then the other option is Ubercart SSL which can also be extended to secure additional pages. As a whole these modules can really help to handle transitions between secure and insecure pages.
This should give you a basic idea about SSL and whether or not you should be using it on your Drupal site. Do let us know whether you chose to have it or not!