Seriously, not in the 4.3 release for October? C'mon guys... get serious about your security. It's pretty absurd in this day & age that you don't support SSL. 

 

We are just starting out our security group on WA, and though we only have about 35 members most of them have asked/commented/laughed about there being no SSL. If this isn't fixed (and it is a fix, not an enhancement) I'm going to have to start looking at alternatives, despite the fact that I think you guys have a good thing going here. 

 

Thanks 

I understand your frustration but we cannot do it any quicker now anyway. 

---

Evgeny
Product Design Team

I'm using the free trial to evaluate WA for our organization.  Like the others, SSL support for any screens that require the member to login or an applicant to enter personal information is a requirement.  I just mentioned to the other board members that I was starting this trial and the first question wasn't how much does it cost, or does it accept online payments-- it was does is support SSL for screens where personal information is entered/displayed.

A previous post in July 2011 mentioned SSL support was a "candidate for the next release - 5.0 (~Jan-Feb 2012), though it is not yet clear if it will go there in full, partially (for free wa domains only) - or will be pushed to a later release",  Since we're now starting that time period, can you provide an update on SSL support?  Thanks!

 

Regards, Fred

We rejigged our releases, release 5.0 will be coming out in late summer 2008 - but we have added release 4.4, planned for May 2012 and SSL is scheduled for that release. 

---

Dmitry Buterin, Chief Apricot

Good news! This feature is now in development and we would like to give you a preview of this new feature - Secure Site Access (HTTPS) for members and administrators.

This post is a part of our efforts to increase transparency of our design and development work. We are trying to share our ideas and designs earlier so that you can help us catch any gaps/mistakes/inconsistencies - while still have time before releasing the new version.

Key need we are trying to address is to protect secure and private data (like login and password, membership application form data, profile, etc.) from passing unencrypted over Internet channels by using Https (SSL/TLS) encryption. For example, if you are accessing Internet over WiFi from a cafe, it is possible that your traffic can be ‘sniffed' by mischievous or even malicious neighbors.

The biggest challenge was to figure out how to deal with custom domains - since each unique domain requires its own encryption certificate to be purchased and then installed on our web servers. For now we decided not to pursue this but provide other options for secure access in case custom domain is used. All custom domains will be provided with special secure URLs as a subdomain of wildapricot.org (secure certificate issued for Wild Apricot company). For example, http://www.abc.org would use httpS://abc.wildapricot.org for secure access. This means that if full or selective enforcement option is enabled for custom domain, your users will be redirected to pages via secure subdomain of wildapricot.org.

For all examples below, let's assume that your free URL for your Wild Apricot site is abc.wildapricot.org and your custom domain is www.abc.org

User interface of the solution we designed is pretty simple:

Gallery (3)

There are three options you can select for secure (HTTPS) access to your site:

Full https enforcement

• most secure setup, all requests are redirected to special HTTPS URL even if user enters non-secure URL or uses old bookmark. (We recommend that you do not use any third party non-secure resources like JS libraries or CSS files, otherwise end users will see security warning messages from their browser that page contains non-secure elements).
• Example: Requests to http://abc.wildapricot.org/about or http://www.abc.org/about will be redirected to secure URL httpS://abc.wildapricot.org/about

Selective enforcement of https

• for public visitors (not logged in), most web pages are served as usual except for pages with built-in interactive forms (i.e. membership application, event registrations), which are redirected via secure URLs
• login details are always sent to secure post page and after logging in, all site pages are served via HTTPS URLs
• Example: Requests to a content page via http://abc.wildapricot.org/about or http://www.abc.org/about will be served unchanged but requests to the membership application page http://abc.wildapricot.org/join or http://www.abc.org/join will be redirected to secure URL httpS://abc.wildapricot.org/join

Optional https

• secure access will available only if site is accessed via special URL, i.e. when requested explicitly. These special secure URLs will be available for all sites so administrators can use them to test that everything works smoothly before using stricter security options above
• Example: Requests to a content page via http://abc.wildapricot.org/about or http://www.abc.org/about will be served unchanged. Requests to the membership application page http://abc.wildapricot.org/join or http://www.abc.org/join will also be left unchanged. To access the pages securely, users would have to explicitly type the secure URLs (or follow a link): httpS://abc.wildapricot.org/join and httpS://abc.wildapricot.org/about

Note: if your site uses some other free domain provided by Wild Apricot (e.g. memberlodge.org, camp7.org), you will be provided with a second free domain based on wildapricot.org. For example, if your site is abcd.camp7.org, you will be provided with a second free domain like abcd.wildapricot.org for secure access. To avoid confusion with multiple domains, you might want to change your free domain to wildapricot.org via Settings/Domain management.

We actually started the development of this so would appreciate your comments as soon as possible. This is scheduled to be released end of May (which means that development would end at least 6 weeks before that)

---

Ekaterina Tyukina, Funny Apricot

I'm happy to see WA heading in the right direction, but I'm very disappointed that it won't work on custom domains. It's not that hard folks. Charge an implementation fee if you need to.

 

Also, special urls for "security conscious" administrators and users? No. You're doing it wrong. Sites are going to full-time SSL for a reason (see: twitter--just last week) for *all* traffic for *all* users. Dont make it sound like it's just the fringe paranoid users... How are login sessions secured *after* login to prevent hijacking or reuse by someone at the cafe?  

 

In another post you guys talked about how WA is 5 years old and, basically, a mature company that can handle releases in mid-December with confidence. Well, start acting like it. Hire a dedicated web security resource, or contract out to someone help design a secure and workable solution. 

 Seriously, it's just lame that for registration or login every one of my users is going to bounce to example.com.wildapricot.org ... we try to teach people about phishing and making sure domain names match, nothing looks weird, etc., and then go and do stuff like this--it's not helpful. 

It's important to walk before we run. Once we have the basic infrastructure in place for this, we will look at further steps, e.g. custom domains. I believe that for now, third party services like wwwizer might be used for custom domains - we plan to test that.

 

Not sure what is the problem you see with special URLs. You see, we can't enforce it on everyone right away for  many reasons. In this way people can use as much or as little of it as desired. Of course, login sessions will be protected if initial secure URL is used.

I have full confidence in our security expertise to design, implement and roll out the right solution, given all the complicating factors around this.

---

Dmitry Buterin, Chief Apricot

I fully agree - the sooner we can have SSL the better.  I would be happy to pay to have SSL on my custom domain if that's what it takes.  I'll set up a separate domain entirely if necessary, but it is really important, as sullo says, to have SSL on custom domains.

 

The webhost for our main site offers a general secure certificate for less $, and a personal certificate for more $$. I would like to see WA offer the same. I think that anyone who is concerned about this, and who wants to keep their own website instead of being abc.wildapricot.com would understand why you would want us to pay more for this service on a custom website. Would be a hassle initially to do everyone all at once, but once it's set up, becomes a matter of maintenance - a lot less time-consuming.

 

---

Nancy Scanlan, DVM, CVA, MSFP
Executive Director, AHVMA

I am just writing to express my disappointment over how this SSL Certificate roll out has been pushed back so many times, and the fact that other initiatives have been given priority over something that is so essential - information security - despite the number of identity theft cases in the US today.

Not knowing that this issue has been going on for some time now, I called Godaddy to purchase a certificate for my site. They told me to contact my site's host to request a CSR to set up an SSL, forward it to them (godaddy), and then they (godaddy) will provide something to give to the host to upload to the server.

When I hung up with Godaddy, I contacted Wild Apricots' host, who told me that this could be done, however, they would need permission from the Wild Apricot team, and they would email Wild Apricot for permission, and have them contact me. 

The next day, I received an email from Wild Apricot informing me that they will not allow this. It saddens me that the Wild Apricot Team would refuse to do something so simple as to allow their host to provide me with a CSR when it CAN be done. The Wild Apricot team didn't even have to do any work on their part, other than say, "Yes, provide her with the CSR."

Security is a critical issue for membership sites, and it's just a shame that although Wild Apricot is wonderful membership software, it's still pretty much useless and a waste of money without real security measures in place.

At this point, I will most likely cancel my service, as I see no point in paying for the service when members won't sign up since their information is not being transmitted securely. 

Furthermore, I have a friend in journalism, and I'm sure they would love this story - a membership software company that does not provide secure transmittal of information for its customers and members.

Disappointed Customer,

Gly

Let me comment on some important points:

1) As of now we are not able to set up custom SSL certificates. I wish it was that simple just to give you a CSR, have you buy a certificate and install it. This would work if you had a dedicated server. Wild Apricot is a very different thing - its a huge piece of software running many thousands of sites on a large server farm. Enabling SSL access to sites in our system requires lots of code development on our side, additional hardware, etc.

2) We always had the most important part of the system - ecommerce transactions - protected by SSL. We are now rolling out SSL support in our next version 4.4 in June. However we will not allow custom certificates since we are not able to support it yet - see above - so we will walk before we run. That release will solve the main task - enable encrypted traffic transfer if desired, using our own certificates.  

3) As concerns the identity theft, SSL is not a panacea and information security is much more than SSL. In fact, using SSL would not materially affect security of your site except for one particular scenario - where administrator logs in via unsecure network (WiFI) and admin password is intercepted. It does not make sense for hackers to try to try to listen to individual data traffic exchanges - they go instead for the pot of gold, for servers where it is all stored. We have spent a lot of efforts making sure our servers / client sites are well protected and I am confident this was the right decision of where to direct resources.

Feel free to contact support if you want any additional information. 

---

Dmitry Buterin, Chief Apricot

Update: We think we will manage to support custom domains too, though this will have to be done manually and will require one-time payment for the work on our end (not including the certificate itself). 

---

Dmitry Buterin, Chief Apricot

Great News, Dmitiri! REALLY looking forward to this next step.  It will open up a whole new world of capabilities we can offer our members.