search

sipsorcery-org / sipsorcery

A WebRTC, SIP and VoIP library for C# and .NET. Designed for real-time communications apps.
https://sipsorcery-org.github.io/sipsorcery
Other
1.39k stars 424 forks source link

Chrome Version 124 Update is breaking the DTLS Handshake for WebRTC #1104

Open moorecj opened 3 months ago

moorecj commented 3 months ago

I just updated my chrome to: Chrome Version 124.0.6367.61 (Official Build) (64-bit) And now my app gets: [19:33:17 DBG] Peer connection closed with reason dtls handshake failed.

Looking deeper I see this exception being thrown: Org.BouncyCastle.Crypto.Tls.TlsFatalAlert: 'handshake_failure(40)'

I just pulled the latest from master and it still seems to be happening.

Anyone have any idea what is going on? I would guess Chrome restricted their cipher suites and now its breaking.

thiggins09 commented 3 months ago

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

jasonauk commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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); //}

thiggins09 commented 3 months ago

chrome://net-export/

Something in here that is suspect is

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

moorecj commented 3 months ago

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

Looking at this issue: https://github.com/sipsorcery-org/sipsorcery/issues/1036

We pulled in this code here: https://github.com/BorgGames/sipsorcery/commit/7dd537518f5b2f160e97039cd014d61328e295a9

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 commented 3 months ago

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

moorecj commented 3 months ago

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);

sipsorcery commented 3 months ago

https://github.com/sipsorcery-org/sipsorcery/issues/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 https://github.com/sipsorcery-org/sipsorcery/issues/1104#issuecomment-2064995880, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABQIHCH3LUKM2V2OAEH7MTY6ALCTAVCNFSM6AAAAABGMG66QOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRUHE4TKOBYGA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

renanaragao commented 2 months ago

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

hiagotakaki commented 2 months ago

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.

renanaragao commented 2 months ago

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

image

Code in main:

image

RWL-Dittrich commented 2 months ago

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.

SimonJ-DR commented 2 months ago

A version bump would be appreciated.

Noah7071 commented 2 months ago

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?

Screenshot 2024-05-01 153227
burnedikt commented 4 weeks ago

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? Screenshot 2024-05-01 153227

You need to update the following line to use the most recent sipsorcery version (6.2.4) which has the fix for the DTLS issue:

https://github.com/sipsorcery-org/sipsorcery/blob/a92c57441b8fb9aa5add38f58f71232c35ec3284/examples/WebRTCExamples/FfmpegToWebRTC/FfmpegToWebRTC.csproj#L18