In Portland last week, I discovered that Portland Community Media was using Hypertext Transfer Protocol Secure (HTTPS) instead of plain HTTP on the web server to protect data in CiviCRM. That makes sense. In Austin, our installation of CiviCRM is on the web server, but we haven't imported data from Facil yet. This past week, among other things, we're setting up a "data import environment", i.e. another Ubuntu instance on a PC, with Drupal and CiviCRM loaded. We plan to copy the CiviCRM database from the development server to that PC and use it to attempt to use the scripts that raSANTIAGO developed to import data from Facil into it. So, in the process of doing this, and reflecting back on what was in Portland, started thinking that we also may need to change from HTTP to HTTPS on our web server here. No one on staff here has dealt with establishing HTTPS, but instructions found Googling don't seem too daunting. I suppose the question is: is it really necessary? If our server is locked down as much as it can be, what risk is there that someone could access the data in the CiviCRM database?
Comments
It depends. Use HTTP for anything you don't mind becoming public
It depends.
Any system on the same LAN segment the data travels on can read all of the HTTP activity.
If your host is at a third-party data center, are any systems on the same LAN segment untrustworthy or at risk of being hacked at the root level? Probably so. In that case, all personal member data is effectively public -- well, not really to everyone, only to people willing to break the law.
On the client side, generally only the same household is on the same LAN segment, so it's not as risky. But clients on unsecured WiFi networks have no protection, again allowing the data to be seen only by people willing to hack into the network. For clients accessing the system from work, their employer can easily (and usually legally follow all HTTP traffic. Other unscrupulous employees on the same LAN segment could also monitor the HTTP traffic.
There is also a risk that someone at an ISP or backbone provider might read your data (illegally), but that risk seems minimal to me.
HTTPS provides end-to-end security. Provided your server is secure, you've done all you can. If the client's system isn't secure, only that client's data is at risk of being compromised.
Knowing and considering the above risks, I recommended to a local NPO that they purchase a certificate and strictly stick to HTTPS for all Drupal traffic unless they didn't think their members would mind third parties seeing the information. Installation is relatively easy, although it's important that there be no weaker links (such as using the same session cookies between HTTP and HTTPS) that would defeat the purpose.
Bottom line: don't use HTTP (or SMTP, for that matter) for anything that you wouldn't want seen on a public blog (or in a courtroom).
--
Daniel
At Portland Community Media
At Portland Community Media we had several key factors that lead to our decision to secure the entire site. Firstly, because of the Personal Identifiable Information (PII) that could be exposed if users were accessing the data across the Internet. Secondly, as a means to provide a bit of easement for our producers and volunteers sending their credit card information to our servers as a means to pay for services and products. Lastly, and most importantly, the boss wanted it. -dsasser
HTTPS mandatory for credit cards
Any transfer of credit card information must satisfy PCI DSS requirements, among which is the requirement to encrypt credit card numbers. For this, HTTPS must be used instead of HTTP, but HTTPS alone isn't enough: certain minimum encryption schemes are also required. This is generally detailed in the documentation for credit card processing software and the merchant service agreement.