brianr

It's an issue for a number of reasons... First, yes, it is hard(er) to find, and not obvious any more (it's a tiny-font sub-forum off the main list and easily overlooked). Second, if you did find it, your first impression would be that the reports there rarely get any feedback. (Of the 20 threads in my view, 2 are stickys, and only 6 of the 18 left, mostly at the bottom, have any sort of [sTATUS] tag associated with it.) Lastly, it's also a moderation issue... If this thread was a bug report, why wasn't it moved? Bug reporting has been a mess, IMHO, for a long time. There is no tracking of the reports, and all too often they are marked [FIXED] or [RESOLVED] with no resolution posted.

WRT my "information given is not FUD" comment: I was making a generalization regarding the general purview that SNI is not a viable option, and was not commenting specifically on any security implications to SNI. To that point, I stand behind my assertion that the general distaste for SNI is not FUD in and of itself. As far as security goes, as I have no intention to use SNI (for the reasons stated above -- my servers have too high a percentage of commerce sites to justify the few IPs that might be saved vs. the WinXP headaches), I'm not verse on any security implications it may have.

WRT to attitude.. again, not needed, and certainly the information given is not FUD, and still represents current best practice. And the reason for that... SNI is not universally supported on all platforms/browser combinations, most notably WinXP/IE (and some other browsers IIRC). Compounding the problem, WinXP still has >20% of the desktop browser market (http://gs.statcounter.com/#os-ww-monthly-201204-201304) leaving a potentially large pool of people that won't be able to use a SNI-enabled site. Thus, for many sites that must use SSL (eg eCommerce) SNI is still not (and may not be for a long time) a viable option.

The biggest failure of WHMCS support, and has been for a long time, is the queueing of the tickets. If I open a ticket for a problem, and some number of hours later figure out some/part of that problem, or have some new information that would help identify/fix that problem, it's actually in my best interest to *not* add that to the ticket because it will drop to the bottom of the queue, delaying the response. Never gotten a fact-based answer to why this is a good thing.

Don't know if I'd call it a miracle... too many Win XP machines w/ very little options that support SNI in the wild.... Before you deploy SNI, I strongly suggest looking at the compatibility issues you may face for some of your users. ... remember how long it took to get rid of IE6? (And it's not completely dead yet either....)

There are two different upgrade types we're talking about here. First, the "security patch", and the 2nd is a version upgrade. The reason I separate them into two categories is simple. Failing to apply a security patch in a timely manner may (and I'll get back to "may" later) open up your easily-googleable WHMCS installation to attack, or worse, data compromise. The "may" part of this is while I think I can safely say "will" here, often there is little information published as to what kind or type of security issue the patch is meant to address, so determining the severity in a real-installation is difficult. (Eg. if it's a SQL injection vulnerability, but you have good mod_sec rules, the severity isn't really as high.) On the other hand a version upgrade is, by nature, more optional and one can take more time to determine if/when to deploy it, in most cases. (Unfortunately WHMCS doesn't tend to back-port any bug fixes, so the level of urgency is variable.) Either way, if we follow the instructions from WHMCS here (http://docs.whmcs.com/Upgrading), there's a fundamental difference between those instructions and your "advice" that I think Matt and crew should correct ASAP. For snapshot purposes, the current top steps of the upgrade procedure are below: The critical step missing from the procedure is the following (insert this as step 1): Seriously!? Maybe this might fly for a major major upgrade, but who in their right mind would go through all that to test a 1 file security patch. The answer: anyone who tried to apply the last patch. And THAT is a very sorry state of affairs. On a more serious note -- if I pay WHMCS for the upgrade service, are they going to test it on a Dev instance for me first? Or if they put it right into production, are they going to test to make sure everything is working? Or will they do what most of the users here will, install and expect it to work right?

Because keeping track of changes made by WHMCS would be a basic part of a changelog. If they were doing it correctly, the changes would be listed and we wouldn't have any surprises, yet, this keeps coming up. "Template XXX was changed, but not listed in the release notes".... Nevermind with all the patches seemingly released with each version (or handed out piecemeal via tickets) knowing what version and patch level any given installation is at would greatly simplify troubleshooting. If you have a 5.2.2 install, you likely applied a few patches. Was there any indication in the admin panel what patches were applied? No. If you had more problems and opened a ticket you had to keep a log of what patches you applied and track them manually. One would think, with all this work being done (ideally) by every WHMCS admin, Matt and crew would come up with a way to version and track the various files, modules, and templates, not only for "current version" status, but for upgrades, and troubleshooting as well. Hence... Why do *we* have to do it?

I'm thinking this might be just as likely: http://web.archive.org/web/20060118110214/http://www.whmcs.com/

<sarcasm> Because no one is sure which is the better version to be running at the moment?

I think after the number of times I've seen that suggestion (and made it myself) I have to ask -- why is that something *we* have to do?

One login... lol. So I do that and get this in my email box several seconds later: So... yeah... It's another account.

I would but I'm getting tired of having yet another login to keep track of at WHMCS. If WHMCS can't realize that customers are talking about and asking for it in their forums, they're just being lazy and making us do more work for them.

6 weeks? Sure... it could have been 3 mos, but I don't think I'd call it "short".

LOL. Which begs the question, why was there work done to change it in the first place.

Let me try to simplify.... WHMCS has applied a cost ($$$) to an open and fee standard (Google Authenticator free app and it's related IETF standards). This directly goes against Matt's prior posts in this forum on the subject. Second, trying to get users to use 2 factor auth, specifically Google Authenticator is, simply, a royal pain in the ass. If you have non-technical users (and if you don't you're very lucky), many simply have a hard time "getting" it, and often require hand-holding through the setup process. This is complexity and it drives up the support costs for you and I to implement it for the end user.

/agreed However there is a point of diminishing return.... At what point does a) the cost involved, or b) the end-user complexity / support "cost" outweigh the benefit? Given that Google Auth is an open protocol, and open app, and have an open source implementation, the "cost" involved should be zero. Now teach end users how to use it... That hurts.

Holy thread necromancy Batman! Quick someone call in a mod lock squad!

Just keep in mind, with everyone running around screaming for 2FA, it's only one piece in the puzzle. If I can exploit another vulnerability and download your entire WHMCS DB (this is a hypothetical, BTW) the fact you had 2FA in place becomes security theater. 2FA protects against bad guys using good credentials and, really, nothing more. On the client-side, limiting what occurs w/o administrator intervention (eg auto-order setup, or cancellation), and strong process review policies in place ("gee, this guy from California, US, logged in from China..."), will mitigate a great deal. On the admin side, obviously, it's harder to mitigate and 2FA, coupled with strong perimeter and application security, would likely provide a good benefit. That said, I would like to see WHMCS start to provide better permitter security advice -- perhaps, for example, a tight set of mod_sec rules that could govern the members and admin areas. That sort of thing could help stop/prevent attacks that could otherwise be successful.

Given that Matt had previously stated it would be free.... I must respectfully disagree. http://forum.whmcs.com/showthread.php?48074-DuoSecurity-coming-to-WHMCS-soon!/page2&p=226272#post226272

(Emphasis Added) No comment needed, quote stands on its own.

I agree in principal with most of what you said, but.... This isn't the first cluster@#$ release. When 5.1 rolled out it was just as bad, and 5.0 wasn't that much better IIRC. (Part of why I'm still on 4.5) As far as other systems being antiquated, you could say the same about 4.5, but it works. My simple point is this: Customers will stick around and tolerate "upgrades" that break their systems only so many times before a) they stop upgrading, or b) switch to a competitor. And for a second imagine if the WHMCS install base becomes fractured because people stop updating, or even worse, stop applying security patches because they break more than they fix.... Imagine the sea of bad PR a trove of hacked WHMCS installs would bring. Personally, I think most (of not all) could have been prevented by 1) closing/fixing the bugs reported in 5.2.0 beta, and 2) having the only change between 5.2.0 beta and 5.2.1 release be this: s/5.2.0/5.2.1/g And that, is a @#$-damn Greek tragedy.

I started MD5ing every download for WHMCS a long time ago and versioning internally... Made it a lot easier when there were multiple patches. Sadly, and I agree with you, we shouldn't have to go to this end just to see if we're running the latest patch(es).

John, Quick question for the rest of us.... As we start moving more and more to dual-stack IPv4/v6 implementations (mine is ready as soon as cPanel is), will this be biting more of us, or is this a one-off to his config?

/concur (at least on 4.5) - except I didn't bother to open tickets. The forums are filled with people and problems and don't want to add to the noise. Sorry Matt, but this release and security patches have been nothing short of a #$%-show, and after coming on the heels of the nightmare for many that 5.1 was.... It's not good... I was, honestly, looking forward to the 5.2 upgrade, finally, hoping the lessons from 5.1 were learned and processes corrected, but with all these problems, and people saying reported bugs in beta are still in release.... I'm giving it a week and shopping around for alternatives at this point. I think I can safely say -- we just want something that works.

Yep... didn't move to 5.0, or 5.1, and not moving to 5.2 yet either... 'Ol trusty 4.5 still hummin' along nicely.