Chrome Version 124 Update is breaking the DTLS Handshake for WebRTC

[moorecj]

Chrome Version 124 Update is breaking the DTLS Handshake for WebRTC

[SimonJ-DR]

A version bump would be appreciated.

[moorecj]

We found the issue:

Chrome is now checking certificate type and needs to be passed the correct one in Certificate Request, Apparently WebRTC should be using ECDSA.

In DtlsSrtpServer.cs line 251 change the return to this and it will start being accepted by Chrome.
return new CertificateRequest(new byte[] { ClientCertificateType.rsa_sign, ClientCertificateType.ecdsa_sign }, serverSigAlgs, null);

[renanaragao]

I have the latest version of spisorcey (6.2.3.0), but it still gives me the same error

[renanaragao]

From what I checked, the code that is published in nuget does not have the correction made:

Code in main:

[thiggins09]

Yes, after upgrading to the newest BouncyCastle, I can confirm Chrome 123 such as 123.0.6288.0 still works.

I was able to get BouncyCastle to work by downloading BouncyCastle and commenting out this code:

//if (clientCertificateType < 0
// || !Arrays.Contains(certificateRequest.CertificateTypes, clientCertificateType))
//{
// throw new TlsFatalAlert(alertDescription);
//}

[hiagotakaki]

I have the latest version of spisorcey (6.2.3.0), but it still gives me the same error

Me too... We use SIPSorcery as a bridge between the client and the SIP Server (managed RTCPeerConnection + RTPSession in a auto dialer).
We are using Vivaldi Browser while we do not have a new version that includes this functionality, but there are many others that is not based on Chromium and should work.

Thank you guys.

[RWL-Dittrich]

I just cloned and built the project and added that as a dependency. This indeed fixed the problem, so the version on Nuget is confirmed to not have the fix published.

[thiggins09]

I'm able to reproduce this with Chrome 124 but not Chrome 123. Cannot connect in Chrome 124.

[jasonauk]

I am also able to reproduce this issue on 124.0.6367.61. Everything worked as expected on 123.0.6312.123. Microsoft Edge 123.0.2420.97 is also working as expected.

[moorecj]

I used the chromium diff tool and narrowed the the version down some more:

You are probably looking for a change made after 1271606 (known good), but no later than 1271645 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/ddaacfe2b4996abad63c63a265983c6d5ba968c0..d21e8eca4b4a581e1de7640d9dfa4f3b8353c0b6

[jasonauk]

I grabbed a snapshot of Vivaldi to find that the issue occurs with 124.0.6367.35

You can compare via Google's source using versions tags https://chromium.googlesource.com/chromium/src/+log/123.0.6312.123..124.0.6367.35

There are 7 pages of commits

[ChristopheI]

BouncyCastle.Cryptography package is no more here : https://www.nuget.org/packages/Portable.BouncyCastle/
But here: https://www.nuget.org/packages/BouncyCastle.Cryptography/
With a recent version 2.3.0: 2 months ago.
Perhaps using this version will fix the pb

[thiggins09]

Upgraded to newest BouncyCastle, confirmed it works in Firefox after upgrading, but still getting the same behavior.

This appears related as well: https://stackoverflow.com/questions/78273680/webrtc-connection-could-not-be-established-on-chrome-124

[ChristopheI]

Upgraded to newest BouncyCastle, confirmed it works in Firefox after upgrading, but still getting the same behavior.

This appears related as well: https://stackoverflow.com/questions/78273680/webrtc-connection-could-not-be-established-on-chrome-124

You confirm it's also working on Chrome 123 with newest BouncyCastle ?

[thiggins09]

chrome://net-export/

Something in here that is suspect is

t= 703 [st= 1] UDP_SEND_ERROR
--> net_error = -5 (ERR_INVALID_HANDLE)

[moorecj]

Here are a few more details on we have tried so far:

Looking at this issue:
#1036

We pulled in this code here:
BorgGames@7dd5375

After still having issues we ended up cloning the BouncyCastle repo and debugging.
we were seeing this was still throwing errors
BouncyCastle - TlsUtilities.cs line 4802

 private static void CheckClientCertificateType(CertificateRequest certificateRequest,
            short clientCertificateType, short alertDescription)
        {
            if (clientCertificateType < 0
                || !Arrays.Contains(certificateRequest.CertificateTypes, clientCertificateType))
            {
                throw new TlsFatalAlert(alertDescription);
            }
 }

After commenting out this code as mention here:

Yes, after upgrading to the newest BouncyCastle, I can confirm Chrome 123 such as 123.0.6288.0 still works.

I was able to get BouncyCastle to work by downloading BouncyCastle and commenting out this code:

//if (clientCertificateType < 0 // || !Arrays.Contains(certificateRequest.CertificateTypes, clientCertificateType)) //{ // throw new TlsFatalAlert(alertDescription); //}

Its started working for on Chrome 123 but still FAILING for 124

It would seem simply adding the new BouncyCastle is not enough. Trying to look into what chrome thinks is wrong now.

[thiggins09]

Chrome 124 (doesn't work)
[13052:10296:0418/111721.399:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_server_hello
[13052:10296:0418/111721.399:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_server_certificate
[13052:10296:0418/111721.399:INFO:openssl_adapter.cc(817)] connect_exit TLS client read_server_certificate
[13052:10296:0418/111721.400:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_certificate_status
[13052:10296:0418/111721.400:INFO:openssl_adapter.cc(817)] connect_loop TLS client verify_server_certificate
[13052:10296:0418/111721.400:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_server_key_exchange
[13052:10296:0418/111721.400:INFO:openssl_adapter.cc(817)] connect_exit TLS client read_server_key_exchange
[12236:13232:0418/111721.406:INFO:socket_udp.cc(456)] sendto() has failed twice returning a transient error net::ERR_ADDRESS_UNREACHABLE. Dropping the packet.
[12236:13232:0418/111721.406:INFO:socket_udp.cc(456)] sendto() has failed twice returning a transient error net::ERR_ADDRESS_UNREACHABLE. Dropping the packet.
[13052:10296:0418/111721.419:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_certificate_request
[13052:10296:0418/111721.419:INFO:openssl_adapter.cc(817)] connect_exit TLS client read_certificate_request
[13052:10296:0418/111721.419:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_server_hello_done
[13052:10296:0418/111721.419:INFO:openssl_adapter.cc(817)] connect_exit TLS client read_server_hello_done
[13052:10296:0418/111721.419:INFO:openssl_adapter.cc(817)] connect_loop TLS client send_client_certificate
[13052:10296:0418/111721.419:WARNING:openssl_adapter.cc(820)] write_alert fatal handshake failure TLS client send_client_certificate
[13052:10296:0418/111721.419:INFO:openssl_adapter.cc(817)] connect_exit TLS client send_client_certificate
[13052:10296:0418/111721.419:WARNING:openssl_stream_adapter.cc(949)] OpenSSLStreamAdapter::Error(ContinueSSL, 1, 0)
[13052:10296:0418/111721.419:INFO:dtls_transport.cc(756)] DtlsTransport[0|1|]: DTLS transport error, code=1
[13052:10296:0418/111721.419:VERBOSE1:dtls_transport.cc(863)] DtlsTransport[0|1|]: set_dtls_state from:1 to 4
[13052:10296:0418/111721.419:INFO:srtp_transport.cc(287)] The params in SRTP transport are reset.

Chrome 123 (works)
[16972:41556:0418/114121.834:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_server_hello
[16972:41556:0418/114121.834:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_server_certificate
[16972:41556:0418/114121.834:INFO:openssl_adapter.cc(817)] connect_exit TLS client read_server_certificate
[16972:41556:0418/114121.835:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_certificate_status
[16972:41556:0418/114121.835:INFO:openssl_adapter.cc(817)] connect_loop TLS client verify_server_certificate
[16972:41556:0418/114121.835:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_server_key_exchange
[16972:41556:0418/114121.835:INFO:openssl_adapter.cc(817)] connect_exit TLS client read_server_key_exchange
[25888:34252:0418/114121.836:VERBOSE1:raster_decoder.cc(1420)] RasterDecoderImpl::SetQueryCallback: No query with ID 40. Running the callback immediately.
[16972:41556:0418/114121.844:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_certificate_request
[16972:41556:0418/114121.844:INFO:openssl_adapter.cc(817)] connect_exit TLS client read_certificate_request
[16972:41556:0418/114121.844:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_server_hello_done
[16972:41556:0418/114121.844:INFO:openssl_adapter.cc(817)] connect_exit TLS client read_server_hello_done
[16972:41556:0418/114121.844:INFO:openssl_adapter.cc(817)] connect_loop TLS client send_client_certificate
[16972:41556:0418/114121.844:INFO:openssl_adapter.cc(817)] connect_loop TLS client send_client_key_exchange
[16972:41556:0418/114121.845:INFO:openssl_adapter.cc(817)] connect_loop TLS client send_client_certificate_verify
[16972:41556:0418/114121.845:INFO:openssl_adapter.cc(817)] connect_loop TLS client send_client_finished
[16972:41556:0418/114121.845:INFO:openssl_adapter.cc(817)] connect_loop TLS client finish_flight
[16972:41556:0418/114121.845:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_session_ticket
[16972:41556:0418/114121.845:INFO:openssl_adapter.cc(817)] connect_loop TLS client process_change_cipher_spec
[16972:41556:0418/114121.845:INFO:openssl_adapter.cc(817)] connect_exit TLS client process_change_cipher_spec
[16972:41556:0418/114121.855:INFO:openssl_adapter.cc(817)] connect_loop TLS client read_server_finished
[16972:41556:0418/114121.855:INFO:openssl_adapter.cc(817)] connect_exit TLS client read_server_finished
[16972:41556:0418/114121.855:INFO:openssl_adapter.cc(817)] connect_loop TLS client finish_client_handshake
[16972:41556:0418/114121.856:INFO:openssl_adapter.cc(817)] connect_loop TLS client done
[16972:41556:0418/114121.856:INFO:openssl_adapter.cc(817)] handshake_done TLS client done
[16972:41556:0418/114121.856:INFO:openssl_adapter.cc(817)] connect_exit TLS client done

[sipsorcery]

#1104

…

On Thu, 18 Apr 2024 at 20:10, Cyril Moore ***@***.***> wrote: We found the issue: Chrome is now checking certificate type and needs to be passed the correct one in Certificate Request, Apparently WebRTC should be using ECDSA. In DtlsSrtpServer.cs line 251 change the return to this and it will start being accepted by Chrome. return new CertificateRequest(new byte[] { ClientCertificateType.rsa_sign, ClientCertificateType.ecdsa_sign }, serverSigAlgs, null); — Reply to this email directly, view it on GitHub <#1104 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABQIHCH3LUKM2V2OAEH7MTY6ALCTAVCNFSM6AAAAABGMG66QOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRUHE4TKOBYGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Noah7071]

Trying the library first time today, running the ffmpeg webrtc example, but cant seem to get past handshake_failure(40)' error. Would highly appreciate any pointers how to get past this?