Sponsor: VoiceMeUp - Corporate & Wholesale VoIP Services

VoIP Mailing List Archives
Mailing list archives for the VoIP community
 SearchSearch 

[Freeswitch-users] SSL implementation in FreeSWITCH


 
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users
View previous topic :: View next topic  
Author Message
lists at kavun.ch
Guest





PostPosted: Thu Mar 10, 2016 2:39 pm    Post subject: [Freeswitch-users] SSL implementation in FreeSWITCH Reply with quote

Hi all,
I’m writing to document where I’m at with my issues with FreeSWITCH and SSL / TLS and share my conclusions so far.
I am hoping that this can give lieu to some further testing in different environments, and a proper fix if a bug is indeed confirmed.

First, I am running FreeSWITCH 1.6.6 on a Debian 8. Vars.xml shows sip_tls_version=tlsv1,tlsv1.1,tlsv1.2.

What I’ve observed is that in a sequence where
client sens an invite to FS;
FS responds with 407 proxy authorization required;
client sends ack;
Client sends the invite with the digest auth.

The last packet can easily exceed the max segment size of a TCP segment, typically if the SDP advertises a bunch of codecs, or if the client uses SRTP and the SAVP contains many crypto suites.

Now, when this occurs, the packets should be sent fragmented so they can fit in the MTU. It is then up to the receiving end to reassemble the segments and feed the complete packet to the application layer.

What I’ve noticed is that a packet that is too large is simply never received by FreeSWITCH. Since this is systematically the case with every software and hardware client I’ve used, I am drawn to think that the issue lies in the SSL implementation of FreeSWITCH.

In the event that for some reason my network or server OS configuration may be behind this, I would appreciate if someone would be willing to share some SIP credentials that can let me test TLS and SRTP. If getting to the bottom of this is of interest to any of you, I’d obviously be keen on handing out a couple of accounts.

I hope this message can be the starting point of a fruitful resolution process.

Thank you if you’ve read this up to here. Now hit reply and give me your 2 cents! :)

Best,
Emrah
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Back to top
krice at freeswitch.org
Guest





PostPosted: Thu Mar 10, 2016 2:44 pm    Post subject: [Freeswitch-users] SSL implementation in FreeSWITCH Reply with quote

Are you sure you are sending this over TCP/TLS? This sounds like its really using UDP... TCP automatically does packet reassembly, UDP does not. The behavior you described sounds suspiciously like you are using UDP instead of TCP/TLS

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Emrah
Sent: Thursday, March 10, 2016 1:37 PM
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>
Subject: [Freeswitch-users] SSL implementation in FreeSWITCH

Hi all,
I’m writing to document where I’m at with my issues with FreeSWITCH and SSL / TLS and share my conclusions so far.
I am hoping that this can give lieu to some further testing in different environments, and a proper fix if a bug is indeed confirmed.

First, I am running FreeSWITCH 1.6.6 on a Debian 8. Vars.xml shows sip_tls_version=tlsv1,tlsv1.1,tlsv1.2.

What I’ve observed is that in a sequence where client sens an invite to FS; FS responds with 407 proxy authorization required; client sends ack; Client sends the invite with the digest auth.

The last packet can easily exceed the max segment size of a TCP segment, typically if the SDP advertises a bunch of codecs, or if the client uses SRTP and the SAVP contains many crypto suites.

Now, when this occurs, the packets should be sent fragmented so they can fit in the MTU. It is then up to the receiving end to reassemble the segments and feed the complete packet to the application layer.

What I’ve noticed is that a packet that is too large is simply never received by FreeSWITCH. Since this is systematically the case with every software and hardware client I’ve used, I am drawn to think that the issue lies in the SSL implementation of FreeSWITCH.

In the event that for some reason my network or server OS configuration may be behind this, I would appreciate if someone would be willing to share some SIP credentials that can let me test TLS and SRTP. If getting to the bottom of this is of interest to any of you, I’d obviously be keen on handing out a couple of accounts.

I hope this message can be the starting point of a fruitful resolution process.

Thank you if you’ve read this up to here. Now hit reply and give me your 2 cents! :)

Best,
Emrah
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Back to top
mgg at giagnocavo.net
Guest





PostPosted: Fri Mar 11, 2016 12:16 am    Post subject: [Freeswitch-users] SSL implementation in FreeSWITCH Reply with quote

Can you do TCP without TLS and pcap it? Or pcap the TLS and provide the key (if no PFS)?
-Michael

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Emrah
Sent: Thursday, 10 March, 2016 13:37
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>
Subject: [Freeswitch-users] SSL implementation in FreeSWITCH

Hi all,
I’m writing to document where I’m at with my issues with FreeSWITCH and SSL / TLS and share my conclusions so far.
I am hoping that this can give lieu to some further testing in different environments, and a proper fix if a bug is indeed confirmed.

First, I am running FreeSWITCH 1.6.6 on a Debian 8. Vars.xml shows sip_tls_version=tlsv1,tlsv1.1,tlsv1.2.

What I’ve observed is that in a sequence where client sens an invite to FS; FS responds with 407 proxy authorization required; client sends ack; Client sends the invite with the digest auth.

The last packet can easily exceed the max segment size of a TCP segment, typically if the SDP advertises a bunch of codecs, or if the client uses SRTP and the SAVP contains many crypto suites.

Now, when this occurs, the packets should be sent fragmented so they can fit in the MTU. It is then up to the receiving end to reassemble the segments and feed the complete packet to the application layer.

What I’ve noticed is that a packet that is too large is simply never received by FreeSWITCH. Since this is systematically the case with every software and hardware client I’ve used, I am drawn to think that the issue lies in the SSL implementation of FreeSWITCH.

In the event that for some reason my network or server OS configuration may be behind this, I would appreciate if someone would be willing to share some SIP credentials that can let me test TLS and SRTP. If getting to the bottom of this is of interest to any of you, I’d obviously be keen on handing out a couple of accounts.

I hope this message can be the starting point of a fruitful resolution process.

Thank you if you’ve read this up to here. Now hit reply and give me your 2 cents! Smile

Best,
Emrah
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Back to top
s.safarov at gmail.com
Guest





PostPosted: Fri Mar 11, 2016 12:51 am    Post subject: [Freeswitch-users] SSL implementation in FreeSWITCH Reply with quote

If want send TLS+encryption key check that RSA encryption is used. Some other encryption may not allow decryption.
On Fri, Mar 11, 2016, 08:15 Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:

Quote:
Can you do TCP without TLS and pcap it? Or pcap the TLS and provide the key (if no PFS)?
-Michael

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of Emrah
Sent: Thursday, 10 March, 2016 13:37
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)>
Subject: [Freeswitch-users] SSL implementation in FreeSWITCH

Hi all,
I’m writing to document where I’m at with my issues with FreeSWITCH and SSL / TLS and share my conclusions so far.
I am hoping that this can give lieu to some further testing in different environments, and a proper fix if a bug is indeed confirmed.

First, I am running FreeSWITCH 1.6.6 on a Debian 8. Vars.xml shows sip_tls_version=tlsv1,tlsv1.1,tlsv1.2.

What I’ve observed is that in a sequence where client sens an invite to FS; FS responds with 407 proxy authorization required; client sends ack;  Client sends the invite with the digest auth.

The last packet can easily exceed the max segment size of a TCP segment, typically if the SDP advertises a bunch of codecs, or if the client uses SRTP and the SAVP contains many crypto suites.

Now, when this occurs, the packets should be sent fragmented so they can fit in the MTU. It is then up to the receiving end to reassemble the segments and feed the complete packet to the application layer.

What I’ve noticed is that a packet that is too large is simply never received by FreeSWITCH. Since this is systematically the case with every software and hardware client I’ve used, I am drawn to think that the issue lies in the SSL implementation of FreeSWITCH.

In the event that for some reason my network or server OS configuration may be behind this, I would appreciate if someone would be willing to share some SIP credentials that can let me test TLS and SRTP. If getting to the bottom of this is of interest to any of you, I’d obviously be keen on handing out a couple of accounts.

I hope this message can be the starting point of a fruitful resolution process.

Thank you if you’ve read this up to here. Now hit reply and give me your 2 cents! Smile

Best,
Emrah
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org (consulting@freeswitch.org)
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org (consulting@freeswitch.org)
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Back to top
lists at kavun.ch
Guest





PostPosted: Fri Mar 11, 2016 4:59 pm    Post subject: [Freeswitch-users] SSL implementation in FreeSWITCH Reply with quote

Hi there,
I am using TLS over TCP for sure. I spent a significant amount of time inspecting this and UDP is only used for the RTP stream.
People have reported issues with Polycom phones where the TLS thread crashes when the SDP is overloaded.
http://community.polycom.com/t5/VoIP/IP550-Loses-Registration-as-soon-as-I-try-to-make-a-call/td-p/21372
This is not just a Polycom issue, and doesn’t seem to be happening with other SIP servers.
Many times, because the client doesn’t get a response, it sends the packets over and over and eventually times out.
I doubt that the same SIP stack is used across Polycom, Yealink, Counterpath Bria, Blink Pro, etc…
I will put together a PCAP of the session in TCP since I can’t share the private key of the SSL certificate.
Is someone willing to provide me with a SIP account where I can test TLS connections with SRTP enabled? An Echo test is enough.

Thanks
Quote:
On Mar 10, 2016, at 8:42 PM, Ken Rice <krice@freeswitch.org> wrote:

Are you sure you are sending this over TCP/TLS? This sounds like its really using UDP... TCP automatically does packet reassembly, UDP does not. The behavior you described sounds suspiciously like you are using UDP instead of TCP/TLS

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Emrah
Sent: Thursday, March 10, 2016 1:37 PM
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>
Subject: [Freeswitch-users] SSL implementation in FreeSWITCH

Hi all,
I’m writing to document where I’m at with my issues with FreeSWITCH and SSL / TLS and share my conclusions so far.
I am hoping that this can give lieu to some further testing in different environments, and a proper fix if a bug is indeed confirmed.

First, I am running FreeSWITCH 1.6.6 on a Debian 8. Vars.xml shows sip_tls_version=tlsv1,tlsv1.1,tlsv1.2.

What I’ve observed is that in a sequence where client sens an invite to FS; FS responds with 407 proxy authorization required; client sends ack; Client sends the invite with the digest auth.

The last packet can easily exceed the max segment size of a TCP segment, typically if the SDP advertises a bunch of codecs, or if the client uses SRTP and the SAVP contains many crypto suites.

Now, when this occurs, the packets should be sent fragmented so they can fit in the MTU. It is then up to the receiving end to reassemble the segments and feed the complete packet to the application layer.

What I’ve noticed is that a packet that is too large is simply never received by FreeSWITCH. Since this is systematically the case with every software and hardware client I’ve used, I am drawn to think that the issue lies in the SSL implementation of FreeSWITCH.

In the event that for some reason my network or server OS configuration may be behind this, I would appreciate if someone would be willing to share some SIP credentials that can let me test TLS and SRTP. If getting to the bottom of this is of interest to any of you, I’d obviously be keen on handing out a couple of accounts.

I hope this message can be the starting point of a fruitful resolution process.

Thank you if you’ve read this up to here. Now hit reply and give me your 2 cents! :)

Best,
Emrah
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Back to top
krice at freeswitch.org
Guest





PostPosted: Fri Mar 11, 2016 5:10 pm    Post subject: [Freeswitch-users] SSL implementation in FreeSWITCH Reply with quote

The particular message on the polycom boards only References FreeSWITCH 1.2... there have been significant changes from that point... without getting decoded packet captures theres really not much to see here.

TCP handles the packet fragmentation as should TLS... this is transport protocol later stuff... this is not something FreeSWITCH would really be involved in at that point...

The other thing that might prove useful is isolating this on an idle machine, with 1 phone enabling all the good SIP and libsofia debugging and getting it into a long along with the logs from the client so it can be compared to see whats going on...

Further discussion of this should be taken to jira so that it can be tracked and captures and logging can be attached to the ticket

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Emrah
Sent: Friday, March 11, 2016 3:57 PM
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>
Subject: Re: [Freeswitch-users] SSL implementation in FreeSWITCH

Hi there,
I am using TLS over TCP for sure. I spent a significant amount of time inspecting this and UDP is only used for the RTP stream.
People have reported issues with Polycom phones where the TLS thread crashes when the SDP is overloaded.
http://community.polycom.com/t5/VoIP/IP550-Loses-Registration-as-soon-as-I-try-to-make-a-call/td-p/21372
This is not just a Polycom issue, and doesn’t seem to be happening with other SIP servers.
Many times, because the client doesn’t get a response, it sends the packets over and over and eventually times out.
I doubt that the same SIP stack is used across Polycom, Yealink, Counterpath Bria, Blink Pro, etc… I will put together a PCAP of the session in TCP since I can’t share the private key of the SSL certificate.
Is someone willing to provide me with a SIP account where I can test TLS connections with SRTP enabled? An Echo test is enough.

Thanks
Quote:
On Mar 10, 2016, at 8:42 PM, Ken Rice <krice@freeswitch.org> wrote:

Are you sure you are sending this over TCP/TLS? This sounds like its
really using UDP... TCP automatically does packet reassembly, UDP does
not. The behavior you described sounds suspiciously like you are using
UDP instead of TCP/TLS

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org
[mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of
Emrah
Sent: Thursday, March 10, 2016 1:37 PM
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>
Subject: [Freeswitch-users] SSL implementation in FreeSWITCH

Hi all,
I’m writing to document where I’m at with my issues with FreeSWITCH and SSL / TLS and share my conclusions so far.
I am hoping that this can give lieu to some further testing in different environments, and a proper fix if a bug is indeed confirmed.

First, I am running FreeSWITCH 1.6.6 on a Debian 8. Vars.xml shows sip_tls_version=tlsv1,tlsv1.1,tlsv1.2.

What I’ve observed is that in a sequence where client sens an invite to FS; FS responds with 407 proxy authorization required; client sends ack; Client sends the invite with the digest auth.

The last packet can easily exceed the max segment size of a TCP segment, typically if the SDP advertises a bunch of codecs, or if the client uses SRTP and the SAVP contains many crypto suites.

Now, when this occurs, the packets should be sent fragmented so they can fit in the MTU. It is then up to the receiving end to reassemble the segments and feed the complete packet to the application layer.

What I’ve noticed is that a packet that is too large is simply never received by FreeSWITCH. Since this is systematically the case with every software and hardware client I’ve used, I am drawn to think that the issue lies in the SSL implementation of FreeSWITCH.

In the event that for some reason my network or server OS configuration may be behind this, I would appreciate if someone would be willing to share some SIP credentials that can let me test TLS and SRTP. If getting to the bottom of this is of interest to any of you, I’d obviously be keen on handing out a couple of accounts.

I hope this message can be the starting point of a fruitful resolution process.

Thank you if you’ve read this up to here. Now hit reply and give me
your 2 cents! :)

Best,
Emrah
______________________________________________________________________
___ Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use
rs
http://www.freeswitch.org


______________________________________________________________________
___ Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use
rs
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Back to top
brian at freeswitch.org
Guest





PostPosted: Fri Mar 11, 2016 5:13 pm    Post subject: [Freeswitch-users] SSL implementation in FreeSWITCH Reply with quote

What kind of router is doing your nat?  

Smells like someone needs 'ip virtual-reassembly'


On Fri, Mar 11, 2016 at 4:09 PM, Ken Rice <krice@freeswitch.org (krice@freeswitch.org)> wrote:
Quote:
The particular message on the polycom boards only References FreeSWITCH 1.2... there have been significant changes from that point... without getting decoded packet captures theres really not much to see here.

TCP handles the packet fragmentation as should TLS... this is transport protocol later stuff... this is not something FreeSWITCH would really be involved in at that point...

The other thing that might prove useful is isolating this on an idle machine, with 1 phone enabling all the good SIP and libsofia debugging and getting it into a long along with the logs from the client so it can be compared to see whats going on...

Further discussion of this should be taken to jira so that it can be tracked and captures and logging can be attached to the ticket

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of Emrah
Sent: Friday, March 11, 2016 3:57 PM
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)>
Subject: Re: [Freeswitch-users] SSL implementation in FreeSWITCH

Hi there,
I am using TLS over TCP for sure. I spent a significant amount of time inspecting this and UDP is only used for the RTP stream.
People have reported issues with Polycom phones where the TLS thread crashes when the SDP is overloaded.
http://community.polycom.com/t5/VoIP/IP550-Loses-Registration-as-soon-as-I-try-to-make-a-call/td-p/21372
This is not just a Polycom issue, and doesn’t seem to be happening with other SIP servers.
Many times, because the client doesn’t get a response, it sends the packets over and over and eventually times out.
I doubt that the same SIP stack is used across Polycom, Yealink, Counterpath Bria, Blink Pro, etc… I will put together a PCAP of the session in TCP since I can’t share the private key of the SSL certificate.
Is someone willing to provide me with a SIP account where I can test TLS connections with SRTP enabled? An Echo test is enough.

Thanks
Quote:
On Mar 10, 2016, at 8:42 PM, Ken Rice <krice@freeswitch.org (krice@freeswitch.org)> wrote:

Are you sure you are sending this over TCP/TLS? This sounds like its
really using UDP... TCP automatically does packet reassembly, UDP does
not. The behavior you described sounds suspiciously like you are using
UDP instead of TCP/TLS

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)
[mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of
Emrah
Sent: Thursday, March 10, 2016 1:37 PM
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)>
Subject: [Freeswitch-users] SSL implementation in FreeSWITCH

Hi all,
I’m writing to document where I’m at with my issues with FreeSWITCH and SSL / TLS and share my conclusions so far.
I am hoping that this can give lieu to some further testing in different environments, and a proper fix if a bug is indeed confirmed.

First, I am running FreeSWITCH 1.6.6 on a Debian 8. Vars.xml shows sip_tls_version=tlsv1,tlsv1.1,tlsv1.2.

What I’ve observed is that in a sequence where client sens an invite to FS; FS responds with 407 proxy authorization required; client sends ack;  Client sends the invite with the digest auth.

The last packet can easily exceed the max segment size of a TCP segment, typically if the SDP advertises a bunch of codecs, or if the client uses SRTP and the SAVP contains many crypto suites.

Now, when this occurs, the packets should be sent fragmented so they can fit in the MTU. It is then up to the receiving end to reassemble the segments and feed the complete packet to the application layer.

What I’ve noticed is that a packet that is too large is simply never received by FreeSWITCH. Since this is systematically the case with every software and hardware client I’ve used, I am drawn to think that the issue lies in the SSL implementation of FreeSWITCH.

In the event that for some reason my network or server OS configuration may be behind this, I would appreciate if someone would be willing to share some SIP credentials that can let me test TLS and SRTP. If getting to the bottom of this is of interest to any of you, I’d obviously be keen on handing out a couple of accounts.

I hope this message can be the starting point of a fruitful resolution process.

Thank you if you’ve read this up to here. Now hit reply and give me
your 2 cents! Smile

Best,
Emrah
______________________________________________________________________


Quote:
___ Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org (consulting@freeswitch.org)
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use
rs
http://www.freeswitch.org


______________________________________________________________________
___ Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org (consulting@freeswitch.org)
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use
rs
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org (consulting@freeswitch.org)
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org (consulting@freeswitch.org)
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org





--

Brian West
brian@freeswitch.org (brian@freeswitch.org)


Twitter: @FreeSWITCH , @briankwest
http://www.freeswitchbook.com
http://www.freeswitchcookbook.com
https://www.gofundme.com/freeswitch_ubuntu
Got Bugs? Report them here! | Reddit: /r/freeswitch
T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378)
iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest
Back to top
lists at kavun.ch
Guest





PostPosted: Sun Mar 13, 2016 2:00 pm    Post subject: [Freeswitch-users] SSL implementation in FreeSWITCH Reply with quote

Hi!The server isn’t behind NAT, and I don’t know the make and model of all the routers that the affected clients use. And this problem also occurs when there isn’t NAT involved at all.

I will see to open a bug.

Best,
Emrah
Quote:
On Mar 11, 2016, at 11:12 PM, Brian West <brian@freeswitch.org (brian@freeswitch.org)> wrote:
What kind of router is doing your nat?
Smells like someone needs 'ip virtual-reassembly'

On Fri, Mar 11, 2016 at 4:09 PM, Ken Rice <krice@freeswitch.org (krice@freeswitch.org)> wrote:
Quote:
The particular message on the polycom boards only References FreeSWITCH 1.2... there have been significant changes from that point... without getting decoded packet captures theres really not much to see here. TCP handles the packet fragmentation as should TLS... this is transport protocol later stuff... this is not something FreeSWITCH would really be involved in at that point... The other thing that might prove useful is isolating this on an idle machine, with 1 phone enabling all the good SIP and libsofia debugging and getting it into a long along with the logs from the client so it can be compared to see whats going on... Further discussion of this should be taken to jira so that it can be tracked and captures and logging can be attached to the ticket -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of Emrah Sent: Friday, March 11, 2016 3:57 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)> Subject: Re: [Freeswitch-users] SSL implementation in FreeSWITCH Hi there, I am using TLS over TCP for sure. I spent a significant amount of time inspecting this and UDP is only used for the RTP stream. People have reported issues with Polycom phones where the TLS thread crashes when the SDP is overloaded. krice@freeswitch.org (krice@freeswitch.org)> wrote: > > Are you sure you are sending this over TCP/TLS? This sounds like its > really using UDP... TCP automatically does packet reassembly, UDP does > not. The behavior you described sounds suspiciously like you are using > UDP instead of TCP/TLS > > -----Original Message----- > From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) > [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of > Emrah > Sent: Thursday, March 10, 2016 1:37 PM > To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)> > Subject: [Freeswitch-users] SSL implementation in FreeSWITCH > > Hi all, > I’m writing to document where I’m at with my issues with FreeSWITCH and SSL / TLS and share my conclusions so far. > I am hoping that this can give lieu to some further testing in different environments, and a proper fix if a bug is indeed confirmed. > > First, I am running FreeSWITCH 1.6.6 on a Debian 8. Vars.xml shows sip_tls_version=tlsv1,tlsv1.1,tlsv1.2. > > What I’ve observed is that in a sequence where client sens an invite to FS; FS responds with 407 proxy authorization required; client sends ack; Client sends the invite with the digest auth. > > The last packet can easily exceed the max segment size of a TCP segment, typically if the SDP advertises a bunch of codecs, or if the client uses SRTP and the SAVP contains many crypto suites. > > Now, when this occurs, the packets should be sent fragmented so they can fit in the MTU. It is then up to the receiving end to reassemble the segments and feed the complete packet to the application layer. > > What I’ve noticed is that a packet that is too large is simply never received by FreeSWITCH. Since this is systematically the case with every software and hardware client I’ve used, I am drawn to think that the issue lies in the SSL implementation of FreeSWITCH. > > In the event that for some reason my network or server OS configuration may be behind this, I would appreciate if someone would be willing to share some SIP credentials that can let me test TLS and SRTP. If getting to the bottom of this is of interest to any of you, I’d obviously be keen on handing out a couple of accounts. > > I hope this message can be the starting point of a fruitful resolution process. > > Thank you if you’ve read this up to here. Now hit reply and give me > your 2 cents! Smile > > Best, > Emrah > ______________________________________________________________________

Quote:
___ Professional FreeSWITCH Consulting Services: > consulting@freeswitch.org (consulting@freeswitch.org) > FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org) > consulting@freeswitch.org (consulting@freeswitch.org) > FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org) > consulting@freeswitch.org (consulting@freeswitch.org) FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org) consulting@freeswitch.org (consulting@freeswitch.org) FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org) http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org



--
Brian Westbrian@freeswitch.org (brian@freeswitch.org)

Twitter: @FreeSWITCH , @briankwesthttp://www.freeswitchbook.comhttp://www.freeswitchcookbook.comhttps://www.gofundme.com/freeswitch_ubuntu
Got Bugs? Report them here! | Reddit: /r/freeswitch
T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378)iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest












_________________________________________________________________________Professional FreeSWITCH Consulting Services: consulting@freeswitch.org (consulting@freeswitch.org)http://www.freeswitchsolutions.comOfficial FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon.comFreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-usersUNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
Back to top
ssinyagin at gmail.com
Guest





PostPosted: Sun Mar 13, 2016 2:02 pm    Post subject: [Freeswitch-users] SSL implementation in FreeSWITCH Reply with quote

Let's try reproducing it in a lab and let freeswitch developers access it if we're able to reproduce the issue. I can help and also provide some hosts for it.


On Sun, Mar 13, 2016 at 7:58 PM, Emrah <lists@kavun.ch (lists@kavun.ch)> wrote:
Quote:
Hi!The server isn’t behind NAT, and I don’t know the make and model of all the routers that the affected clients use. And this problem also occurs when there isn’t NAT involved at all.


I will see to open a bug.


Best,
Emrah
Quote:
On Mar 11, 2016, at 11:12 PM, Brian West <brian@freeswitch.org (brian@freeswitch.org)> wrote:

What kind of router is doing your nat?  

Smells like someone needs 'ip virtual-reassembly'


On Fri, Mar 11, 2016 at 4:09 PM, Ken Rice <krice@freeswitch.org (krice@freeswitch.org)> wrote:
Quote:
The particular message on the polycom boards only References FreeSWITCH 1.2... there have been significant changes from that point... without getting decoded packet captures theres really not much to see here.

TCP handles the packet fragmentation as should TLS... this is transport protocol later stuff... this is not something FreeSWITCH would really be involved in at that point...

The other thing that might prove useful is isolating this on an idle machine, with 1 phone enabling all the good SIP and libsofia debugging and getting it into a long along with the logs from the client so it can be compared to see whats going on...

Further discussion of this should be taken to jira so that it can be tracked and captures and logging can be attached to the ticket

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of Emrah
Sent: Friday, March 11, 2016 3:57 PM
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)>
Subject: Re: [Freeswitch-users] SSL implementation in FreeSWITCH

Hi there,
I am using TLS over TCP for sure. I spent a significant amount of time inspecting this and UDP is only used for the RTP stream.
People have reported issues with Polycom phones where the TLS thread crashes when the SDP is overloaded.
http://community.polycom.com/t5/VoIP/IP550-Loses-Registration-as-soon-as-I-try-to-make-a-call/td-p/21372
This is not just a Polycom issue, and doesn’t seem to be happening with other SIP servers.
Many times, because the client doesn’t get a response, it sends the packets over and over and eventually times out.
I doubt that the same SIP stack is used across Polycom, Yealink, Counterpath Bria, Blink Pro, etc… I will put together a PCAP of the session in TCP since I can’t share the private key of the SSL certificate.
Is someone willing to provide me with a SIP account where I can test TLS connections with SRTP enabled? An Echo test is enough.

Thanks
Quote:
On Mar 10, 2016, at 8:42 PM, Ken Rice <krice@freeswitch.org (krice@freeswitch.org)> wrote:

Are you sure you are sending this over TCP/TLS? This sounds like its
really using UDP... TCP automatically does packet reassembly, UDP does
not. The behavior you described sounds suspiciously like you are using
UDP instead of TCP/TLS

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)
[mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of
Emrah
Sent: Thursday, March 10, 2016 1:37 PM
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)>
Subject: [Freeswitch-users] SSL implementation in FreeSWITCH

Hi all,
I’m writing to document where I’m at with my issues with FreeSWITCH and SSL / TLS and share my conclusions so far.
I am hoping that this can give lieu to some further testing in different environments, and a proper fix if a bug is indeed confirmed.

First, I am running FreeSWITCH 1.6.6 on a Debian 8. Vars.xml shows sip_tls_version=tlsv1,tlsv1.1,tlsv1.2.

What I’ve observed is that in a sequence where client sens an invite to FS; FS responds with 407 proxy authorization required; client sends ack;  Client sends the invite with the digest auth.

The last packet can easily exceed the max segment size of a TCP segment, typically if the SDP advertises a bunch of codecs, or if the client uses SRTP and the SAVP contains many crypto suites.

Now, when this occurs, the packets should be sent fragmented so they can fit in the MTU. It is then up to the receiving end to reassemble the segments and feed the complete packet to the application layer.

What I’ve noticed is that a packet that is too large is simply never received by FreeSWITCH. Since this is systematically the case with every software and hardware client I’ve used, I am drawn to think that the issue lies in the SSL implementation of FreeSWITCH.

In the event that for some reason my network or server OS configuration may be behind this, I would appreciate if someone would be willing to share some SIP credentials that can let me test TLS and SRTP. If getting to the bottom of this is of interest to any of you, I’d obviously be keen on handing out a couple of accounts.

I hope this message can be the starting point of a fruitful resolution process.

Thank you if you’ve read this up to here. Now hit reply and give me
your 2 cents! Smile

Best,
Emrah
______________________________________________________________________


Quote:
___ Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org (consulting@freeswitch.org)
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use
rs
http://www.freeswitch.org


______________________________________________________________________
___ Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org (consulting@freeswitch.org)
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use
rs
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org (consulting@freeswitch.org)
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org (consulting@freeswitch.org)
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org





--

Brian West
brian@freeswitch.org (brian@freeswitch.org)


Twitter: @FreeSWITCH , @briankwest
http://www.freeswitchbook.com
http://www.freeswitchcookbook.com
https://www.gofundme.com/freeswitch_ubuntu
Got Bugs? Report them here! | Reddit: /r/freeswitch
T:[url=tel:%2B19184209001]+19184209001[/url] | F:[url=tel:%2B19184209002]+19184209002[/url] | M:+1918424WEST (9378)
iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest












_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org (consulting@freeswitch.org)
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org







_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org (consulting@freeswitch.org)
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Back to top
lists at kavun.ch
Guest





PostPosted: Sun Mar 13, 2016 3:26 pm    Post subject: [Freeswitch-users] SSL implementation in FreeSWITCH Reply with quote

Scratch that, I need to confirm that this issue occurs when there is no NAT involved.
I’ll post here what happens.

Stan, I like your idea very much.
On Mar 13, 2016, at 7:58 PM, Emrah <lists@kavun.ch (lists@kavun.ch)> wrote:
Quote:
Hi!The server isn’t behind NAT, and I don’t know the make and model of all the routers that the affected clients use. And this problem also occurs when there isn’t NAT involved at all.

I will see to open a bug.

Best,
Emrah
Quote:
On Mar 11, 2016, at 11:12 PM, Brian West <brian@freeswitch.org (brian@freeswitch.org)> wrote:
What kind of router is doing your nat?
Smells like someone needs 'ip virtual-reassembly'

On Fri, Mar 11, 2016 at 4:09 PM, Ken Rice <krice@freeswitch.org (krice@freeswitch.org)> wrote:
Quote:
The particular message on the polycom boards only References FreeSWITCH 1.2... there have been significant changes from that point... without getting decoded packet captures theres really not much to see here. TCP handles the packet fragmentation as should TLS... this is transport protocol later stuff... this is not something FreeSWITCH would really be involved in at that point... The other thing that might prove useful is isolating this on an idle machine, with 1 phone enabling all the good SIP and libsofia debugging and getting it into a long along with the logs from the client so it can be compared to see whats going on... Further discussion of this should be taken to jira so that it can be tracked and captures and logging can be attached to the ticket -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of Emrah Sent: Friday, March 11, 2016 3:57 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)> Subject: Re: [Freeswitch-users] SSL implementation in FreeSWITCH Hi there, I am using TLS over TCP for sure. I spent a significant amount of time inspecting this and UDP is only used for the RTP stream. People have reported issues with Polycom phones where the TLS thread crashes when the SDP is overloaded. krice@freeswitch.org (krice@freeswitch.org)> wrote: > > Are you sure you are sending this over TCP/TLS? This sounds like its > really using UDP... TCP automatically does packet reassembly, UDP does > not. The behavior you described sounds suspiciously like you are using > UDP instead of TCP/TLS > > -----Original Message----- > From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) > [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of > Emrah > Sent: Thursday, March 10, 2016 1:37 PM > To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)> > Subject: [Freeswitch-users] SSL implementation in FreeSWITCH > > Hi all, > I’m writing to document where I’m at with my issues with FreeSWITCH and SSL / TLS and share my conclusions so far. > I am hoping that this can give lieu to some further testing in different environments, and a proper fix if a bug is indeed confirmed. > > First, I am running FreeSWITCH 1.6.6 on a Debian 8. Vars.xml shows sip_tls_version=tlsv1,tlsv1.1,tlsv1.2. > > What I’ve observed is that in a sequence where client sens an invite to FS; FS responds with 407 proxy authorization required; client sends ack; Client sends the invite with the digest auth. > > The last packet can easily exceed the max segment size of a TCP segment, typically if the SDP advertises a bunch of codecs, or if the client uses SRTP and the SAVP contains many crypto suites. > > Now, when this occurs, the packets should be sent fragmented so they can fit in the MTU. It is then up to the receiving end to reassemble the segments and feed the complete packet to the application layer. > > What I’ve noticed is that a packet that is too large is simply never received by FreeSWITCH. Since this is systematically the case with every software and hardware client I’ve used, I am drawn to think that the issue lies in the SSL implementation of FreeSWITCH. > > In the event that for some reason my network or server OS configuration may be behind this, I would appreciate if someone would be willing to share some SIP credentials that can let me test TLS and SRTP. If getting to the bottom of this is of interest to any of you, I’d obviously be keen on handing out a couple of accounts. > > I hope this message can be the starting point of a fruitful resolution process. > > Thank you if you’ve read this up to here. Now hit reply and give me > your 2 cents! Smile > > Best, > Emrah > ______________________________________________________________________

Quote:
___ Professional FreeSWITCH Consulting Services: > consulting@freeswitch.org (consulting@freeswitch.org) > FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org) > consulting@freeswitch.org (consulting@freeswitch.org) > FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org) > consulting@freeswitch.org (consulting@freeswitch.org) FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org) consulting@freeswitch.org (consulting@freeswitch.org) FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org) http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org



--
Brian Westbrian@freeswitch.org (brian@freeswitch.org)

Twitter: @FreeSWITCH , @briankwesthttp://www.freeswitchbook.comhttp://www.freeswitchcookbook.comhttps://www.gofundme.com/freeswitch_ubuntu
Got Bugs? Report them here! | Reddit: /r/freeswitch
T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378)iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest












_________________________________________________________________________Professional FreeSWITCH Consulting Services: consulting@freeswitch.org (consulting@freeswitch.org)http://www.freeswitchsolutions.comOfficial FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon.comFreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-usersUNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org




Back to top
lists at kavun.ch
Guest





PostPosted: Wed Mar 16, 2016 6:34 am    Post subject: [Freeswitch-users] SSL implementation in FreeSWITCH Reply with quote

Digging into my Yealink logs, I just wanted to show one interesting line that occurs right before the phone goes crazy on the TLS session.Mar 16 11:10:56 sua [574]: DLG <5+notice> [002] Message sent: (to dest=123.123.123.123:5061 len=1466)
My little finger tells me the len=1466 is the size of the TLS record, or of its content, and it’s trying to squeeze it into one TCP segment.

I am just not sure what to do of this. Because it doesn’t seem to be a constant. I’ve had success with large packets I’m sure, but can’t say for sure in what network condition.

All I know for certain is that I have multiple phones and softphones in different network topologies. that when TLS and SRTP are used, calls randomly fail. If TCP is used with SRTP, it works fine. If TLS without SRTP is used, it also works consistently.

Emrah

Quote:
On Mar 13, 2016, at 9:24 PM, Emrah <lists@kavun.ch (lists@kavun.ch)> wrote:
Scratch that, I need to confirm that this issue occurs when there is no NAT involved.
I’ll post here what happens.

Stan, I like your idea very much.
On Mar 13, 2016, at 7:58 PM, Emrah <lists@kavun.ch (lists@kavun.ch)> wrote:
Quote:
Hi!The server isn’t behind NAT, and I don’t know the make and model of all the routers that the affected clients use. And this problem also occurs when there isn’t NAT involved at all.

I will see to open a bug.

Best,
Emrah
Quote:
On Mar 11, 2016, at 11:12 PM, Brian West <brian@freeswitch.org (brian@freeswitch.org)> wrote:
What kind of router is doing your nat?
Smells like someone needs 'ip virtual-reassembly'

On Fri, Mar 11, 2016 at 4:09 PM, Ken Rice <krice@freeswitch.org (krice@freeswitch.org)> wrote:
Quote:
The particular message on the polycom boards only References FreeSWITCH 1.2... there have been significant changes from that point... without getting decoded packet captures theres really not much to see here. TCP handles the packet fragmentation as should TLS... this is transport protocol later stuff... this is not something FreeSWITCH would really be involved in at that point... The other thing that might prove useful is isolating this on an idle machine, with 1 phone enabling all the good SIP and libsofia debugging and getting it into a long along with the logs from the client so it can be compared to see whats going on... Further discussion of this should be taken to jira so that it can be tracked and captures and logging can be attached to the ticket -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of Emrah Sent: Friday, March 11, 2016 3:57 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)> Subject: Re: [Freeswitch-users] SSL implementation in FreeSWITCH Hi there, I am using TLS over TCP for sure. I spent a significant amount of time inspecting this and UDP is only used for the RTP stream. People have reported issues with Polycom phones where the TLS thread crashes when the SDP is overloaded. krice@freeswitch.org (krice@freeswitch.org)> wrote: > > Are you sure you are sending this over TCP/TLS? This sounds like its > really using UDP... TCP automatically does packet reassembly, UDP does > not. The behavior you described sounds suspiciously like you are using > UDP instead of TCP/TLS > > -----Original Message----- > From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) > [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of > Emrah > Sent: Thursday, March 10, 2016 1:37 PM > To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)> > Subject: [Freeswitch-users] SSL implementation in FreeSWITCH > > Hi all, > I’m writing to document where I’m at with my issues with FreeSWITCH and SSL / TLS and share my conclusions so far. > I am hoping that this can give lieu to some further testing in different environments, and a proper fix if a bug is indeed confirmed. > > First, I am running FreeSWITCH 1.6.6 on a Debian 8. Vars.xml shows sip_tls_version=tlsv1,tlsv1.1,tlsv1.2. > > What I’ve observed is that in a sequence where client sens an invite to FS; FS responds with 407 proxy authorization required; client sends ack; Client sends the invite with the digest auth. > > The last packet can easily exceed the max segment size of a TCP segment, typically if the SDP advertises a bunch of codecs, or if the client uses SRTP and the SAVP contains many crypto suites. > > Now, when this occurs, the packets should be sent fragmented so they can fit in the MTU. It is then up to the receiving end to reassemble the segments and feed the complete packet to the application layer. > > What I’ve noticed is that a packet that is too large is simply never received by FreeSWITCH. Since this is systematically the case with every software and hardware client I’ve used, I am drawn to think that the issue lies in the SSL implementation of FreeSWITCH. > > In the event that for some reason my network or server OS configuration may be behind this, I would appreciate if someone would be willing to share some SIP credentials that can let me test TLS and SRTP. If getting to the bottom of this is of interest to any of you, I’d obviously be keen on handing out a couple of accounts. > > I hope this message can be the starting point of a fruitful resolution process. > > Thank you if you’ve read this up to here. Now hit reply and give me > your 2 cents! Smile > > Best, > Emrah > ______________________________________________________________________

Quote:
___ Professional FreeSWITCH Consulting Services: > consulting@freeswitch.org (consulting@freeswitch.org) > FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org) > consulting@freeswitch.org (consulting@freeswitch.org) > FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org) > consulting@freeswitch.org (consulting@freeswitch.org) FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org) consulting@freeswitch.org (consulting@freeswitch.org) FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org) http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org



--
Brian Westbrian@freeswitch.org (brian@freeswitch.org)

Twitter: @FreeSWITCH , @briankwesthttp://www.freeswitchbook.comhttp://www.freeswitchcookbook.comhttps://www.gofundme.com/freeswitch_ubuntu
Got Bugs? Report them here! | Reddit: /r/freeswitch
T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378)iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest












_________________________________________________________________________Professional FreeSWITCH Consulting Services: consulting@freeswitch.org (consulting@freeswitch.org)http://www.freeswitchsolutions.comOfficial FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon.comFreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-usersUNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org








Back to top
Display posts from previous:   
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group

VoiceMeUp - Corporate & Wholesale VoIP Services