DTLS decode error on WebRTC gateway acting as the client

[Uma Shunmugan]

Hi,

I'm implementing DTLS-SRTP support on our WebRTC gateway using openssl version 1.0.1e.  I have it working with Chrome 28.0.1500.95m when the gateway is the server (and the caller) and Chrome is the client.  However, when the gateway is the callee/client, the DTLS negotiation fails early with a decoding error at our gateway trying to decode the server/Chrome response with "Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done".  Just for comparison, when the gateway is acting as the server, its response contains "Server Hello, Certificate, Server Hello Done", which works.

The gateway is using a self-signed certificate with no CA, and it has the SSL verify mode set to SSL_VERIFY_NONE. The verify routine callback is still called by openssl after reading Server Hello with an error like, "18:self signed certificate:depth=0:/CN=WebRTC". I am not sure if this is a real error or not, and if the callback should be even called with verify disabled.  The callback function, however, returns 1 to make openssl ignore it. Openssl continues on to read the server certificate and produces an alert with the fatal "decode error" (and SSL_read() or SSL_connect() returns SSL_ERROR_SSL (1)).  At this point, I'm thinking it must be a problem on the gateway side either in code or set-up.  Is there any one with familiarity with the topic and/or openssl offer me some suggestions as to what could be wrong here?

Thanks,

Uma

[Justin Uberti]

It seems strange that there is no Certificate Request when your gateway is the server; it should require a cert from the client. That doesn't explain why you can't parse the server hello from Chrome, but it might be indicative of a wrong configuration.

[Uma Shunmugan]

Thanks, Justin.  The reason for the missing Certificate Request is that the verification mode is off.  With verification on, the gateway does send Certificate Request, and DTLS connection is established.  It still doesn't work when the gateway is the client.

[kevinde...@gmail.com]

Does your verify callback return 1 when it gets that error? If not, then you are refusing to accept self-signed certificates.

You may also wish to allow for other certificate verification errors as, unlike most use cases, the certificates are used only to generate SRTP keys and not to verify identity.

static int verify_callback(int preverify_ok, X509_STORE_CTX *ctx)

{

if (!preverify_ok) {

int err = X509_STORE_CTX_get_error(ctx);

switch(err) {

case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT:

case X509_V_ERR_UNABLE_TO_GET_CRL:

case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT:

case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN:

case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:

preverify_ok = 1; // accept certs where we can't verify the trust chain, including self-signed certs

break;

default:

break;

}

}

return preverify_ok;

[Lorenzo Miniero]

What you may also want to try, besides blindly returning 1 in the verify callback (as I shamelessly do :-) ) is compute the fingerprint of the peer certificate and compare it with the one you got via SDP, just to be sure everything's fine with the certificate itself.

Lorenzo

[Harald Alvestrand]

Not verifying the certificat / fingerprint will, of course, leave you open to man-in-the-middle attacks.

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Lorenzo Miniero]

Of course, the 1 in the verify callback is only needed not to get a failure when trying to validate a self signed certificate, as there wouldbe no certificate authority to refer to. Validating the fingerprint right after that is what we do right now.

Lorenzo

[Uma Shunmugan]

Thanks everyone for the feedback!  As Lorenzo mentioned, I do the fingerprint validation a bit later, but I found that I needed to reset the error in the verify callback using the following call in addition to returning 1:

 X509_STORE_CTX_set_error(ctx, X509_V_OK).  (Currently, I do this only if the error is X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT; forgive my ignorance, but could the other error cases "kevinde" pointed out in the code fragment could happen with WebRTC using Chrome or Firefox?)

[Uma Shunmugan]

Oops! I accidentally sent the last response a bit prematurely!  Without resetting the error in the verify callback, SSL_get_peer_certificate() was failing, I believe.

With WebRTC calls, is it possible that a browser uses a trusted certificate instead of self-signed one?  If so, how to configure the certificate to use, for e.g., in Chrome?

So, I'm still debugging the issue when our gateway is the client.  With some of the latest changes (mostly in verify callback), I don't see the fatal alert any more.  However the SSL_read returns error SSL_ERROR_SSL (1), following "read server certificate A" and "read server key exchange B" (as reported in the info callback).  With the retransmitted DTLS message from the server, I see state progresses a bit further to "read server certificate request  A" and "server done A", and then "write client certificate A", but SSL_read() still returns SSL_ERROR_SSL.  With further retransmissions from server, the error/state is stuck (obviously, client/gateway isn't sending the certificate back to the server).  Could this be related to ciphers that are enabled on the gateway side (I tried the default, "ALL" and "MEDIUM,HIGH,eNULL,NULL,aNULL")?

Does anyone have this case working with an endpoint that is using an openssl implementation?  If so, which version of openssl?  Is there a way to get more debug info from openssl than what is shown in the examples at http://www.openssl.org/docs/ssl/SSL_CTX_set_info_callback.html?  If not, I'd need to build a debug version of openssl for debugging this, I suppose.

Thanks,

 Uma

[Lorenzo Miniero]

This is definitely working in the gateway application I'm working on, with both Firefox and Chrome, and without resetting the error as you had to: I haven't tested all browser versions, though, just Firefox Nightly and the "unstable" development version of Chrome. The openssl version I'm using is the 1.0.1e bundled with Fedora 18. Just for the sake of completeness, the ciphers I enabled are "ALL:NULL:eNULL:aNULL".

Lorenzo

[Uma Shunmugan]

OK, I got it working with a debug build of the openssl.  Earlier, I was using the default optimized version.  In addition, I was using the FIPS module with it.  This time with the debug build, I have disabled FIPS for now.  I also had to make some code change: I was assuming SSL_is_init_finished() would be true before getting the peer certificate, which may not be true for the client case; after certificate is received, and SSL_is_init_finished(), get the SRTP keys.

Even with these code changes, an optimized version of openssl built without FIPS did not work in the client case.  I observed that the process doing SSL_read got stuck in a likely infinite loop in openssl taking up all the CPU in one core, and when it eventually returned (it varied but usually after > 1 minute), it had the same SSL_ERROR_SSL (1).  I'll investigate this later to make sure it was not a build issue.

Thanks,

 Uma

[Uma Shunmugan]