DTLS handshake issues on Ubuntu with openssl

[Rajmohan Banavi]

This is an information of those who are having issues with DTLS handshake when using the openssl in their applications on Ubuntu and testing against chrome (may be firefox as well, not tested)

On Ubuntu, with the latest release of openssl the DTLS handshake never completes. The work around is to make an additional call to the api - SSL_CTX_set_read_ahead(ssl_ctx, 1)

So the sequence of API calls must be 

SSL_CTX_new(DTLSv1_server_method());

SSL_CTX_use_certificate(pSslContext, pX509);

SSL_CTX_use_PrivateKey(pSslContext, pX509Key);

SSL_CTX_check_private_key(pSslContext);

SSL_CTX_set_read_ahead(ctx, 1);

After this additional openssl api call, my SFU/router was able to do a successful handshake with chrome. This seems to be a known issue in Openssl. The source for this information - https://mta.openssl.org/pipermail/openssl-dev/2015-January/000400.html

Regards,

Rajmohan

[bryand...@gmail.com]

Thanks for posting this information.  Wish I saw it 2 days ago :)

The issue affected both Chrome and Firefox, at least on my Ubuntu setup.  

I switched to BoringSSL, which resolved it without the extra line of code.  And with the advantage that SSL/crypto are now statically linked, so no more update surprises.

When I try to execute that SSL_CTX_set_read_ahead call on BoringSSL, it returns 0 (failure)

With BoringSSL both Chrome and Firefox work fine, except for Firefox 37-38 which do not complete the handshake.  I suspect that is for a different reason, since Firefox 35-36 now work fine.

--

---
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/d/optout.

[bryand...@gmail.com]

I found the handshake problem with Firefox 37+ and BoringSSL.  

It is necessary to call SSL_CTX_set_ecdh_auto(ctx,1) for FF 37+ to handshake successfully with an OpenSSL server.

More info here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1052610#c40

[Justin Uberti]

Known issue, tracked in https://code.google.com/p/chromium/issues/detail?id=447431.

Generally, support for OpenSSL in WebRTC is in the process of being deprecated. We encourage everyone to migrate to BoringSSL; once BoringSSL is available on iOS, we will officially deprecate support for OpenSSL.

[Lorenzo Miniero]

Hi Justin, 

when you say that it's going to be deprecated in WebRTC, do you mean that in the Google WebRTC stack you'll stop using it, or that you'll stop interacting properly with thirt-party applications that make use of it to implement DTLS and talk to Chrome? As long as openssl implements DTLS according to the standard, shouldn't it work for those anyway?

[Simon Perreault]

On Tue, Jan 20, 2015 at 8:55 PM, Justin Uberti <jub...@google.com> wrote:

Known issue, tracked in https://code.google.com/p/chromium/issues/detail?id=447431.

Generally, support for OpenSSL in WebRTC is in the process of being deprecated. We encourage everyone to migrate to BoringSSL; once BoringSSL is available on iOS, we will officially deprecate support for OpenSSL.

Does BoringSSL actually fix that issue? If so I might start using it in my own implementation. Otherwise, it looks like I'll spend the rest of the day writing a packet-oriented FIFO... ;)

Simon

[Justin Uberti]

I mean that the Google WebRTC stack will no longer support using OpenSSL for SSL; trying to use OpenSSL instead of BoringSSL will result in compilation and probably also runtime errors as the forks diverge.

We will of course continue to interoperate with anything that supports standard DTLS.

[Justin Uberti]

BoringSSL fixes the issue in that they haven't taken the patch that causes the problem yet. 

Once we've added a FifoPacketBuffer to WebRTC we will take the patch in BoringSSL.