| Summary: | ASTERISK-29017: pjsip: As of 2.9 with newer OpenSSL "tlsv1" method is TLSv1.3 only | ||||
| Reporter: | Bernhard Schmidt (bschmidt) | Labels: | |||
| Date Opened: | 2020-07-31 16:55:08 | Date Closed: | |||
| Priority: | Major | Regression? | Yes | ||
| Status: | Open/New | Components: | pjproject/pjsip | ||
| Versions: | 16.10.0 16.12.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Debian Unstable (sid) | Attachments: | |||
| Description: | Originally reported to Debian in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966636 .
After upgrading from Asterisk 16.2.1 to Asterisk 16.10.0 the pjsip TLS listener only accepts TLSv1.3 connections in the default configuration (method= not set or set to "default") {noformat} [transport-tls] type=transport protocol=tls bind=0.0.0.0 cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem priv_key_file=/etc/ssl/private/ssl-cert-snakeoil.key ;cipher=ADH-AES256-SHA,ADH-AES128-SHA ;method=tlsv1 {noformat} {noformat} [Jul 31 21:48:23] WARNING[4288] pjproject: SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <337678594> <SSL routines-tls_early_post_process_client_hello-unsupported protocol> len: 0 peer: 127.0.0.1:49478 }}} {noformat} Workaround is setting {noformat} method=tlsv1_2 {noformat} which appears to accept both TLSv1.2 and TLSv1.3 connections. I have quickly spun up a test package with Asterisk 16.12.0 which shows the same symptoms | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2020-07-31 16:55:09.086-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: Joshua C. Colp (jcolp) 2020-08-03 06:34:28.064-0500 This does not appear to be a recent change. It occurs going from Asterisk 16.4.0 to 16.5.0, which is when PJSIP was upgraded from 2.8 to 2.9. I think there is an interaction in PJSIP between the default "tlsv1" option and OpenSSL where it is becoming TLSv1.3 only. In fact, that version of PJSIP doesn't even have any knowledge of TLSv1.3 in itself. By: Alexander Traud (traud) 2020-10-06 04:10:05.351-0500 TLS 1.3 is allowed because PJSIP does not know about it and does not disable it. Bernhard, you are referencing (and mentioning) a bug related to the latest Debian unstable. I tried to explain all this chaos a bit in [this community post|https://community.asterisk.org/t/85091/10]. Does that help? However, the referenced bug-report states even {{method=sslv23}} does not help. Can you confirm, that only {{method=tlsv1_2}} works and {{method=sslv23}} does not work? Then, I have a look at your scenario. By: Alexander Traud (traud) 2020-10-27 11:55:35.052-0500 [~bschmidt], I tried to reproduce your issue on Debian Bullseye (currently testing) and was not able to do so. In Asterisk, {{method=}} does not have a ‘good’ default. I know, this is in contrast to your previous analysis in ASTERISK-27031. When you leave that out (or empty), all TLS versions are disabled by PJSIP. Because PJSIP does not know how to disable TLS 1.3, yet, it is left enabled. Furthermore, {{method=sslv23}} works here. Going for {{method=tlsv1}} does not set TLS 1.0 as minimum version. Instead it disables all other versions except TLS 1.0. And because TLS 1.0 is disabled on default in Debian Bullseye, you end up with no TLS version (except TLS 1.3 because PJSIP does not disable that). If you need TLS 1.3, TLS 1.2, and TLS 1.0, you go for {{method=sslv23}} and one of those: a) Look at {{Set-systemwide-default-settings-for-libssl-users.patch}} introduced with Debian Bullseye. That means to have to edit the last line of the file {{/etc/ssl/openssl.cnf}} system wide: {{MinProtocol = TLSv1}} b) You do not use the Debian provided package {{asterisk}} but go for your own one with its own {{openssl}}. A step-by-step-guide is in ASTERISK-27908… with that the _minimum_ version is not TLS 1.2 but TLS 1.0. c) You re-phrase your report. I guess, you want a way to control the _minimum_ version from within a configuration file like {{/etc/asterisk/pjsip.conf}}. If I understand the comments in the Asterisk community thread correctly, that would be a not a bug but a feature request. Am I correct? So once again: If you specify a specific version in {{pjsip.conf}}, PJSIP disables all other versions except that one. Because your system has TLS 1.0 disabled already, you end up with no version. Because PJSIP does not know how to disable TLS 1.3, yet, you end up with TLS 1.3-only. I think, the way to go is a {{min_protocol}} which overrides the system value. However, that is something the Usable-Security Engineer of the Asterisk team = of Sangoma has to decide. By: Alexander Traud (traud) 2020-10-27 16:15:27.273-0500 I stand corrected, a bit, the default method ({{method=''}}, {{=default}}, {{=unspecified}}, or not specified at all) is TLS 1.0-only, as explained in [my analysis from Aug 2016|https://github.com/asterisk/asterisk/commit/e55d1e47aa28f7f0477bbbb251bdabaddf640f9a]. | ||||