Reset the Net, CiviCRM

Gepubliceerd
2014-05-06 10:50
Written by
JoeMurray - member of the CiviCRM community - view blog guidelines

Don't ask for your privacy. Take it back.

Reset the Net is a campaign to improve individual and organizational privacy against mass government surveillance. I think we as CiviCRM community members should step up and act. In particular, hosting providers, implementors, and organizations using CiviCRM should up their game to implement SSL, HSTS, and PFS.

As users, administrators, and developers of software used by non-profits and advocacy groups around the world, we should all be concerned about the security of information in CiviCRM databases.

Many administrators and consultants went into overdrive to respond promptly to the recent http://heartbleed.com/ security vulnerability. But we also need to be aware of threats from mass government surveillance. 

Whether it is America's NSA, the Communications Security Establishment Canada, Britain's GCHQ, China's military, or other government's spies, as individuals and organizations we need to protect our privacy.

As a software project primarily focussed on personal information in the form of contact info and transactions, CiviCRM has long aimed to implement security best practices. Reset the Net suggests some reasonable improvements for most CiviCRM sites:

JMA started some of its clients on using https for all traffic a few years ago to overcome the vulnerability associated with redirects from http to https. HSTS helps protect against security vulnerabilities when sites are available over both http and https, and even when just served over https. PFS helps protect against problems from encryption methods being compromised.

Besides each CiviCRM organization upping their privacy protection, is there anything else we as a community should be doing? 

Filed under

Comments

Absolutely, totaly agree. As CiviCRM service providers, our customers do entrust us with their most precious data - donors, members, volunteers, event attendeees, etc. This data is the lifeblood of their nonprofit organization. We should all be very aware of potential threats and pitfalls related to the availability and pricacy of this data, and take measures to adequately protect it.

Cividesk has long ago taken the "All HTTPS, all the time" pledge, and only serves CiviCRM pages over HTTPS. All CiviCRM pages, all the time, for all our customers, whether in the Standalone mode or integrated in Drupal, WordPress or Joomla!.

Contrary to popular beliefs, this has not had any significant impact on performance on our servers, nor caused irremediable issues with older browsers not supporting SNI for example. However, although we do favor PFS-compatible algorythms in our SSL negotiation, we have not been able to mandate it yet due to these compatibility issues. We are however continuing to monitor progress made in these areas and improving our security configuration whenever possible.

I would specifically recommend the following resource to any implementer looking to deploy SSL and PFS on their servers, and will also gladly help anyone in need with advise, return on experience and additional resources.

is there anything else we as a community should be doing.... An easy thing to do is switch your search engine. If you have not heard of duckduckgo, you will. It's the search engine that doesn't track you ever.The results are less targeted, but you if you don't want the other search engines tracking you and serving up ads based on your searching, its worth it.

However the use of cryptographic software, including SSL, is actually illegal in some parts of the world. I'm not defending this but in cases when we want to engage with constituents in those countries we can't always offer an SSL solution.

Thanks for the info JKingsnorth. I was aware of export control on some cryptography by US, but didn't realize that import and domestic restrictions were so prevalent - see http://www.cryptolaw.org/cls-sum.htm.

Cheers,

I'm not certain what's meant by "component data" here - but in all likelihood the easiest approach is to restore a copy of the civicrm.mysql and civicrm_generated.mysql files in the "sql" directory. Don't forget to drop your database first, restoring a SQL file won't drop existing tables created, e.g. by generating custom fields. Thanks in advance.