Hello there, hope someone else also had the problem - and found a solution for it. My "internal" profile has TLS enabled with tlsv1, 1.1 and 1.2 - this worked like a charm on stretch. I'm using the freeswitch-repos. I upgraded to buster and here my problems started. Seems the gentls_cert only creates SHA1 (CA)Certificates - so freeswitch started with openssl error messages "md too weak". Tried at first to bypass this error by setting the tls_ciphers to "DEFAULT:@SECLEVEL=0" but this error still occured. So as a consequence, I modified the gentls_cert script and replaced everywhere the parameter -sha1 with -sha256. This error disappeared now, but the next one is coming up. It seems it does not matter which value I set for "tls_version" - in every case, my TLS enabled port only accepts TLS 1.3 connections. I have the problem that we're also using older phones which only support TLS 1.0. Error message is: tport_tls.c:157 tls_log_errors() TLS setup failed: 14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol I tried with openssl s_client and the parameters -tls1 -tls1_1 and so on - it really only worked for -tls1_3 Any idea about this? setting tls_version to tlsv1,tlsv1.1,tlsv1.2 does not change anything. Also setting the value just to tlsv1 does not help, I verified this with the phones AND with openssl s_client. Still only TLS 1.3 gives results here. Thanks in advance... BR Walter
On Mon, Nov 11, 2019 at 11:21:05PM +0100, Walter Behrend wrote:
Hello there,
Hi Walter,
I upgraded to buster and here my problems started. Seems the gentls_cert only creates SHA1 (CA)Certificates - so freeswitch started with openssl error messages "md too weak". Tried at first to bypass this error by setting the tls_ciphers to "DEFAULT:@SECLEVEL=0" but this error still occured.
I don't have Debian, I got OpenWrt with openssl 1.1.1d and FS 1.10.1. Updated /etc/ssl/openssl.cnf like this: https://sources.debian.org/src/openssl/1.1.1c-1/debian/patches/Set-systemwid... I also used gentls_cert to create CA & server cert. But I don't get "md too weak" when starting FS.
So as a consequence, I modified the gentls_cert script and replaced everywhere the parameter -sha1 with -sha256. This error disappeared now, but the next one is coming up.
It seems it does not matter which value I set for "tls_version" - in every case, my TLS enabled port only accepts TLS 1.3 connections. I have the problem that we're also using older phones which only support TLS 1.0.
Error message is:
tport_tls.c:157 tls_log_errors() TLS setup failed: 14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol
Works fine here: 4 0.004770 192.168.0.120 → 192.168.0.1 TLSv1 464 Client Hello 6 0.193706 192.168.0.1 → 192.168.0.120 TLSv1.2 1514 Server Hello 7 0.193809 192.168.0.1 → 192.168.0.120 TLSv1.2 871 Certificate, Server Key Exchange, Server Hello Done 10 0.256056 192.168.0.120 → 192.168.0.1 TLSv1.2 141 Client Key Exchange 12 0.269076 192.168.0.120 → 192.168.0.1 TLSv1.2 72 Change Cipher Spec 14 0.269344 192.168.0.120 → 192.168.0.1 TLSv1.2 103 Encrypted Handshake Message With openssl s_client I can also connect with TLS1.0, 1.1, 1.2 and 1.3 (which suggests that FS isn't using system openssl config).
Any idea about this? setting tls_version to tlsv1,tlsv1.1,tlsv1.2 does not change anything. Also setting the value just to tlsv1 does not help, I verified this with the phones AND with openssl s_client. Still only TLS 1.3 gives results here.
The only way to reproduce your result was to set tls-version to tls1_3. When you grep your FS log for tls-version, do you see "tlsv1,tlsv1.1,tlsv1.2" or "tlsv1_3"? Regards, Seb
On Tue, Nov 12, 2019 at 09:27:16PM +0100, Sebastian Kemper wrote:
On Mon, Nov 11, 2019 at 11:21:05PM +0100, Walter Behrend wrote:
It seems it does not matter which value I set for "tls_version" - in every case, my TLS enabled port only accepts TLS 1.3 connections. I have the problem that we're also using older phones which only support TLS 1.0.
Error message is:
tport_tls.c:157 tls_log_errors() TLS setup failed: 14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol
Works fine here:
4 0.004770 192.168.0.120 → 192.168.0.1 TLSv1 464 Client Hello 6 0.193706 192.168.0.1 → 192.168.0.120 TLSv1.2 1514 Server Hello 7 0.193809 192.168.0.1 → 192.168.0.120 TLSv1.2 871 Certificate, Server Key Exchange, Server Hello Done 10 0.256056 192.168.0.120 → 192.168.0.1 TLSv1.2 141 Client Key Exchange 12 0.269076 192.168.0.120 → 192.168.0.1 TLSv1.2 72 Change Cipher Spec 14 0.269344 192.168.0.120 → 192.168.0.1 TLSv1.2 103 Encrypted Handshake Message
With openssl s_client I can also connect with TLS1.0, 1.1, 1.2 and 1.3 (which suggests that FS isn't using system openssl config).
Actually it doesn't work fine here after all. I had updated /etc/ssl/openssl.cnf with the Debian changes, but actually openssl_conf = default_conf was overwritten by some OpenWrt config snippet later. I amended that and now when I set tls_version to something specific I get 4 0.010062 192.168.0.120 → 192.168.0.1 TLSv1 464 Client Hello 6 0.010927 192.168.0.1 → 192.168.0.120 TLSv1.2 73 Alert (Level: Fatal, Description: Protocol Version) and when I leave it unset I get 4 0.009440 192.168.0.120 → 192.168.0.1 TLSv1 464 Client Hello 6 0.010884 192.168.0.1 → 192.168.0.120 TLSv1.2 73 Alert (Level: Fatal, Description: Handshake Failure) Regards, Seb
Btw, I think there is a problem in freeswitch - if for example I configure stunnel, there is no problem with specifying accepting also older TLS standards without the need of changing the MinProtocol setting within the openssl.cnf file. As a user or admin, I would normally expect the tls-version parameter to do the same job for me... Cheers, Walter On Tue, Nov 12, 2019 at 09:27:16PM +0100, Sebastian Kemper wrote:
On Mon, Nov 11, 2019 at 11:21:05PM +0100, Walter Behrend wrote:
It seems it does not matter which value I set for "tls_version" - in every case, my TLS enabled port only accepts TLS 1.3 connections. I have the problem that we're also using older phones which only support TLS 1.0.
Error message is:
tport_tls.c:157 tls_log_errors() TLS setup failed: 14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol
Works fine here:
4 0.004770 192.168.0.120 → 192.168.0.1 TLSv1 464 Client Hello 6 0.193706 192.168.0.1 → 192.168.0.120 TLSv1.2 1514 Server Hello 7 0.193809 192.168.0.1 → 192.168.0.120 TLSv1.2 871 Certificate, Server Key Exchange, Server Hello Done 10 0.256056 192.168.0.120 → 192.168.0.1 TLSv1.2 141 Client Key Exchange 12 0.269076 192.168.0.120 → 192.168.0.1 TLSv1.2 72 Change Cipher Spec 14 0.269344 192.168.0.120 → 192.168.0.1 TLSv1.2 103 Encrypted Handshake Message
With openssl s_client I can also connect with TLS1.0, 1.1, 1.2 and 1.3 (which suggests that FS isn't using system openssl config).
Actually it doesn't work fine here after all. I had updated /etc/ssl/openssl.cnf with the Debian changes, but actually openssl_conf = default_conf was overwritten by some OpenWrt config snippet later. I amended that and now when I set tls_version to something specific I get 4 0.010062 192.168.0.120 → 192.168.0.1 TLSv1 464 Client Hello 6 0.010927 192.168.0.1 → 192.168.0.120 TLSv1.2 73 Alert (Level: Fatal, Description: Protocol Version) and when I leave it unset I get 4 0.009440 192.168.0.120 → 192.168.0.1 TLSv1 464 Client Hello 6 0.010884 192.168.0.1 → 192.168.0.120 TLSv1.2 73 Alert (Level: Fatal, Description: Handshake Failure) Regards, Seb
On Tue, Nov 12, 2019 at 10:38:40PM +0100, Walter Behrend wrote:
Btw, I think there is a problem in freeswitch - if for example I configure stunnel, there is no problem with specifying accepting also older TLS standards without the need of changing the MinProtocol setting within the openssl.cnf file. As a user or admin, I would normally expect the tls-version parameter to do the same job for me...
Hi Walter, I guess that's a point of view. I was quite happy to find that OpenSSL enforces the restrictions set in /etc/ssl/openssl.cnf also when used through FreeSWITCH. I'd find it rather strange if it didn't, honestly. If they're the default settings then they have to be enforced whenever OpenSSL is used, in my opinion. I've tested with an updated message digest in gentls_cert (SHA256 like you suggested) and can confirm it's working properly with this. I've sent a pull request via GitHub to FS. Regards, Seb
Hello, We have a need to set presence_id to an extension different than the one being dialed. We do this in the dial-string of the dialed extension: Say dialed_user is 3005, we set presence_id to be for 3001 with this dial-string: {presence_id=3001@${dialed_domain}}${sofia_contact(${dialed_user}@${dialed_domain})} When 3005 is dialed, 3001's presence indicator on the phones (in this case Yealink) does indeed behave correctly, that is until an answered call is hung up - in that case the presence is not cleared and the BLF subscription for 3001@domain remains lit up. Anyone seen this behavior before? Is there a better way to set a custom presence_id for extensions? This was tested on FS 1.6.20 as well as latest master just now. Thank you, Mike
Answering my own question -- oops, I overlooked the presence_id directory variable. Setting that to 3001@domain for the 3005 user directory resolved the issue. Mike On Wed, Nov 13, 2019, at 9:31 PM, Michael Avers wrote:
Hello,
We have a need to set presence_id to an extension different than the one being dialed. We do this in the dial-string of the dialed extension:
Say dialed_user is 3005, we set presence_id to be for 3001 with this dial-string:
{presence_id=3001@${dialed_domain}}${sofia_contact(${dialed_user}@${dialed_domain})}
When 3005 is dialed, 3001's presence indicator on the phones (in this case Yealink) does indeed behave correctly, that is until an answered call is hung up - in that case the presence is not cleared and the BLF subscription for 3001@domain remains lit up.
Anyone seen this behavior before? Is there a better way to set a custom presence_id for extensions?
This was tested on FS 1.6.20 as well as latest master just now.
Thank you, Mike _________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 https://freeswitch.com
Old thread, but in case it helps anyone. For SessionTalk + FreeSwitch, you need to set openssl.cnf params rock bottom low: [system_default_sect] MinProtocol = TLSv1 CipherString = DEFAULT@SECLEVEL=1 I've followed-up with SessionTalk support to check on TLS V1.2 and stronger cipher suite. However my hopes are low since they haven't though of it on their own. App store feedback pending... On 2019-11-13 3:01 p.m., Sebastian Kemper wrote:
On Tue, Nov 12, 2019 at 10:38:40PM +0100, Walter Behrend wrote:
Btw, I think there is a problem in freeswitch - if for example I configure stunnel, there is no problem with specifying accepting also older TLS standards without the need of changing the MinProtocol setting within the openssl.cnf file. As a user or admin, I would normally expect the tls-version parameter to do the same job for me... Hi Walter,
I guess that's a point of view. I was quite happy to find that OpenSSL enforces the restrictions set in /etc/ssl/openssl.cnf also when used through FreeSWITCH. I'd find it rather strange if it didn't, honestly. If they're the default settings then they have to be enforced whenever OpenSSL is used, in my opinion.
I've tested with an updated message digest in gentls_cert (SHA256 like you suggested) and can confirm it's working properly with this. I've sent a pull request via GitHub to FS.
Regards, Seb
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 https://freeswitch.com
participants (4)
-
Michael Avers
-
Sebastian Kemper
-
Victor Chukalovskiy
-
Walter Behrend