Anyone using XMPP and/or WebRTC apps?

[smn]

XMPP doesn't look too hard to install but WebRTC looks like a PiTA because of the TLS stuff. I am wondering if they work ok and are worth installing or are they kind of experimental? Doesn't seem to be much documentation or discussion which to me indicates there are not a lot of users/eyes on that software and therefore maybe buggy and not very polished.

Are they even that useful or is this more of a me-too thing where it's bolted on to show they can do the same thing as skype/messenger if they want to?

 

[Dan]

I haven't played around with WebRTC for FusionPBX, but if maintaining a valid TLS certificate is problematic for you, I would encourage you not to host your own web accessible PBX.

All internet accessible systems need regular maintenance and updates. If you don't want to maintain your server, don't set one up. Otherwise the server is apt to join a botnet and/or be hijacked and make calls to (expensive) places.

One workaround for the certificate requirement of WebRTC is to generate a self signed cert, or set up your own CA to sign your certificates (which can be more secure than trusting the 200+ certificate authorities when done properly), but with either of these options you will have to add them to your OS's trust store.

 

[smn]

I haven't played around with WebRTC for FusionPBX, but if maintaining a valid TLS certificate is problematic for you, I would encourage you not to host your own web accessible PBX.

All internet accessible systems need regular maintenance and updates. If you don't want to maintain your server, don't set one up. Otherwise the server is apt to join a botnet and/or be hijacked and make calls to (expensive) places.

One workaround for the certificate requirement of WebRTC is to generate a self signed cert, or set up your own CA to sign your certificates (which can be more secure than trusting the 200+ certificate authorities when done properly), but with either of these options you will have to add them to your OS's trust store.

As someone who has hosted of web-accessible PBX's for many years, your advice is duly noted and given the consideration it deserves.

My question is not about justifications for security or how to set up certificates. But since you brought it up I will give you some insights learned from may years of experience. Within the context of PBX servers, in all the years I have been doing this I have never seen a system compromised because it did not use SSL (No I am not saying don't use bother using SSL). Nor have I ever seen breaches due to brute force password guessing (no I am not saying don't use secure passwords).

Most if not all security breaches have been due to weaknesses in the files exposed to the internet allowing simple direct access through the files, usually the code itself in the case of PHP. See recent Fusion security problems for an example of that. The wider the attack surface (ie. the more files and related code exposed to the internet), the more likely that is to happen. It doesn't matter how good the people who wrote the code are. Sooner or later weaknesses are found.

The best security by far also tends to be the simplest. Anything that prevents anonymous internet access to the files. There are a few different ways to do that depending on your use case.

 

[Dan]

My question is not about justifications for security or how to set up certificates. But since you brought it up I will give you some insights learned from may years of experience. Within the context of PBX servers, in all the years I have been doing this I have never seen a system compromised because it did not use SSL (No I am not saying don't use bother using SSL). Nor have I ever seen breaches due to brute force password guessing (no I am not saying don't use secure passwords).

Not using TLS is barebacking the web. If you like hanging your users out to dry, go right ahead and schlep their data around with no encryption (or worse yet, broken crypto like SSL), your letting any bad actor between you and your client read & potentially alter said data.

Slinging unencrypted phone calls isn't HIPPA compliant or PCI-DSS compliant, the latter of which most businesses need to comply with to avoid fines and ensure their continued ability to accept credit & debit cards.

Most if not all security breaches have been due to weaknesses in the files exposed to the internet allowing simple direct access through the files, usually the code itself in the case of PHP.

FusionPBX vulns are always in PHP, it is the language FusionPBX is written in after all! Without TLS, there is nothing to stop an intermediary from swiping cookies off an authorized user and going hog wild with toll fraud.

 

[smn]

Not using TLS is barebacking the web. If you like hanging your users out to dry, go right ahead and schlep their data around with no encryption (or worse yet, broken crypto like SSL), your letting any bad actor between you and your client read & potentially alter said data.

Slinging unencrypted phone calls isn't HIPPA compliant or PCI-DSS compliant, the latter of which most businesses need to comply with to avoid fines and ensure their continued ability to accept credit & debit cards.


FusionPBX vulns are always in PHP, it is the language FusionPBX is written in after all! Without TLS, there is nothing to stop an intermediary from swiping cookies off an authorized user and going hog wild with toll fraud.

Walk me through how I can hack into fusionpbx because it is not HIPPA or PCI-DSS compliant. Step by step with command lines. Not theory. Show me how you can hack into an actual server. Because if you truly understand what you are talking about you have done that. Also, please provide a link to your step by step instruction on how to make it HIPPA and PCI-DSS compliant so that everyone can immediately fix their insecure systems.

And thanks for derailing my post into another religious argument about security.

 

[Dan]

Walk me through how I can hack into fusionpbx because it is not HIPPA or PCI-DSS compliant. Step by step with command lines. Not theory. Show me how you can hack into an actual server. Because if you truly understand what you are talking about you have done that.

The potential vulnerability I bring up is not a flaw in FusionPBX, but rather setting FusionPBX up in an insecure manner (which violates PCI-DSS). Mozilla started warning end users about this a few years ago.

Example attack: Connect to the local WiFi network, ARP spoof to hijack traffic headed to the router, snatch the cookie for FusionPBX when the user pokes around the FusionPBX interface (without using TLS).

BGP hijacking will also work to this end (rather than ARP spoofing), or there are a variety of provider specific ways to eavesdrop on a connection if your internet is via a shared medium (cable, BPON/GPON, WISPs, etc). An infected device on the LAN or your ISP's network could also perform this attack.

If the connection had been using TLS, an attacker would not have been able to get the cookie or any form data and compromise the server. This vulnerability affects unencrypted websites that has a user login or stores a cookie.

And thanks for drailing my post into yet another religious argument about security. Something that my original post has nothing to do with.

This ain't religious, just encouraging you to avoid known pitfalls. I already suggested workarounds, take a peek at the last paragraph of my first comment.

 

[smn]

So I guess I should disable anonymous WiFi access to my LAN. Thanks for the advice.

 

[Dan]

Insecure connections for logins are a threat that Chrome warns about, Safari shows scary red text over, and Mozilla shows a dialog to inform users about the vulnerability.

If you don't believe any of the browser vendors warnings, nothing I can say will sway you.

 

[smn]

Insecure connections for logins are a threat that Chrome warns about, Safari shows scary red text over, and Mozilla shows a dialog to inform users about the vulnerability.

If you don't believe any of the browser vendors warnings, nothing I can say will sway you.

What does that have to do with WebRTC since you don't have a choice about using certificates anyways.

 

[Dan]

What does that have to do with WebRTC since you don't have a choice about using certificates anyways.

We were on a tangent about how vulnerable web based systems without TLS are, but you seem to have edited your posts to adjust/redact your comments. You can still issue a self-signed certificate to use WebRTC (like I suggested before), its a very minimal barrier.

 

[JamesBorne]

The Freeswitch documentation for SIPS/SRTP has a good writeup on creating self signed certs for voice comms with TLS.

 

[noci]

Why not use letsencrypt certificates?