How to tell whether communication is secure?

[MucCX]

Hi,

So this may be actually two topics:

Is there a status light (or similar) somewhere that tells me whether the calls I make via 3cx are secure (i.e. encrypted)?

If not, what do I have to check to find out? (And may I suggest to put an indicator on the dashboard for this - this would probably be of interest to others as well.)

I note that in Settings > Security Settings > Secure SIP there is a check box "Secure SIP/TLS" which used to be checked (and a certificate and a key shown below) but that now is unchecked (with not certificate and no key shown). (I am certain that I did not deactivate this or delete the certificate and key!)

I am assuming I have to enable that again but I don't know where to get the certificate and key from. This link seems to explain https://www.3cx.com/docs/secure-sip/ but I seem to be missing a piece. Under "Configuring Secure SIP (TLS) for 3CX-provided FQDNs" it talks about using the provided Let's Encrypt certificate but that might be what disappeared from my 3cx installation. So how do I get it back?

Any help greatly appreciated!

 

[cobaltit]

Secure to what end? And for what leg? It's pretty much impossible to guarantee calls are encrypted end to end unless you control the entire network. There's no compliance standard that requires encrypted calls (at least that I'm aware of) so there's no real big push for something like this. And because encryption requires resources to support it, you aren't going to see it just happen over night. Very few dial tone providers support encryption and even if they do, once it hits the PSTN it's no longer encrypted so it's not particularly useful.

Some desk phones will show a lock icon when using SIP-TLS or SRTP but that's phone/vendor specific and needs to be manually configured. 3CX apps (current ones) and web client always encrypt the traffic but that's just from the client to 3CX. Desk phones using the SBC in the default configuration have the traffic encrypted between the SBC and 3CX, but still unencrypted between the phone and SBC and most likely from 3CX to the PSTN.

 

[MucCX]

Secure to what end?

So that others cannot listen in.

And for what leg?

The one that goes across the internet.

It's pretty much impossible to guarantee calls are encrypted end to end unless you control the entire network.

That's true. But I would like to achieve as much security as possible.

There's no compliance standard that requires encrypted calls (at least that I'm aware of) so there's no real big push for something like this.

That may be (I really wouldn't know). But I guess nobody wants their calls listened in on, whether there is compliance standard against it or not. I certainly don't.

Very few dial tone providers support encryption and even if they do, once it hits the PSTN it's no longer encrypted so it's not particularly useful.

Sorry, I don't know what a dial tone provider is. If you are talking about analogue phone lines - understood. I should have made clear, I am talking about VOIP.

3CX apps (current ones) and web client always encrypt the traffic but that's just from the client to 3CX.

That's a good start. But TBH that's the part that I am least worried about.

In summarizing, I take it, there is no status light in 3CX and there won't be one anytime soon.

Until then, where do I have to look to see whether the communication that goes across the internet is encrypted?

Thanks!

 

[SteveITS]

dial tone provider

Your SIP trunk provider. It sounds like you're asking if your SIP provider supports an encrypted connection between them and 3CX, and from the SIP provider to the destination number.

 

[Kevin@voxtelesys]

It was mentioned above, if you are using encryption (SRTP) with your carrier then you would have encrypted calls to your carrier from your phone system. Once that call leaves your carriers network to reach your terminating call it will not be encrypted, or highly likely wont be.

 

[leejor]

When it comes down to it, if someone (Government agency?) wants to hear (record?) your conversations, it's going to happen, no matter what steps you take to prevent that. The chances that someone random, on the internet, is going to be listening, is probably less likely than being in an accident on the way to work. As mentioned an encrypted call, only goes so far unless it is VoIP one end to the other, and all carriers honour the encryption. Once it transfers to a PSTN provider, especially the "last mile", over copper, which is actually the most vulnerable, then all bets are off.

 

[cobaltit]

So dial tone provider is simply whoever you are using to connect your phone system to the rest of the world, thus providing 'dial tone'. I see a lot of people asking about encrypted VoIP like PSTN was so secure to start with. A 5 year old could listen in to your conversation on a POTS line so VoIP is already significantly more secure in that sense. And you say you aren't concerned about the local leg (extension to PBX) but that's actually where it's MOST likely and easiest for your VoIP traffic to get sniffed.

And if you think about it, it's kinda silly to ask for an indicator for when it's encrypted. Realistically if you care about encryption and security, your system should ONLY be communicating securely, not conditional and thus needing an indicator.

The closest and most reasonable 'security' you can achieve with any VoIP PBX is to use what enterprises have been using for years for other data. VPC or VPN to your VoIP provider.

 

[MucCX]

Your SIP trunk provider. It sounds like you're asking if your SIP provider supports an encrypted connection between them and 3CX, and from the SIP provider to the destination number.

Hmm. I thought that a SIP provider only helps negotiate the terms of a call between the two endpoints but that the content of the call (i.e. the payload, my voice) is transported directly between the two phones (assuming both are VOIP phones and not classic land line phones).

So this is where I would like to see the encryption happen: Between the two VOIP phones. (It would be nice to also have the SIP messages between my phone (or my 3CX) and my SIP provider encrypted, but I care much more about my call.

 

[MucCX]

It was mentioned above, if you are using encryption (SRTP) with your carrier then you would have encrypted calls to your carrier from your phone system. Once that call leaves your carriers network to reach your terminating call it will not be encrypted, or highly likely wont be.

Is that also true for calls between two VOIP phones?

In any case, I am with the local market leader. And so are most other people here. So the majority of my calls will be within the network of my provider. So if staying within a provider's network is actually a requirement, it would be met in most of my use cases.

 

[MucCX]

As mentioned an encrypted call, only goes so far unless it is VoIP one end to the other, and all carriers honour the encryption.

Yes, as specified above, this is my scenario: Calls between two VOIP phones.

If two VOIP phones talk to each other directly and encrypt the call between them, I don't see where a carrier would come in that even would be in a position to not honour the encryption. (But maybe it's my not completely understanding the technology.)

 

[MucCX]

So dial tone provider is simply whoever you are using to connect your phone system to the rest of the world, thus providing 'dial tone'. I see a lot of people asking about encrypted VoIP like PSTN was so secure to start with. A 5 year old could listen in to your conversation on a POTS line so VoIP is already significantly more secure in that sense.

Well, we don't have that here anymore. It's all VOIP, no POTS. So my 3CX connects to my telephone provider via SIP and its VOIP all the way through to the person I am calling. They may have a plain old telephone on their end but it would be their own internet router that translates the VOIP into a plain analogue call, not a "dial tone provider".

And you say you aren't concerned about the local leg (extension to PBX) but that's actually where it's MOST likely and easiest for your VoIP traffic to get sniffed.

As far as my LAN is concerned, I am not concerned that anybody will be able to listen in.

And if you think about it, it's kinda silly to ask for an indicator for when it's encrypted. Realistically if you care about encryption and security, your system should ONLY be communicating securely, not conditional and thus needing an indicator.

My goal is to actually only communicate securely. That's exactly why I would like to get a visual confirmation that everything is working as it is supposed to be. And if a red light is on instead of a green one, I know I need to investigate.

The closest and most reasonable 'security' you can achieve with any VoIP PBX is to use what enterprises have been using for years for other data. VPC or VPN to your VoIP provider.

My VOIP provider is my internet provider, so I am already connected directly to my VOIP provider.

 

[cobaltit]

Yes, as specified above, this is my scenario: Calls between two VOIP phones.

If two VOIP phones talk to each other directly and encrypt the call between them, I don't see where a carrier would come in that even would be in a position to not honour the encryption. (But maybe it's my not completely understanding the technology.)

So your original question didn't cover this, and it's still slightly ambiguous. Two VOIP phones could have many permutations. Are we talking two hardware IP phones, 2 web clients, 2 soft clients, 1 and 1 of any combination? You also asked about an INDICATOR of encryption. So is that the primary concern, or just encryption?

For example:
- Any soft client (Windows/Web Client/smart phone client) call to another extension on the same 3CX instance is encrypted. But only the smart phone client specifically indicates the call is encrypted. There's no visual indicator in the windows client while the web client can be inferred via the SSL status of the web page. And even then the indicator is only that the call is encrypted between the soft phone client and 3CX, not end to end.
- Any soft client call to another soft client on another 3CX system, going across a 3CX bridge configured to use the tunnel protocol would be encrypted but again, not always have an indicator.

The fact that you use the same carrier between two PBXes also doesn't guarantee encryption. For one, it would require that both your trunk to the provider is encrypted AND the trunk to the other PBX is encrypted. It also depends on how the provider handles what they consider on-net calls. Depending on how their network is architected they may route even on-net calls to the PSTN and then back again for accounting purposes. This would lose the encryption.

Long story short, if you don't control the network or if you are using a medium that was not originally designed to be encrypted/secure then you have no expectations of such. This is things like WhatsApp, Telegram, etc were created with End-to-End encryption as part of the original design.

 

[cobaltit]

Well, we don't have that here anymore. It's all VOIP, no POTS. So my 3CX connects to my telephone provider via SIP and its VOIP all the way through to the person I am calling. They may have a plain old telephone on their end but it would be their own internet router that translates the VOIP into a plain analogue call, not a "dial tone provider".

I think you missed the point. How the dial tone is provided does not change the fact that they are providing dial tone. So yes, your VoIP provider is your dial tone provider.

My goal is to actually only communicate securely. That's exactly why I would like to get a visual confirmation that everything is working as it is supposed to be. And if a red light is on instead of a green one, I know I need to investigate.

Again, if the system is designed to ONLY communicate securely, then communicating insecurely is not an option. So your 'red' light would be when you can't make a call.

My VOIP provider is my internet provider, so I am already connected directly to my VOIP provider.

That doesn't guarantee anything as far as security. Best case scenario is that while your VOIP traffic doesn't touch the public internet, it's still mingled with the rest of the traffic for that provider so thus not secure. Worst case scenario is that they aren't even housing their own services and have it outsourced. Now the assumption is that even in that case it shouldn't touch the public internet as they should have some sort of peering but you never know. It wouldn't be the first time a network was not designed properly, especially if the VOIP services were part of a merger or acquisition.

 

[MucCX]

The fact that you use the same carrier between two PBXes also doesn't guarantee encryption. For one, it would require that both your trunk to the provider is encrypted AND the trunk to the other PBX is encrypted. It also depends on how the provider handles what they consider on-net calls. Depending on how their network is architected they may route even on-net calls to the PSTN and then back again for accounting purposes. This would lose the encryption.

I don't know how realistic this scenario is in other places in the world, but around here we don't have a POTS system anymore. It's all VOIP.

But let's say that this could happen, if I make a call abroad. That would be a good example for when I would like that indicator to tell me "Careful! This call is not encrypted."

Long story short, if you don't control the network or if you are using a medium that was not originally designed to be encrypted/secure then you have no expectations of such. This is things like WhatsApp, Telegram, etc were created with End-to-End encryption as part of the original design.

Actually, as far as I know, WhatsApp communication was not end-to-end encrypted in the beginning. That was only implemented later when the public became more security aware.

 

[cobaltit]

But let's say that this could happen, if I make a call abroad. That would be a good example for when I would like that indicator to tell me "Careful! This call is not encrypted."

In that case, the indicator would be the number you are dialing. If it's not a local extension on your PBX, it's not encrypted.

 

[MucCX]

I think you missed the point. How the dial tone is provided does not change the fact that they are providing dial tone. So yes, your VoIP provider is your dial tone provider.

The point is: There is no switching of media within the connection. The call originates and terminates as a VOIP call. It is not routed across a POTS in between where encryption would either fail or make the routing impossible.

(And my dial tone is generated by my VOIP phone as an homage to old school analogue phones.)

Again, if the system is designed to ONLY communicate securely, then communicating insecurely is not an option. So your 'red' light would be when you can't make a call.

If I am only ordering a pizza, I might be willing to compromise.

That doesn't guarantee anything as far as security. Best case scenario is that while your VOIP traffic doesn't touch the public internet, it's still mingled with the rest of the traffic for that provider so thus not secure. Worst case scenario is that they aren't even housing their own services and have it outsourced. Now the assumption is that even in that case it shouldn't touch the public internet as they should have some sort of peering but you never know. It wouldn't be the first time a network was not designed properly, especially if the VOIP services were part of a merger or acquisition.

Fully agreed. That is why I want to know when my call is secure and when it is not.

 

[MucCX]

In that case, the indicator would be the number you are dialing. If it's not a local extension on your PBX, it's not encrypted.

Okay, so you are saying, I can't have encrypted calls beyond my own 3cx system.

Not what I was hoping for. But that is an answer. Thanks!

 

[cobaltit]

Actually, as far as I know, WhatsApp communication was not end-to-end encrypted in the beginning. That was only implemented later when the pubic became more security aware.

Not sure and not really the point. The point is that if it was not designed from day 1 to be encrypted/secure, then you can't make any assumption that it is. Look at HTTP for example. It's been around for a LONG time, and encryption was added in very early as extensions or revisions to the standard. SSL certificates were relatively cheap for some time but until LE came up, it still provided a cost barrier for widespread adoption. Google has a nice page showing encrypted traffic across all of their services. Notice it's not at 100%

HTTPS encryption on the web – Google Transparency Report


Encryption has a cost. It takes more CPU cycles, it breaks compatibility with legacy devices, it has a support cost, it has a learning curve, and it's not mandated by anything that I'm aware of. But the biggest factor is always money. As long as it's more expensive to provide encryption, and there's no financial motivation to do so, it won't happen. Now whether that financial motivation is from folks willing to pay a premium, or penalties for non-compliance with certain regulations or most likely some combination of both doesn't matter, but it's money that makes the world go 'round.

 

[cobaltit]

The point is: There is no switching of media within the connection. The call originates and terminates as a VOIP call. It is not routed across a POTS in between where encryption would either fail or make the routing impossible.

(And my dial tone is generated by my VOIP phone as an homage to old school analogue phones.)

It has nothing to do with switching of media. I more specific term (and old for sure) would be hard dial tone. I use the term dial tone provider because it covers all sources (POTS, VoIP, ISDN, cellular, etc). At the end of the day they are providing your voice connectivity beyond your PBX. The tone you get when you pickup a handset would be referred to as PBX/soft dial tone back in the day. But the reason I mention it is even in the event of a VOIP to ATA conversion, it can still be exposed. While pretty much all new residential phone service is delivered over VOIP to a modem that sits inside the house, the local cable provider in my mom's neighborhood used to install the ATAs outside where the cable drop came done from the street. So for those setups, one could still clip a buttset on the line the same as you can with POTS. The difference being you'd have to be right at the box outside the house vs being able to do it down the street on a pole but still easy.

But it looks like you understand what I'm referring to and certainly not the focus as far as encryption goes.