Hi, Yes, this is a known issue and it has now been mitigated in git.
Please note that, it doesn't prevent you from using TLS with sflphone 1.4.1 as long as it is configured correctly. For your information, we are currently rewriting most of our security code after the switch away from ccrtp (see previous mail) and while not all features are implemented yet, some parts, like this one, is already in much better shape. We are still doing heavy refactoring to fix multiple longstanding issues related to SRTP and transports in general. SFLPhone 1.4.1 was the pinnacle of an era for us. We have reached an inflexion point where we had to do absolutely major work if we wanted to continue to advance our product. This is one of the issue, among other. Using TLS with the git version probably wont work, as some components are work in progress. The pjproject cipher buffer is problematic. One mitigation technique we had was to set a shorter chain in the config, but I think is was broken in 1.4.1. Regards, Emmanuel ----- Original Message ----- From: "Gerald Turner" <[email protected]> To: [email protected] Sent: Friday, February 6, 2015 7:08:14 PM Subject: [SFLphone] TLS unusable with 1.4.1 and OpenSSL 1.0.1k Hi, I'm trying to enable TLS with SFLphone using the Debian jessie 1.4.1-0.1 packages and the daemon aborts with the following assertions: sipaccount.cpp:1059:0xc9c0: Using 46 ciphers ... sipaccount.cpp:898:0xc9c0: SIPAccount::registerVoIPLink managerimpl.cpp:236:0xc9c0: Starting client event loop sflphoned: ../src/pj/ssl_sock_ossl.c:703: set_cipher_list: Assertion `!"Insufficient temporary buffer for cipher"' failed. Looks like ssl_sock_ossl.c has 1024 byte buffer for building the list of ciphers. I patched the source to increase the buffer size and print the ciphers_list, and on my system it needs 1033 bytes: 10:51:39.231 ssl0x237c5a0 cipher_list=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-GCM-SHA384:ADH-AES256-SHA256:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DHE-DSS-A ES128-GC M-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256 I've tried setting the 'ciphers' configuration parameter to something like "ECDHE-ECDSA-AES256-SHA", but this parameter seems ineffective, no matter what, "Using 46 ciphers" is printed and the assertion is triggered. -- Gerald Turner <[email protected]> Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D _______________________________________________ SFLphone mailing list [email protected] http://lists.savoirfairelinux.net/mailman/listinfo/sflphone _______________________________________________ SFLphone mailing list [email protected] http://lists.savoirfairelinux.net/mailman/listinfo/sflphone
