Matt, Thanks for taking the time to go through this. Unfortunately this error only happens when WebRTC is acting as the server in the dtls handshake and no logs (at all) seem to be printed but I think that's because openssl logging is done in a different way in native WebRTC which I'm not handling. I'll try increasing logs and / or printing openssl errors. The janus server gets the alert packet which I'm guessing is an error produced by the server in the transaction above. I'm assuming the problem is with the client reply that janus sent. Any idea what it could have sent wrong that WebRTC didn't like? Could it have encrypted the message with a wrong crypto or something or is this negotiation wholly handled by openssl? I'm trying to understand if janus is doing something wrong or is the dtls stuff completely handled by libssl - in which case this might be a dtls bug? I'm a newbie to openssl and dtls so dont mind the stupid questions. I however do know C and socket stuff so can get in to check with some guidance :) On Fri, May 1, 2015, 2:37 AM Matt Caswell <matt at openssl.org> wrote: > > > On 01/05/15 02:11, faraz khan wrote: > > Hi everyone, > > This is my first time posting to this list - so if theres a better place > > for this question please let me know. > > > > The problem I'm trying to fix applies to the Janus webrtc gateway > > (https://github.com/meetecho/janus-gateway) and my application which is > > using native C++ webrtc. > > > > What happens is that after hundreds of successful connections, sometimes > > the Janus server is unable to negotiate a DTLS handshake and after a key > > exchange the webrtc client replied with a DTLS Alert: Decrypt failed > > message. I'm attaching a wireshark trace of the issue happening and one > > for the correct negotiation. > > > > The problem refuses to fix itself till Janus is restarted. > > > > Both installations are using Openssl. Janus is compiled with version > 1.0.1f > > > > If someone can help explain how DTLS key exchange works and whats going > > wrong in the above trace it would be great! I'm completely at a loss as > > far as this is concerned! > > > > Thanks all! > > Hmmmm. I can't see anything obviously wrong with the above traces. The > handshake seems to proceed as normal and then fail near the end. > > A couple of things of note: > * A client cert is being sent, but it has expired. I don't think this is > the problem though because it is the same cert in the "good" trace and > the "bad" trace. > Validity > Not Before: Feb 9 16:18:45 2007 GMT > Not After : Feb 8 16:18:45 2009 GMT > > * A different ciphersuite is being negotiated between the "good" version > and the "bad" version. "Good" is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, > whilst "Bad" is TLS_RSA_WITH_AES_256_CBC_SHA. I'm not sure if that is > significant, but I can't see why a server restart would make any > difference if it were. > > Are there any server logs which might indicate why it is sending the > alert? Looking at the code there are only a few places in the code which > generate a decrypt error alert. It would probably help diagnose the > problem if we could narrow down which of those places this is coming > from. OpenSSL adds an error to its error queue for each of those places. > > The other point of note is that there have been quite a lot of DTLS > related defect fixes in the OpenSSL code since 1.0.1f. An upgrade would > be a really good idea. > > Matt > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150501/01b8ad20/attachment.html>
