1574188 - No support for rfc7627 extended master secret

Status: NEW

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

Description

[mondain]

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

Steps to reproduce:

Connect Firefox to a subscribe to webrtc link (can be provided if requested)

The server being connected to is using DTLS 1.2 with RFC 7627 enabled

Actual results:

Connection failed with server log output:
DtlsPacketTransformer - Connect exception
org.bouncycastle.tls.TlsFatalAlert: unsupported_extension(110)
at org.bouncycastle.tls.DTLSRecordLayer.processRecord(Unknown Source)
at org.bouncycastle.tls.DTLSRecordLayer.receive(Unknown Source)
at org.bouncycastle.tls.DTLSReliableHandshake.receiveMessage(Unknown Source)
at org.bouncycastle.tls.DTLSServerProtocol.serverHandshake(Unknown Source)
at org.bouncycastle.tls.DTLSServerProtocol.accept(Unknown Source)
at org.bouncycastle.tls.DTLSServerProtocol.accept(Unknown Source)

Expected results:

Firefox should have connected successfully in the same manner as it does before the RFC 7627 feature is enabled on the server.

Doing a search here yields this ticket which would most likely resolve the problem if it were actually resolved: https://bugzilla.mozilla.org/show_bug.cgi?id=1224875

Comment 1

[Alex Chronopoulos [:achronop]]

Can you please help me triage this issue?

Comment 2

[Byron Campen [:bwc]]

It looks like bug 1224875 was in fact fixed: https://searchfox.org/mozilla-central/rev/3a61fb322f74a0396878468e50e4f4e97e369825/security/manager/ssl/nsNSSComponent.cpp#1744

I think there may be something more complicated going on here. Could you attach a wireshark trace?

Comment 3

[mondain]

I'll collect a trace today if time permits; thanks for looking into this.

Comment 4

[Martin Thomson [:mt:]]

Here's some code that might be added to TransportLayerDtls::Setup() to see if anything changes:

  rv = SSL_OptionSet(ssl_fd.get(), SSL_ENABLE_EXTENDED_MASTER_SECRET, PR_TRUE);
  if (rv != SECSuccess) {
    MOZ_MTLOG(ML_ERROR, "Couldn't enable extended master secret");
    return false;
  }

It's possible that the WebRTC stack isn't able to rely on the defaults. I thought that it would though. Those are globals, so as long as PSM is setup in the process that WebRTC networking runs in, this should be fine.

(Note: I think that we should make this a default in NSS, which would remove the need to do this setup.)

Comment 5

[mondain]

Attachment: Requested pcapng file

Attached requested wireshark capture

Comment 6

[mondain]

Alex, was the pcap helpful at all?

Comment 7

[Alex Chronopoulos [:achronop]]

Byron, did you have a chance to check the traces?

Comment 8

[Byron Campen [:bwc]]

I don't see any DTLS packets in that trace. I cannot tell which end was supposed to send the client hello without the SDP, could you supply that?

Comment 9

[mondain]

Unfortunately I didn't keep the SDP from two weeks ago as I wasn't aware the full pcap with Chrome publishing to the local server via webrtc and Firefox trying to subscribe to the local server wouldn't be enough. If you're not finding DTLS in the pcap, I'd have to assume the filter isn't correctly detecting them as the entire session is there pub and sub with server responses as well.

Comment 10

[Byron Campen [:bwc]]

Wireshark has never failed to classify DTLS packets for me. Are you certain that the DTLS client hello is being sent?

Comment 11

[mondain]

I'm not aware of any browser that does WebRTC without DTLS; so that would imply my wireshark capture is somehow not-correct given that I collected on the interface that all three parties were using. The publisher / broadcaster was Chrome and it was streaming to the server just fine. I'll do another collection and attach some logging to show the DTLS content specifically for comparison.

Comment 12

[mondain]

Attachment: Red5 Pro server log section specific to the DTLS connection

Comment 13

[mondain]

Attachment: Firefox console showing the SDP etc

Comment 14

[mondain]

Attachment: bug1574188-dtls.pcapng

Latest pcap for FF 69 (since my linux box updated)

Comment 15

[Byron Campen [:bwc]]

Ok, we definitely do not seem to be emitting the extended master secret extension in our Client Hello. Not sure why. We could try the suggestion in comment 4 and see if it makes a difference.

Comment 16

[mondain]

I've got a work-around in my server code to handle this now, but I'd love to see it properly fixed in Firefox 69+. Whats the current status of work to emit the extension in the Client Hello?

Comment 17

[mondain]

(In reply to Byron Campen [:bwc] from comment #15)

Ok, we definitely do not seem to be emitting the extended master secret extension in our Client Hello. Not sure why. We could try the suggestion in comment 4 and see if it makes a difference.

Our workaround stopped working in 70, any chance one of y'all could take a look at this issue and / or apply the ext master secret to the hellos? This issue was put in at 68, so it's getting a bit old now.