[openssl-users] Trying to understand DTLS (as it applies to webrtc)

[faraz khan]

Matt,
Thanks again! To be precise webrtc is using boringssl (Google's fork of
openssl). From the commits it seems VERY recent but I'm unable to figure
out the last openssl merge-in. You think this could be the issue? Should I
try both with boringSSL (its kinda hard to compile webrtc with openSSL now
since after the move to boringSSL)

On Fri, May 1, 2015 at 9:33 AM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 01/05/15 16:51, faraz khan wrote:
> > 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.
>
> Yes. You can see the following exchanges in the traces:
>
> Client                    Server
> ------                    ------
>
> ClientHello ------------>
>                           ServerHello
>                           Certificate
>                           CertificateRequest
>             <------------ ServerHelloDone
> Certificate
> ClientKeyExchange
> CertificateVerify
> ChangeCipherSpec
> [Finished (Encrypted)] -->
>             <------------ Alert (Decrypt Error)
>
> If I understand your setup correctly (I'm not familiar with Janus or
> WebRTC), Janus is acting as the client here and WebRTC is the server,
> and both are using OpenSSL?
>
> >
> > 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?
>
> The server doesn't like something the Client sent in the last flight of
> messages, i.e. the Certificate, ClientKeyExchange, CertificateVerify,
> ChangeCipherSpec or Finished. It's unlikely to be the Certificate as, as
> far as I can tell, its the same Certificate in the "good" exchange
> versus the bad. So that means either the ClientKeyExchange,
> CertificateVerify or Finished messages (CCS is super simple so I don't
> think its that).
>
> Is WebRTC using 1.0.1 too (and if so which letter version)? Looking at
> the 1.0.1 code there are only a few places where a decrypt error can
> come from. Possible causes (in 1.0.1 code base):
>
> - digest check failed processing the Finished message
> - CRL signature failure processing the client Certificate
> - Bad RSA decrypt processing the CertificateVerify
> - Bad RSA signature processing the CertificateVerify
>
> There are a few other places that emit Decrypt Error alerts but none of
> them seem to apply here. Getting some additional logging might help us
> figure out which one of these is the cause.
>
> These are all quite low level issues though...deep in OpenSSL internals.
>
> 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/33a9a2bb/attachment-0001.html>