I just migrated from Elastix to FreePBX distro and noticed that FreePBX does not support SSL encryption on the interface? Have I done something wrong, or is this just a glaring omission on the part of Schmooze, et. al.?
Tom
The FreePBX Distro supports SSL, however we currently do not set it up for you out of the box.
Is there a set of instructions available somewhere to enable this, or should I dust off my Apache Fu?
We don’t have a set of instructions available for this, but you should be able to find plenty of how-to guides for setting this up with Apache.
OK, will do. Is there any reason why this is not enabled out of the box? It sure seems like a glaring security oversight, considering the sensitivity of the data being transmitted. The potential cost in toll fraud alone that would result from the compromise of my FreePBX credentials would be staggering.
Tom
We don’t recommend exposing your system to the public internet making https typically a non issue.
That stance does, of course, presume that there are no threats on my local network. A scan of recent news about credit card breaches indicates that to be a dubious assumption.
If you have a threat on your LAN, you have bigger issues than https vs http. As we saw with the whole heartbleed thing your SSL potentially means nothing.
Remember security is only as strong as the weakest link. You should not pretend that the monsters are unable to get you because you have a blanket over your head. Any monster capable of harming you is also capable of pulling away your blanket.
1 Like
Without getting into the basics of security, (rule #1 have an effective firewall/iptables, not currently included 
) https is always more secure than http, that’s why it exists, It’s easy to add the http/https ReWrite rules in your apache/httpd configs but realistically you will need “acceptable” certificates deployed, self signed ones will just annoy your clients.
As to recommending that you don’t allow web access to your presumably well constructed and web based system that has always perplexed me, You would have no usable UCP/ARI no RestApps, no remote provisioning, how is that useful to any but the smallest deployments? suggesting everyone out there install a tunnel on their apple/android/M$/everything is just not realistic.
Again, that is what firewalls are designed for, if you have one deployed and properly configured then you are as exposed to exploitation no more nor less than other well known web sites, like for example this one here or even google.
Any server not behind a firewall makes as much sense to me as giving a fish a bicycle. . .
1 Like
All true, but irrelevant. Just because one improvement doesn’t remove all threats, that doesn’t mean that making that improvement is pointless. These two facts remain:
- Implementing SSL for the distribution is trivial.
- Implementing SSL improves security.
This leaves the question: what benefit is there to leaving things as they are?
1 Like
You (and others who are interested) may wish to click the “vote” on that ticket to show interest… It looks like from the comment after yours their may be some logistics worked out to make sure flipping the switch doesn’t adversely affect some other things. Keep in mind all features/bugs etc are handled in the big picture scope. You may follow the information there and online and find no ill effects in your environment, especially if you don’t use the components mentioned. If we push it the whole user base that may not be the case.
1 Like
Thanks, James. Of course, while the size and diversity of the installed base makes implementation more difficult, that same factor also means that it is that much more important, too.
I’m just wondering what is the point of making a HTTPS site with useless certificates? Do you feel more secure by seeing the UNTRUSTED CONNECTION? As pointed here you can do it yourself and you can buy a “good” certificate for each implementation do you want.
In my personal opinion(+7 years using asterisk) I saw many Elastix hacked than FreePBX/Plain Asterisk, maybe from there is the fear, i mean, maybe in the past you was hacked with your elastix installation, well, a good configured FreePBX/Asterisk is not hacked at all.
Navaisimo: No, I have not had security breaches in the past, over years of experience with FreePBX, Elastix, Trixbox, all the way back to Asterisk@Home. I am simply following simple logic, which states that sending sensitive information over the network unencrypted is asking for trouble.
Implementing basic security practices like this is very much like buying insurance for your house. You don’t buy insurance because you think it is LIKELY your home will burn down, you buy insurance because the price is reasonable and IF your home burned down, it would be a financial catastrophe. To continue the metaphor, you don’t encrypt your HTTP session because you think it is LIKELY that someone will intercept your FreePBX session on the wire and use that data to break in to your PBX, you encrypt your session because it is easy to encrypt your session, and IF someone were to break in to your PBX, it would be VERY EXPENSIVE in terms of dollars (toll fraud) and time.
From there, we can address the “useless” tag that you and others in this community constantly throw at self-signed certs. Do they have their shortcomings? Most certainly. Are they better than an unencrypted session? Undoubtedly! In order of preference from most secure to least secure, here is the way these things go:
1.) SSL with trusted certificates.
2.) SSL with self-signed certificates.
3.) Unencrypted connection.
So yes, using SSL will not eliminate all attack vectors or absolve me of my responsibility to ensure security on a system-wide basis. Yes, using self-signed certificates is inferior to using certificates from a trusted CA. However, neither of those two things changes the fact that using an unencrypted HTTP session is, quite frankly, reckless.
From all this, I draw the following conclusions:
- Implementing SSL should be a major priority for the FreePBX Distro team.
- There will be challenges, such as dealing with phones that are provisioned via http and do not support SSL, but those challenges can be overcome.
- The distribution will necessarily come with self-signed certificates, but a good interface and documentation/tutorials to help users obtain and install trusted certificates will help ensure that as many users as possible will implement the best possible level of security.
If the truth be told, the most troubling thing to me about this entire exchange has been the fact that everyone involved with the FreePBX project that has commented on this subject, from the CEO of Schmooze down, has made it abundantly clear that security concerns are not much of a priority. While a heavily fortified system that does nothing would be pointless, continuing with this attitude will eventually lead to a problem - the FreePBX installed base is just too big to avoid it.
From your last 3 points:
1.- I don’t think this will be a “major priority” since using useless certificates doesn’t solve the real issue. In fact this need to be adress by the manager not the vendor.
2.- You can contact first the vendors whom doesn’t not support ssl. And then you will be very helpful if you can make a patch or mod to the FreePBX engine and submit as request with all changes to implement.
3.- I think anyone can find that information usging google.
Schomoze has a priority in the security but not at that layer, you can see how many patches they did for the framework and to asterisk, i think any self-claimed IT-admin can make it work or more secure at the web layer.
My concerns about security are more in the voice side, did you know how easy is to catch all of your calls, all data in it, or if you pbx is compromised you lost everything, so I try to keep more attention at the TLS, SRTP part, the blockhost part rather than the web side.
1 Like
-
You have not explained how using self-signed certificates is less secure that an unencrypted session. Perhaps that’s why I cannot understand the opposition to what I consider an obvious requirement. Please enlighten me here.
-
There is, quite obviously, I might add, no need to contact the vendors. Modify the SSL implementation to provide access to the relevant portions of the web server without encryption. Similarly, there is no need for changes to FreePBX, as other distributions have been doing this for years now.
-
Yes, you are right: anyone can find out how to implement SSL security using Google. Anyone can find out how to install and configure Linux, Asterisk, and FreePBX using Google, too, so why are there multiple competing distributions that do just that? Similarly, anyone can find how to hand-code an asterisk dialplan using Google, too, so then why does FreePBX exist? My point was that a well-written interface and/or documentation may help drive a higher implementation rate for trusted certificates.
Schmooze/FreePBX most certainly DOES have a responsibility for security at this layer, but obviously only for the FreePBX Distro, not FreePBX itself. Of course I can make it work myself, but I could have installed Linux, Asterisk and FreePBX myself, too, couldn’t I?
Your concerns about security in the voice arena with regard to call interception and authentication are well-placed. However, the fact that other, potentially more serious, security concerns exist does not render this one meaningless.
We are very concerned about security. Look at the bash vulnerability. We released the patch in less than a day. We setup fail2ban by default in all of our distro releases.
We are already discussing this internally. So assumptions about what we are or are not doing aren’t really warranted, especially saying things like “[for schmooze] security concerns are not much of a priority”. One of our developers stated that you could set this up manually, he was trying to be helpful not dismissive.
Also our “CEO” never commented on this subject in this thread, simply more speculation. In fact, our CEO actually stated this “Lets add this to System Admin to enable or disable SSL and self generate a cert.” in [FREEPBX-5288] Please allow https access to web portal in FreePBX distro - Sangoma Issue Tracker which hardly seems like this is not much of a priority…
Andrew: You’re right. I have overreached in my comments, so my apologies on that front. I would suggest that it is because I have been truly shocked by the overall tone of dismissiveness I have received from the folks associated with FreePBX and Schmooze (I do realize that Navaismo is, like me, just a user).
In general, the impression I have been given is “There are bigger risks out there, and even though that solution would be an improvement, it’s imperfect, so why bother?” As an example, I would point to the quote from Tony I was referring to earlier (in the feature request you and I have both linked to):
[quote]Except self signed certs are useless and browser complain and would
cause lots of problems with phones using HTTP to provision and things
like the Rest API and XML apps.[/quote]
Perhaps what the FreePBX team is trying to say is something along the lines of:
“We previously felt that this feature was not needed for systems that are not exposed to the open internet, but recent user feedback and exploits like the one at Home Depot have led us to change our mind on this subject. We are working to implement encryption, but the installed base of FreePBX Distro users is broad and diverse, so please be patient as we take the time to ensure that the solution we develop is mature and doesn’t break core functionality.”
If so, please be aware that what is being received on this end is more along the lines of:
“We’re working on it, but we have no idea why you’d want to bother. It’s simultaneously really easy to set up on your own, while being really complicated for us to get right. Please keep in mind that development is handled in the big picture scope of what we feel is important, and since we have made it abundantly clear that we don’t think this is important, you should probably be prepared to wait.”
I know that is not precisely what has been stated, but if you take a look back, including your +1 of Navaismo’s comment, I think it’s not difficult to see how that conclusion could be reached. Maybe I am overreacting, or maybe I am just a blowhard, but I have been involved as a user and community member in many different projects and distributions over the years (including FreePBX since it was still AMP), and I really cannot sufficiently describe my level of shock at the tenor and tone of the responses I have received here. I am hopeful that this whole thing is a big misunderstanding, but only time will tell, I suppose.
1 Like