SSIP & SRTP

Status
Not open for further replies.

TheBellSystem

Gold Partner
Advanced Certified
Joined
Aug 27, 2019
Messages
26
Reaction score
3
Hey Folks,

So I have the PBX configured appropriately for both Secure SIP and Secure RTP, and I can see the TLS and SRTP traffic in the captures, so I know it's at least functional. The issue I am having is I am not able to get the phones to use TLS for transport. I have tried every combination of settings I can think of. Is there a guide somewhere or has someone configured Fanvil X3S, X6, etc to work with these protocols? I must be missing something dumb.

Thank you!
 
We have been trying for 1 year and gave up.
We asked Gold and Titanium partners, both do not use it in the internal networks at their clients....

https://www.3cx.com/community/threa...-sip-in-15-5-linux-version.50770/#post-305691

On trunks: We tried 3CX supported Providers easybell and dus.net, sometimes works sometimes no audio. (On Asteriks these providers worked without issues.)

You may try "PBX delivers Audio" on all extensions.

Hope you have better luck......
 
  • Like
Reactions: Evolute IT
We always use PBX delivers audio.

Our instance is in AWS. We setup two instances and called between them. The PBX to PBX is not doing either from what I can see. The phones will not register when forcing TLS.
 
We always use PBX delivers audio.

Our instance is in AWS. We setup two instances and called between them. The PBX to PBX is not doing either from what I can see. The phones will not register when forcing TLS.

You would need to clarify what you mean by this. Calling between two instances using a bridge should be encrypted or at least obfuscated (I don't know for sure if they use the same encryption as they do on SBC tunnels although it would make sense to). Calling via a SIP provider should honor the trunk settings if regular calls on the trunk use TLS.

The fact of the matter is that VoIP encryption is not mainstream, and while 3CX has the basic framework in place, they aren't losing any business over not having it fully supported as there are no requirements/regulations that I'm aware of that require the traffic to be encrypted that can't instead be met by network segmentation, VPN, etc. Once it becomes more mainstream or something like PCI says it has to be I'm sure 3CX will support it. The hard part is that unlike manufactures that make the PBX and the end points 3CX has to depend on Yealink/Fanvil/Grandstream, etc to do their job right. Encryption is even more particular than T.38 which doesn't work all that well, even when all the pieces are T.38 compliant.
 
I am calling between two instances that are not related or intended to be bridged to see if the traffic is actually encrypting, which it is not.

3CX is offering a product that states it supports encryption. It clearly does not work as advertised. Just because encryption is not "mainstream" is not a reason to not implement it or take it seriously. If we are not securing everything we can, we are not protecting our interests or our customers interests. It's just a matter of time until something big happens and everyone is scrambling at the last minute to roll this out.
 
  • Sad
Reactions: Anaphylaxis
+1 for SSIP and SRTP.
 
Put in many hours too. TLS is not working for me.
You have to use the tunnel or VPN for encryption.
 
  • Sad
Reactions: Anaphylaxis
VOIP without SRTP/TLS is like online shopping with http:// instead of https://
Or E-Mail-Servers still communicating without TLS (look at your mail server logs, you still may find some).

As far as I know, 3CX uses encrypted tunnel when using the mobile App, Windows- or Webclient, but not on normal phones or DECT/Fax GW's.

Some sort of "Workaround" for normal phones, DECT or Fax-Adapters: Use a VPN / SBC or vlan at internal networks.
 
I am calling between two instances that are not related or intended to be bridged to see if the traffic is actually encrypting, which it is not.

I still don't see the how. You have a working SIP trunk with a supported provider configured with TLS that works for regular calls and then when you call a number on the other PBX which is also using a supported provider configured with TLS that works for regular calls it's not encrypted? That sounds like an issue with the provider, not 3CX

3CX is offering a product that states it supports encryption. It clearly does not work as advertised.
How so? You already stated the pieces that 3CX does control (softphone apps, webclient) do support encryption. The SBC also supports encryption. There's check marks to enable encryption for endpoints and trunks but that requires the endpoints and trunks to support it as well. I don't see 3CX guaranteeing end-to-end encryption anywhere or that it works automagically. It definitely does work if you put the time in and have the know-how, but it is far from easy and adds complexity. Again, because it's not mainstream or a regulatory requirement everyone is just giving it the good ol' college try. Once it picks up steam you'll see better out of the box support. In another post 3CX mentioned because their revamped TLS support wasn't added until v16 Update 3 they haven't had a chance to interop test with the supported trunking providers. That is in progress and they will update the provider listings when done and we'll be one step closer.

VoIP is inherently more than the PSTN technology it's replacing. A 5 year old could clip an a butt set on analog lines to listen to a call. It's a lot harder to do the same with VoIP. Please do explain the attack vector you are you are concerned about and I would bet your security already failed by the time that comes into play. If you are the tinfoil hat type with the 'trust no-one' attitude you shouldn't be using VoIP.

There's a number of threads on this and my response is the same. Encryption of VoIP is not mainstream because no one is requiring if. It's an internal requirement, you are better of with VPN and private circuits to your dial tone provider which is a tried and true method. And even then, once the call leaves your provider you can pretty much guarantee it's not being encrypted at that point. Once encryption starts becoming a requirement or vendors lose business because they don't support it then we'll start seeing better interoperability. 3CX has the pieces now (for the most part) to support it, and now it's about about economics driving it the rest of the way home.
 
I am really shocked !

I comment, just in case someone at 3CX thinks, that Cobaltit's opinion is the only one:

.... I don't see 3CX guaranteeing end-to-end encryption anywhere or that it works automagically. It definitely does work if you put the time in and have the know-how, but it is far from easy and adds complexity.
And that's why people buy products like 3CX:
They expect to get good software side support for "special things like SRTP/TLS provisioning".
Otherwise they can use Open Souce Asterisk solutions which perform well....

Again, because it's not mainstream or a regulatory requirement everyone is just giving it the good ol'
So, You want to say:
"https: is not a "regulatory requirement" or mainstream: So why should people ask for it?"
Are you serious?

VoIP is inherently more than the PSTN technology it's replacing. A 5 year old could clip an a butt set on analog lines to listen to a call. It's a lot harder to do the same with VoIP.
You may talk about phone systems good enough for the USA......:rolleyes:
Have you ever managed to spy 25 year old European E1 lines or Alcatel 4x64KBit ISDN on 2-wires!!! proprietary lines?
I haven't managed because you need real expensive equipment.
But I managed easily to spy on SIP calls.....

Please do explain the attack vector you are you are concerned about and I would bet your security already failed by the time that comes into play. If you are the tinfoil hat type with the 'trust no-one' attitude you shouldn't be using VoIP.
Again: Do you do your online-shopping with HTTP ?
If not, please explain what tinfoil 'trust-no-one' you are.

There's a number of threads on this and my response is the same. Encryption of VoIP is not mainstream because no one is requiring if.
You may speak for your 'unknowing cients'....
If I would ask some of your clients / some top 500 CIO/CEO, whether he thinks, his phone conversations within the company should be protected at least as well as his online shopping, I might get other answers / requirements from him.....

It's an internal requirement, you are better of with VPN and private circuits to your dial tone provider which is a tried and true method.
Oh.... so all your clients have each of their internal phones connected with a VPN tunnel?

And even then, once the call leaves your provider you can pretty much guarantee it's not being encrypted at that point.
That's unfortunately true and this will never change, as long as people like you - who have some knowledge and influence - continue to flame "tinfoil" on people like us.

Once encryption starts becoming a requirement or vendors lose business because they don't support it then we'll start seeing better interoperability. 3CX has the pieces now (for the most part) to support it, and now it's about about economics driving it the rest of the way home.
We were waiting for 1 year, paying a 128 concurrent call license without using it, always waiting for 3CX to get their SRTP/TLS working !!

After 1 year, we gave up but keep on dreaming that 3CX will finally make it!

Of course we expected from 3CX, as a premier VOIP company, to FULLY support SRTP/TLS at all possible communication levels.

And I know the people at 3CX are great !
And they will make it work in the future !

So please:
  • Stop de-motivating 3CX staff and
  • Accept, that people like us, asking for SRTP/TLS, are not stupid !

Best Regards from
Tinfoil George


My Footer:
No need for "Earn Crypto in your Sleep" Advertisement in my footer,
no certified, no nothing.


.
 
  • Like
Reactions: Alex_N
As am also shocked. You seem to prefer to argue instead of understanding the reasoning presented. Let's break it down.
I am really shocked !

I comment, just in case someone at 3CX thinks, that Cobaltit's opinion is the only one:
Your original post said you asked gold and titanium partners and they don't use it on their internal networks at the clients. So thus I'm clearly not the only one. I'm just one of the more vocal ones because I'm tired of people complaining that 3CX doesn't do something that it does in fact do.

And that's why people buy products like 3CX:
They expect to get good software side support for "special things like SRTP/TLS provisioning".
Otherwise they can use Open Souce Asterisk solutions which perform well....

As far as I know, 3CX uses encrypted tunnel when using the mobile App, Windows- or Webclient, but not on normal phones or DECT/Fax GW's.

You and I have both stated that the software components that 3CX has direct control of fully support encryption. And 3CX does support encryption between itself and trunking providers as well as endpoints but that is dependent on 3rd parties and the installer's level of knowledge which 3CX can't control.

So, You want to say:
"https: is not a "regulatory requirement" or mainstream: So why should people ask for it?"
Are you serious?

Now you are just putting words in my mouth or perhaps it's just something lost in translation. I never said people shouldn't ask for it. My statement that it is not mainstream or a regulatory requirement has to do with economics which is the primary motivator for parties to come together to make something work. You keep mentioning HTTPS so let me give you an example. HTTPS has been around for ever but it wasn't until LE came out and gave away free certificates that there was a tremendous growth in adoption over the last few years because the economics (free) and the technical requirement was lowered.

You may talk about phone systems good enough for the USA......:rolleyes:
Have you ever managed to spy 25 year old European E1 lines or Alcatel 4x64KBit ISDN on 2-wires!!! proprietary lines?
I haven't managed because you need real expensive equipment.
But I managed easily to spy on SIP calls.....

Equipment expense is not a limiting factor. A motivated person could just as easily steal the equipment. And exactly the same way as unencrypted SIP, your examples are relying on access, not encryption, as the limiting factor. For your example, where you spied on SIP calls, were you inside the network you are trying the secure or were you sitting outside on a pole 6 blocks away?

Again: Do you do your online-shopping with HTTP ?
If not, please explain what tinfoil 'trust-no-one' you are.
I ask you for the attack vector you are trying to protect against and this is your response? Well I want to thank you for proving my point. HTTPS is there, particularly in your online shopping scenario, for a couple reasons:
- It's mainstream.
- It's a regulatory requirement (PCI)
- Economics because the penalties for not adhering to PCI compliance outweigh the costs for complying.

You may speak for your 'unknowing cients'....
If I would ask some of your clients / some top 500 CIO/CEO, whether he thinks, his phone conversations within the company should be protected at least as well as his online shopping, I might get other answers / requirements from him.....

Where to start on this..... So first off, CEO/CIO's say many things, like "I had no knowledge of this illegal thing or that inappropriate thing", etc so what they say, and what they act upon is two entirely different things. Heck how many CEOs/CIOs got sacked/resigned after major breaches in their credit card systems which they were (supposedly) much more concerned about securing. And like your HTTPS to SIPS/SRTP comparison your example here is apples to oranges. You are comparing internal traffic (topology not withstanding) to external traffic (online shopping). And then there's the fact that the CEO doesn't care about the HOW. Protecting via VPN, and other readily available and known reliable methods achieve the goal. But since you have the ears of CIO/CEOs, please let me know how the conversation goes when you tell said CIO/CEOs the reason they keep having audio issues (as you confirmed in another post) is because you decided to configure TLS/SRTP vs using one of the other tried and true methods.

Oh.... so all your clients have each of their internal phones connected with a VPN tunnel?
So I think you misunderstood what I meant by internal requirement. Internal requirement as far as what company policy dictates as to how your voice traffic should be handled as opposed to an external requirement (PCI, HIPPA, etc) not specifically internal traffic. But yes we do have scenarios where we are using VPN on the phones themselves (many of the supported phones support this) for 'internal' phones but this from back in the SIP Proxy days when it was garbage and was mainly for ease of provisioning/accessing remote phones. For for true internal phones, it's separate network/VLAN with ACLs typically but for more secure environments full on firewall/traffic inspection since that's a requirement now for PCI and other standards so we often already have the pieces in place.



That's unfortunately true and this will never change, as long as people like you - who have some knowledge and influence - continue to flame "tinfoil" on people like us.

Well thank you for believing I have the kind of influence to change the behaviours of LECs, transit providers and other entities but unfortunately I don't. If I did, I'd post on here even more because I could quit my day job! That scenario will change when the economics force it to, and not before.

We were waiting for 1 year, paying a 128 concurrent call license without using it, always waiting for 3CX to get their SRTP/TLS working !!

After 1 year, we gave up but keep on dreaming that 3CX will finally make it!

I see we get down to the root of the problem perhaps?. Were you the person who made the decision to purchase 3CX without doing proper testing/homework beforehand and this is where the angst/frustration is coming from? If you had come here on the forums or talked to partners prior to purchase we could have educated you and set appropriate expectations.

And I know the people at 3CX are great !
And they will make it work in the future !

This is something we agree on it seems.

So please:
  • Stop de-motivating 3CX staff and
  • Accept, that people like us, asking for SRTP/TLS, are not stupid !

Best Regards from
Tinfoil George
So again, I have not the influence you think I have with 3CX. But I will say I think I help 3CX staff by setting reasonable expectations for how 3CX should work and, often bluntly, saying the things they can't say as a direct employee of 3CX . And I don't need to tell people they are stupid, they make that obvious themselves. In this particular case I didn't call you stupid, I was correcting your factually incorrect statements about what 3CX does and doesn't do. Continuing to argue in the face of those facts can be construed as stupid but I leave that interpretation up to the reader.

My Footer:
No need for "Earn Crypto in your Sleep" Advertisement in my footer,
no certified, no nothing.

If you need help setting up a footer properly there are many folks on the forum that can help with that as well.:D
 
Thanks @cobalt for his extensive reply on this.
I have to admit: I was not able to make him understand the problem.:(....

Securitywise we all seem to know what is possible, and what is out of 3CX range.

And TLS/SRTP between 3CX-supported phones and the 3CX-PBX is certainly not out of 3CX range.
 
Are you saying that you haven't been able to get TLS/SRTP working between 3CX and supported hardware phones? That scenario *should* work although 3CX only controls one side of things but I would expect it to work. I'll test it tomorrow
 
Yes, I am mostly talking about PBX to internal Phones.
(Most people recommend VLAN (sniffable) or expert stuff like Layer3 encryption... between a switch and a phone...:rolleyes:)

Internally, it did not work when we tested, so we kept waiting for 1 year, hoping 3CX might work on that.
And those Titanium and Platinium we were talking to also said, that they don't do this at their clients, because it does not work with normal provisioning....
They can do it manually, takes some time to find out exactly how, and then lots of time to implement.
Upload certs manually to every phone and change certs as they run out....
Maybe we were asking at the wrong place....:)


On external Trunks:
We all know, that encryption would end most certainly at the provider. Therefore undecided priority.
At least 3cx supports it, but in our tests with 2 "by 3cx-profile officially supported providers", communication was not reliable, or trunk did not work at all.

Also no way to implement two or more certificates of those providers....
(One should be able to define the cert for each trunk separately)
Adding multiple certs in the cert-box also did not work.
 
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
111,939
Messages
589,844
Members
164,826
Latest member
Ravex comms