| Summary: | ASTERISK-29416: Client Hello sent as TLSv1.3 | ||||
| Reporter: | Morten Sølvberg (Soelvberg) | Labels: | |||
| Date Opened: | 2021-05-07 08:28:30 | Date Closed: | 2021-05-10 10:50:18 | ||
| Priority: | Minor | Regression? | |||
| Status: | Closed/Complete | Components: | Channels/chan_pjsip | ||
| Versions: | 18.1.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) 13.18.0.jpg ( 1) 18.0.1.jpg | |||
| Description: | Whenever I establish a TLS connection from Asterisk 18.0.1, then I can in Wireshark see that the "Client Hello" it is sent as TLSv1.3, even though you do not support that version.
The correct version (1.2) is written in the Handshake Protocol section though. The libsrtp module is version 2.2.0-1. On an Asterisk version 13 I use libsrtp version 1.5.4, and on this version, the "Client Hello" is sent as TLSv1.2. Is it an error on your part, on Cisco's part, or is it valid to indicate that "Client Hello" is v. 1.3, when another version is indicated in the Handshake Protocol section? | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2021-05-07 08:28:31.712-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. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: Morten Sølvberg (Soelvberg) 2021-05-07 08:31:39.421-0500 Client Hello from Asterisk 18.0.1 indicating TLSv1.3 By: Morten Sølvberg (Soelvberg) 2021-05-07 08:32:17.989-0500 Client Hello from Asterisk 13.18.0 indicating TLSv1.2 By: Joshua C. Colp (jcolp) 2021-05-07 08:42:07.240-0500 Per the linked issue, if you set "method" on the TLS transport to "tlsv1_2" does this change things? Additionally libsrtp has nothing to do with TLS or DTLS. By: Morten Sølvberg (Soelvberg) 2021-05-07 08:50:05.766-0500 It is already set to tlsv1_2 [transport-tls] type=transport protocol=tls bind=0.0.0.0:5091 tos=cs3 cos=3 allow_reload=true method=tlsv1_2 external_media_address=51.136.41.XXX external_signaling_address=51.136.41.XXX local_net=10.0.0.0/8 local_net=172.16.0.0/12 local_net=192.168.0.0/16 cert_file=/var/lib/asterisk/certs/novus.crt priv_key_file=/var/lib/asterisk/certs/novus.key By: Morten Sølvberg (Soelvberg) 2021-05-07 08:55:58.058-0500 I assume that you still don't support v. 1.3 - correct? By: Joshua C. Colp (jcolp) 2021-05-07 09:02:20.168-0500 TLSv1.3 is not "supported" in PJSIP exactly. It provides no mechanism to disable it or control it, but it's possible that it will be offered and used if possible. Is there a problem you're actually encountering? By: Morten Sølvberg (Soelvberg) 2021-05-07 09:14:20.968-0500 Yes, I am trying to connect to a provider that is using Mitel, and we are having issues with a BYE message that is not being sent to us, when we make an outbound call, and hang it up on the device we called. Mitel supports both v. 1.2 and 1.3, and the Mitel tech's that is investigating the problem believes that it is because we indicate 1.3, but is in fact sending 1.2. I have tried to read the RFC's and I can't find any indication of whether the behavior is allowed or not. By: Morten Sølvberg (Soelvberg) 2021-05-07 09:16:11.888-0500 From the installation using Asterisk 13.18.0 which is indicating 1.2, we do not have this problem. By: Joshua C. Colp (jcolp) 2021-05-07 09:21:35.314-0500 Are you or them seeing the TLS negotiation fail? The TLS connection won't be established if it can't be negotiated, and it will negotiate either at 1.2 or 1.3. If the TLS connection is established then it should be fine for sending and receiving traffic. I should also add that that is all handled by OpenSSL, which can be influenced on the system elsewhere I believe to disable offering 1.3. I don't have experience with that though. By: Morten Sølvberg (Soelvberg) 2021-05-10 10:18:53.490-0500 No the TLS negotiation does not fail, and I agree that the problem must lie somewhere else. I managed to disable TLS 1.3 from openssl.cnf, so we now send 1.2. It did not fix the failing calls - but I very much doubted that it would. I just needed to prove to Mitel that it wasn't the TLS version indication that caused it, so they will continue their search for the culprit. Thank you so much for pointing me in the right direction. | ||||
