1397177 - Problem with the second peer connection in one browser tab (WebRTC)

Status: NEW

(Core :: WebRTC: Networking, defect, P3)

Description

[Anatoly]

Attachment: Connection Log.txt

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce:

I create two separate streams from my webcam with different identifiers. Then I try to connect to both of them and display them within one tab of the browser. 


Actual results:

First stream is displayed correctly, the second stream is not displayed at all.


Expected results:

Both streams should be displayed.

Comment 1

[Andreas Pehrson [:pehrsons]]

Do you have an example page we can use to reproduce this?

Comment 2

[Anatoly]

http://alpha-mgw-sd.webinar.ru/web/create.html

In first tab execute in console:
1) createPublisher("1")
2) createPublisher("2")

In second tab execute in console:
1) createPlayer("1")
2) createPlayer("2")

Second player will not work.

Comment 3

[Andreas Pehrson [:pehrsons]]

Thanks. I can reproduce this in both 55 and 57. We'll have to take a closer look to prioritize properly.

Comment 4

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 5

[Vasiliy Vasilyev]

I have found that Mozilla FireFox can not validate second DTLS Certificate with the same Common Name and different Public Keys. According the code it relies on unique Certificate Subject/Identity per Transport. That's why the same issue occurs with Google Chrome due to its static Common Name "WebRTC". Same issue with OpenWebRTC implementation (also "dtls" plugins from the GStreamer's gst-plugins-pad repo) with its "OpenWebRTC" Certificate. And Firefox works fine with each other in most cases since it generates random Common Names.

Anyway, using static Key Pair temporary solves the issue.

Comment 6

[Eric Rescorla (:ekr)]

Yes, this is a problem in the NSS cert handling. I'll take a look and see if I can fix it.

Needinfoing WTC in case he has any good ideas.

Comment 7

[Eric Rescorla (:ekr)]

After looking at this a bit, I'm less sure what I said in c6 is correct. Firefox should be good with two certificates with the same CN as long as they have different issuer/serials. Valisy, are you sure you are generating separate issuer/serials?

Comment 8

[Vasiliy Vasilyev]

They have same issuer and serial but different keys:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=SE, CN=OpenWebRTC
        Validity
            Not Before: Oct 17 09:35:39 2017 GMT
            Not After : Oct 17 09:35:39 2018 GMT
        Subject: C=SE, CN=OpenWebRTC
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    ...(different)...
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         ...(different)...

Comment 9

[Eric Rescorla (:ekr)]

Thanks. This matches my expectation and I'll see what we can do about making Firefox more robust in this case.

Comment 10

[Wan-Teh Chang]

The issuer name + serial number pair uniquely identifies a certificate.
It is wrong for two different certificates to have the same issuer name
and serial number.

For example, see this excerpt from RFC 5280:

4.1.2.2.  Serial Number

   The serial number MUST be a positive integer assigned by the CA to
   each certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a unique
   certificate).

I am sure this is also specified in X.509.

Comment 11

[Vasiliy Vasilyev]

Thanks, WTC. But reading the same RFC:

4.1.2.2.  Serial Number

   ...

   Note: Non-conforming CAs may issue certificates with serial numbers
   that are negative or zero.  Certificate users SHOULD be prepared to
   gracefully handle such certificates.

In the real world:

Google Chrome's WebRTC self-signed certificates have a negative serial number.
OpenSSL's self-signed certificates have a zero serial number.

Comment 12

[Anatoly]

Hello, colleagues, is there any new information on this issue? Its decision is very important for us.
Best regards!

Comment 13

[Iñaki Baz Castillo]

After looking at this a bit, I'm less sure what I said in c6 is correct. Firefox should be good with two certificates with the same CN as long as they have different issuer/serials.

In https://mediasoup.org we create random DTLS certificates with random name/subject and random serial number:

• https://github.com/versatica/mediasoup/blob/v3/worker/src/RTC/DtlsTransport.cpp#L155

However the issue reported above happens as shown here:

• https://mediasoup.discourse.group/t/firefox-pipetorouter-problems/1995/2

A second PeerConnection connecting to a different worker instance of mediasoup (which has a different random DTLS certificate) fails. And the issue does not happen if all worker instances of mediasoup are provided with the same DTLS certificate (instead of letting them create a random one).

Comment 14

[moritz.becker]

Hi,
we are experiencing the same issue. We are using AWS Kinesis Video Streams with a backend based on https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c and GStreamer. Streams from multiple PeerConnections show up fine in Chrome but only one stream shows up in Firefox.
I have also created this issue for the amazon-kinesis-video-streams-webrtc-sdk-c (https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/issues/1050) but they say the problem is not on their side.

Is anyone looking into this?

Comment 15

[michalsledz34]

Hi,
similar problem here. Opening two PeerConnections from one tab results in DTLS handshake error - Bad Certificate. Sending the same cert works well but it's not an option in my case. Any updates about this issue?

Comment 16

[asad.mahmood]

Hi, We are also facing the same issue. stream on second peer connection doesn't play. If anyone found a workaround please share. Thanks in advance.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.