Jump to content

snom ONE + snom M9 = SRTP not really working


scmp
 Share

Recommended Posts

I've been on a quest to secure my voip traffic for some time and it led me to snom ONE; gave up on SRTP on Asterisk. I've been running a snom One pbx on an Amazon AMI for some time with only few issues. Recently I purchased a snom M9 and I started testing the SRTP feature. Below are the test environemnt and results; further below are my comments on how this is not really working as advertised.

 

PBX:

 

PBX Snom One 4.3.0.5020

Amazon Linux AMI release 2011.09 x32

 

snom M9: Version 9.4.12-a

 

PSTN termination: SIP trunk via sipgate

 

Test setup:

Voip phones: M9 and M3 connected to the same snom ONE pbx

Cell phone via SIP trunk

Wireshark capture ran on the pbx

Certificates are the default snom certificates on both M9 and pbx

 

Test Results:

 

*** with encryption set

Identity 1 > Account > Registrar = <pbx ip>:<TLS port>;transport=tls * Outbound Proxy = <pbx ip>:<TLS port>;transport=tls

Identity 1 > SIP > RTP Encryption = on

 

~~~logs confirm signaling over TLS (SIP/2.0/TLS)

 

M9 -> Voicemail

- padlock = closed

- decode outgoing = no

- decode incoming = no

* call not found in the capture by wireshark VoIP plugin

 

M9 -> Cell

- padlock = closed

- can hear what I say while ringing (see note 1 for explanation) = yes

- decode outgoing = yes

- decode incoming = yes

 

M9 -> M3

- padlock = closed

- can hear what I say while ringing = no

- decode outgoing = yes

- decode incoming = yes

 

M3 -> M9

- padlock = closed

- can hear what I say while ringing = yes

- decode outgoing = yes

- decode incoming = yes

 

*** with encryption NOT set

Identity 1 > Account > Registrar = <pbx ip>:<SIP port> * Outbound Proxy = <pbx ip>:<SIP port>

Identity 1 > SIP > RTP Encryption = off

 

M9 -> Voicemail

- padlock = open

- decode outgoing = no

- decode incoming = no

* call found in the capture by wireshark VoIP plugin, decoded but nothing playing

 

M9 -> Cell

- padlock = open

- can hear what I say while ringing = yes

- decode outgoing = yes

- decode incoming = yes

 

M9 -> M3

- padlock = open

- can hear what I say while ringing = no

- decode outgoing = yes

- decode incoming = yes

 

M3 -> M9

- padlock = open

- can hear what I say while ringing = yes

- decode outgoing = yes

- decode incoming = yes

 

note 1:

"can hear what I say while ringing" means that while playing the capture decoded with wireshark I can hear myself talking while the remote party is still ringing (before picking up). This is on the caller' stream. So media is transmitted before the call is set up.

 

=================================

 

This is it. It looks like the only really secure call is the M9 - Voicemail call. For the tests with the M3 phone I was expecting that the M9-PBX leg to be encrypted and PBX-M3 not encrypted. Same for the tests with the cell phone (M9-PBX leg to be encrypted). I'm assuming that a call between 2 M9 phones with encryption set would be indeed encrypted end to end. The tests without encryption set are not relevant for this encryption issue; I tested that way to see if the media is sent early as in the first tests.

 

So, what am I missing? The closed padlock is certainly misleading. Am I not understanding correctly how this encryption thingy is supposed to work or did I run into some known bugs with M9?

Link to comment
Share on other sites

The M3 is end of life and never supported TLS/SRTP. So that part is clear.

 

The m9 should always do SRTP. The indication on the handset can be a little bit "misleading", I would consider that a minor problem. Not sure why that is not the case when you talk to the mailbox. The only idea that I have is that the direct call answer screws something up. There is a ticket SMN-343 for this now, so if there is a bug the fix should be on the way.

Link to comment
Share on other sites

The M3 is end of life and never supported TLS/SRTP. So that part is clear.

 

The m9 should always do SRTP. The indication on the handset can be a little bit "misleading", I would consider that a minor problem. Not sure why that is not the case when you talk to the mailbox. The only idea that I have is that the direct call answer screws something up. There is a ticket SMN-343 for this now, so if there is a bug the fix should be on the way.

 

Thank you for replying. Not sure why you consider the padlock indication a minor problem. We are talking about security. A phone is advertised and sold as supporting TLS/SRTP and the product datasheets tout security and privacy. Yet, the phone shows an encrypted call but it can be decoded with 2 mouse clicks. Nevermind the M3 not supporting TLS/SRTP it is only about M9. If security is dropped because one endpoint doesn't support it then the padlock should stay open on the M9 screen. If I force codec selection on the registration settings, M9 G722 and M3 G711 then the PBX will do transcoding so media is sure to travel M9-PBX-M3. But in this scenario the entire M9-PBX-M3 stream is unencrypted (M9 padlock shows closed) not only PBX-M3. Where is that ticket you mentioned opened? Is it publicly available to read how it is addressed?

Link to comment
Share on other sites

Thank you for replying. Not sure why you consider the padlock indication a minor problem. We are talking about security. A phone is advertised and sold as supporting TLS/SRTP and the product datasheets tout security and privacy. Yet, the phone shows an encrypted call but it can be decoded with 2 mouse clicks. Nevermind the M3 not supporting TLS/SRTP it is only about M9. If security is dropped because one endpoint doesn't support it then the padlock should stay open on the M9 screen. If I force codec selection on the registration settings, M9 G722 and M3 G711 then the PBX will do transcoding so media is sure to travel M9-PBX-M3. But in this scenario the entire M9-PBX-M3 stream is unencrypted (M9 padlock shows closed) not only PBX-M3. Where is that ticket you mentioned opened? Is it publicly available to read how it is addressed?

 

Well, first of all the lock only indicates that the traffic between the PBX and the handset is encrypted. There used to be a feature called "end to end encryption" on the PBX, but in the last five years NOBODY ever paid attention to that and even the IETF is still arguing what exacly "sips" means. I agree the lock on the screen is something that needs to be fixed, but the actual encryption is definitevely more critical.

 

You might want to take a look at ZRTP (the m9 supports that, see http://snom-m9.blogspot.com/2011/09/does-zrtp-solve-key-exchange-problem.html), this implements end-to-end encryption but both sides need to have it. We would have to support the ZRTP packet passthrough also in the PBX, which would not be very hard, but something that would have to be done.

 

The ticket number is just for refenence in the release notes. The ticket system is not public.

 

I agree there is a lot of marketing bla bla in the security area. Only very few people really pay attention to it. For most customers, the color of the handset is much more important than encrypting their voice.

Link to comment
Share on other sites

Well, first of all the lock only indicates that the traffic between the PBX and the handset is encrypted. There used to be a feature called "end to end encryption" on the PBX, but in the last five years NOBODY ever paid attention to that and even the IETF is still arguing what exacly "sips" means. I agree the lock on the screen is something that needs to be fixed, but the actual encryption is definitevely more critical.

 

You might want to take a look at ZRTP (the m9 supports that, see http://snom-m9.blogspot.com/2011/09/does-zrtp-solve-key-exchange-problem.html), this implements end-to-end encryption but both sides need to have it. We would have to support the ZRTP packet passthrough also in the PBX, which would not be very hard, but something that would have to be done.

 

The ticket number is just for refenence in the release notes. The ticket system is not public.

 

I agree there is a lot of marketing bla bla in the security area. Only very few people really pay attention to it. For most customers, the color of the handset is much more important than encrypting their voice.

 

Sorry if I'm being dense, but what I saw in my tests is that the M9-PBX stream is not encrypted when talking either with an endpoint that does not support SRTP or through a SIP trunk. This is the part I cannot get my head around. My expectation was to have M9-PBX stream encrypted and PBX-sip trunk unencrypted. Thanks for the link; hopefully ZRTP passthrough will be available in Snom ONE soon. From the comments section of the that blog post I understand that regular builds don't include ZRTP but a custom one could be provided. If that's the case, can I have it? :) Getting additional M9 endpoints would take care of the encryption issue with key exchange so the ZRTP built would be just for me to toy around with.

 

However, here is my real life situation that keeps me trying for real encryption. One of the endpoints is in an European country that pumps out hackers on an assembly line. On my last visit I had an account for an online service hacked by sniffing the traffic at the demarc. The endpoint there is now a Grandstream that doesn't support TLS/SRTP and my plan was to replace it with an M9. My Snom ONE PBX is on an Amazon EC2 machine. I'm in the US and I have the M9 here (replaced an M3). So, once I ship an M9 overseas, internal calls are safe (key exchange or ZRTP). What concerns me is the call between the non-US M9 and my cell phone. Since the call to my cell phone will go over the sipgate trunk the encryption will be dropped altogether for the entire stream and not only the PBX-sipgate-cell legs.

Link to comment
Share on other sites

A quick check from here: When I use TLS and make sure that "RTP Encryption" is on, at least calling the mailbox is encrypted. Maybe a configuration problem? Did you use plug and play to configure the device?

 

Hi

Nope, no plug an play. I just configured the phone manually.

Link to comment
Share on other sites

Then please check if you actually turned SRTP on :rolleyes: or use PnP... There is a setting "RTP encryption" and it could be that this setting is "off".

 

Well, it is enabled as I stated at the beginning of the first post:

Identity 1 > Account > Registrar = <pbx ip>:<TLS port>;transport=tls * Outbound Proxy = <pbx ip>:<TLS port>;transport=tls

Identity 1 > SIP > RTP Encryption = on

 

I actually got the RMA; it is going back. I bought it for the "security" features but those seem to not go beyond the marketing materials. To top it off, the volume is low and it creates a bad echo when using a headset. M3 didn't have those issues. Perhaps I'll give M10 a try if there will be such a device but in the meantime I'll go the Grandstream-3CX route. Thank you.

Link to comment
Share on other sites

Well, you should use plug and play. For example, the domain registrar is wrong. For the volume, there are keys on the side to control the volume. Anyway, good luck with 3CX and Grandstream.

 

 

Domain registrar is wrong? You do realize that it was an example as I didn't want to post the fqdn and ports of my pbx, right? If you actually used M9 and snom you would have known that if the registrar was wrong I could have not register the M9 in the first place, nevermind testing and capturing traffic. I think you already know that plug and play would have fixed absolutely nothing for the encryption issue; you are just posting non-sense now. And you don't say, there are buttons on the side of the phone? That must be a miracle. It never crossed my mind to turn the volume up from the keys... Perhaps you want to inform the readers of this forum why vendors call the M9 a "boomerang".

 

I shiver to think of paying for your commercial license and receive this kind of support. Wanna guess how many times I'm going to recommend snom as a business voip solution?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...