pion
It is prohibited to include the renegotiation_info extension in ServerHello if Renegotiation Indication Extension is not supported by client
Your environment.
- Version: 3.0.4
- Browser: We are using the embedded WolfSSL 5.6.0 on the Sequans GM02SP on Walter (https://www.quickspot.io)
- Other Information: We use pion/dtls as the encryption for a CoAP server for our cellular devices.
What did you do?
We are running a pion/dtls server and connect through cellular with the stack on the modem, which is WolfSSL 5.6.0. The WolfSSL stack aborts the handshake in flight4.
What did you expect?
I expected the handshake to work.
What happened?
After a lot of digging with Wireshark packet traces we have found and validated the issue. In the ClientHello message from the embedded devices there is no renegotiation_info extension and also no TLS_EMPTY_RENEGOTIATION_INFO_SCSV Signaling Cipher Suite Value:
In reply to the above ClientHello the pion/dtls library sends a ServerHello with an empty renegotiation_info extension.
RFC5746 section 3.6 states the following:
If neither the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV nor the "renegotiation_info" extension was included, set the secure_renegotiation flag to FALSE. In this case, some servers may want to terminate the handshake instead of continuing; see Section 4.3 for discussion.
o If the secure_renegotiation flag is set to TRUE, the server MUST include an empty "renegotiation_info" extension in the ServerHello message.
RFC5246 section 7.4.1.4 states the following:
An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello. If a client receives an extension type in ServerHello that it did not request in the associated ClientHello, it MUST abort the handshake with an unsupported_extension fatal alert.
RFC5746 section 4.2 states the following:
When the ServerHello is received, the client MUST verify that it does not contain the "renegotiation_info" extension. If it does, the client MUST abort the handshake. (Because the server has already indicated it does not support secure renegotiation, the only way that this can happen is if the server is broken or there is an attack.)
When I read through merge request #314 I can see that the initial implementation from 16 February 2021 was correct and followed the RFC. But for some reason this was changed a day later to not follow the RFC an always return a renegotiation_info in the ServerHello.
My request would be to rollback commit 9890736 as this breaks clients that follow the RFC spec.
Sorry about the bug @daanpape !
If we revert is https://github.com/pion/dtls/pull/314#issuecomment-779121176 still a problem?
It sounds like we were NEVER sending it? Or did I misunderstand the issue. I am 100% with reverting it, I don't want to break the reported issue in the thread though.
Hi @Sean-Der, no sorry required :D, a big thank you for this piece of software.
In the issue #314 you were indeed never sending it at first. The first applied fix was correct, i.e. sending the renegotiation_info if it is in the ClientHello. But in commit 9890736 this was changed to always return it, which is out of spec.
Ok great! Mind opening a revert PR?
I am able to merge+tag in GitHub UI. Computer I am on currently don't ssh key/access to this repo.
I can do it tonight though!
Sorry for the long pause from my side. I have now created a pull request which reverts the changes but still aligns to master. All tests are working perfectly on my side.
Has there been any updates on this topic? I am trying to use SIPSorcery to interop with PION and having issues with DTLS key sync.
@MikeRavenelle please try https://github.com/pion/dtls/releases/tag/v3.0.7 sorry we lost track of this!
@JoeTurki Hello, I just updated my go.mod file to use v3.0.7 and I am now receiving DTLS handshake failures from BounceyCastle in SipSorcery.
[08:37:10 DBG] Starting DLS handshake with role active. [08:37:10 DBG] RTCPeerConnection DoDtlsHandshake started. [08:37:10 DBG] DTLS commencing handshake as client. [08:37:10 WRN] DTLS client raised unexpected alert: fatal(2), handshake_failure(40). [08:37:10 WRN] DTLS handshake as client failed. handshake_failure(40) Org.BouncyCastle.Tls.TlsFatalAlert: handshake_failure(40) at Org.BouncyCastle.Tls.AbstractTlsPeer.NotifySecureRenegotiation(Boolean secureRenegotiation) at Org.BouncyCastle.Tls.DtlsClientProtocol.ProcessServerHello(ClientHandshakeState state, Byte[] body) at Org.BouncyCastle.Tls.DtlsClientProtocol.ClientHandshake(ClientHandshakeState state, DtlsRecordLayer recordLayer) at Org.BouncyCastle.Tls.DtlsClientProtocol.Connect(TlsClient client, DatagramTransport transport) at SIPSorcery.Net.DtlsSrtpTransport.DoHandshakeAsClient(String& handshakeError) [08:37:10 WRN] RTCPeerConnection DTLS handshake failed with error handshake_failure(40). [08:37:10 DBG] Peer connection closed with reason dtls handshake failed. [08:37:10 DBG] RtpIceChannel for [::]:60996 closed. [08:37:10 DBG] RTPChannel closing, RTP receiver on port 60996. Reason: dtls handshake failed. WebRTC Connection State Changed to: closed WebRTC Connection State Changed to: failed
Here is my log from the SFU that uses PION:
sfu-ws INFO: 2025/08/18 13:37:12 ICE connection state changed: connected dtls TRACE: 13:37:12.322634 handshaker.go:189: [handshake:server] Flight 0: Preparing dtls TRACE: 13:37:12.322687 handshaker.go:189: [handshake:server] Flight 0: Sending dtls TRACE: 13:37:12.322698 handshaker.go:189: [handshake:server] Flight 0: Waiting dtls TRACE: 13:37:12.344368 handshaker.go:313: [handshake:server] Flight 0 -> Flight 2 dtls TRACE: 13:37:12.344395 handshaker.go:189: [handshake:server] Flight 2: Preparing dtls TRACE: 13:37:12.344408 handshaker.go:189: [handshake:server] Flight 2: Sending dtls TRACE: 13:37:12.344420 conn.go:484: [handshake:server] -> HelloVerifyRequest (epoch: 0, seq: 0) dtls TRACE: 13:37:12.344512 handshaker.go:189: [handshake:server] Flight 2: Waiting dtls TRACE: 13:37:12.351639 handshaker.go:313: [handshake:server] Flight 2 -> Flight 4 dtls TRACE: 13:37:12.351662 handshaker.go:189: [handshake:server] Flight 4: Preparing dtls TRACE: 13:37:12.351877 handshaker.go:189: [handshake:server] Flight 4: Sending dtls TRACE: 13:37:12.351898 conn.go:484: [handshake:server] -> ServerHello (epoch: 0, seq: 1) dtls TRACE: 13:37:12.351914 conn.go:484: [handshake:server] -> TypeCertificate (epoch: 0, seq: 2) dtls TRACE: 13:37:12.351927 conn.go:484: [handshake:server] -> ServerKeyExchange (epoch: 0, seq: 3) dtls TRACE: 13:37:12.351938 conn.go:484: [handshake:server] -> CertificateRequest (epoch: 0, seq: 4) dtls TRACE: 13:37:12.351948 conn.go:484: [handshake:server] -> ServerHelloDone (epoch: 0, seq: 5) dtls TRACE: 13:37:12.352031 handshaker.go:189: [handshake:server] Flight 4: Waiting dtls TRACE: 13:37:12.359766 conn.go:984: server: <- Alert Fatal: HandshakeFailure
@MikeRavenelle I'm not sure this has to do with the renegotiation_info extension fix that was presented in this issue. I think you would need to create a new issue and do a packet capture in WireShark to see what is going on.
@MikeRavenelle Did it work with v3.0.6, can you provide packet capture or a way to reproduce?
@JoeTurki So it kind of worked with v3.0.6. The initial handshake would work and the signaling would succeed but after so many packets the keys would become out of sync with the client/server so SRTP unwrapping would start to fail. Attached is a wireshark trace of the DTLS handshake.
I'm not sure how that relates to #711 there is no SCSV in your cipher list for example. hmm, can you please open an issue and provide a way to reproduce this, And we'll try to fix it?