NullReferenceException in CreateSession

[skalinets]

Hi,

I have very weird issue. Following code works fine when running locally, but throws nullref when deployed to Azure web app.

Code:

var openTok = new OpenTok(key, secret);
openTok.Debug = true;
Console.SetOut(writer);
var session = openTok.CreateSession();

Exception:

System.NullReferenceException:
   at OpenTokSDK.Util.HttpClient.DoRequest (OpenTok, Version=3.0.6786.26080, Culture=neutral, PublicKeyToken=null)
   at OpenTokSDK.Util.HttpClient.Post (OpenTok, Version=3.0.6786.26080, Culture=neutral, PublicKeyToken=null)
   at OpenTokSDK.OpenTok.CreateSession (OpenTok, Version=3.0.6786.26080, Culture=neutral, PublicKeyToken=null)

I enabled Debug mode and redirected Console.Out to a StringWriter. Here is what I got when code is running in Azure:

[1535559379] Request Method: POST 
[1535559379] Request URI: https://api.opentok.com/session/create 
[1535559379] Request Header: User-Agent = Opentok-DotNet-SDK/3.0.6786.26080 
[1535559379] Request Header: Content-Type = application/x-www-form-urlencoded 
[1535559379] Request Header: Expect = application/x-www-form-urlencoded 
[1535559379] Request Header: X-OPENTOK-AUTH = <removed_token> 
[1535559379] Request Header: X-TB-VERSION = 1 
[1535559379] Request Body: location=&p2p.preference=enabled&archiveMode=manual 
[1535559379] WebException Status: SendFailure, Message: The underlying connection was closed: An unexpected error occurred on a send.

And this one is produced when the same code is running on localhost:

[1535559691] Request Method: POST 
[1535559691] Request URI: https://api.opentok.com/session/create 
[1535559691] Request Header: User-Agent = Opentok-DotNet-SDK/3.0.6786.26080 
[1535559691] Request Header: Content-Type = application/x-www-form-urlencoded 
[1535559691] Request Header: Expect = application/x-www-form-urlencoded 
[1535559691] Request Header: X-OPENTOK-AUTH = <removed_token> 
[1535559691] Request Header: X-TB-VERSION = 1 
[1535559691] Request Body: location=&p2p.preference=enabled&archiveMode=manual 
[1535559691] Response Status Code: OK 
[1535559691] Response Status Description: OK 
[1535559691] Response Header: Connection = keep-alive 
[1535559691] Response Header: Access-Control-Allow-Origin = * 
[1535559691] Response Header: Strict-Transport-Security = max-age=31536000; includeSubdomains 
[1535559691] Response Header: Content-Length = 720 
[1535559691] Response Header: Content-Type = application/xml 
[1535559691] Response Header: Date = Wed, 29 Aug 2018 16:21:31 GMT 
[1535559691] Response Header: Server = nginx

I thought that probably jwt token is being gerenated incorrectly in Azure and hence the error, but then I tried to run that request with the same headers, including jwt token, from localhost and it works fine.

I also tried to create .NET Web API app from scratch, deployed it to azure and it works fine as well. I deployed my impacted app to different app services and issue is being reproduced everywhere.

Even if this one is not an issue of opentok, getting nullrefs from inside 3rd party library is rather confusing. You might want to wrap it to something meaningful :)

[skalinets]

I tried to make the same call to API from Azure Diagnostic Console using powershell script, and also got "The underlying connection was closed" error. Interesting, that error for powershell script is being received on both servers -- where I get nullref and where everything works fine.

[eccdev]

I'm experiencing the same issue on an AWS EC2 instance. I was working on the development server for a production app that had some other changes related to Google Maps and was checking everything else when the error occurred. The TokBox code has been running for several years with no problems, so I opened the sample project and the same error occurred. I'll try it locally and see what happens.

[eccdev]

It looks like the solution is a single line of code to force TLS 1.2 before creating a session, and also from what I found, starting an archive.
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

There was actually a note on this in one of the TokBox support areas about two weeks ago.

[skalinets]

@eccdev yes, it is. One day of pulling my hear out has been fixed by one line :)
Thanks!

[skalinets]

Are there any reasons of why this line should not be in opentok SDK?

[skalinets]

here is the link to support article https://support.tokbox.com/hc/en-us/articles/360000373020-Getting-error-while-creating-session-using-OpenTok-Net-SDK

[eccdev]

It's still somewhat incomplete. It seems like it's also needed for archiving calls, even the one to get archive info. It's funny that they don't mention going from ASP.NET 4.5.x to 4.6, and in the case of a large solution, this can be a headache.

[msach22]

@skalinets Thanks for reporting the issue and sorry for the delayed response my end. As of Aug 1st, the our servers only accept TLS1.1 and above. This means that any API call that's made to OpenTok servers must be done using TLS1.1 or above.

We haven't hard coded that in the SDK because we don't want to limit our users to TLS 1.1 or TLS1.2 (it should be picking up from the server environment).

You should be able to add it to your global.asax Application_Start so you don't have to add it everywhere else.

[skalinets]

@msach22 I think 2 changes would help someone who will face this or similar issue

1. Handle send failures errors and throw exception with meaningful message
2. Include recommendation regarding TLS upgrade into exception message

[msach22]

That sounds like a great idea @skalinets! If you're up for it, please submit a PR, if not I will try to add this in the near future 😄

[llauderesv]

Hi Everyone,

I'm having a problem regarding with this library when I tried to create a session in OpenTok. The error says "Error with request Submission"

Here's the screenshot of the error.

• I'm using the OpenTok 2.2.3 via Nuget version
• Already tried to force the protocol TLS1.2 and TLS1.1

Note: I'm using .NET version 4.0
Seeking in your immediate response. Thank you!

[msach22]

@llauderesv, Could you please upgrade to the latest OpenTok .NET SDK - we are currently on v3.1.0?
Could you please expand the View Details section and share the information?

[llauderesv]

@msach22 If I upgrade to the latest version of OpenTok I think theres a need to upgrade a .NET Framework. Currently we're using .NET Framework version 4.0 in the production that's the reason why I use OpenTok 2.2.3 to support our current .NET framework.

[msach22]

@llauderesv As far as I know, .NET 4.0 does not support TLS 1.1 or TLS 1.2 which is why you would have to upgrade to 4.5 at the very minimum. OpenTok does not support TLS 1.0 so you have use to TLS 1.1 or TLS 1.2 to communicate with our API servers.

[llauderesv]

Hi @msach22,

I already tried to work in OpenTok v3.1.0 in my Application and I encounter this error. I also forcing to use the TLS1.2 Kindly see the screenshot of my error. Thanks.

[msach22]

@llauderesv Could you please confirm that you application is running .NET 4.5? I recommend running the HelloWorld sample within this repo to see if it works for you.

https://github.com/opentok/Opentok-.NET-SDK/tree/master/Samples/HelloWorld

[fidergo-stephane-gourichon]

This is a serious issue because the SDK does not work out-of-the-box. This creates incident and puts feeling of flakey SDK onto your users.

I have read comment #108 (comment) which states:

We haven't hard coded that in the SDK because we don't want to limit our users to TLS 1.1 or TLS1.2 (it should be picking up from the server environment).

I agree that the line should not be in SDK itself, but it should be in caller code, with a comment stating when to remove it.

Having a SDK that work out-of-the-box is very important.

[msach22]

@fidergo-stephane-gourichon That's a fair point. What if we updated our samples and the README of the SDK? This way the TLS code would not be in the code of the SDK, but would show you how to make it work in your app.

[abidCharlotte49er]

How is it going @msach22 I've tried forcing SecurityProtocol to Tls12 as seen in the image. It still fails for 5 different combinations I tried. I can confirm I'm using OpenTok 3.1.0 i got from Nuget and my project is .NETCore which supports Tls12. Am I missing something? Appreciate your help!!

[nnaig08]

Hi Everyone,

We are experiencing the following error in creating session, hoping for your quick response to what might be causing this and possible solution, Thank you

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

Note:

We have a multiple instance of web apps hosted in the same server, two of them uses opentok capability to have a realtime video chat and one of them is successfully using it the reason why we are getting confused why the other app is having the issue above, whilst they are using the same key and secret and request configurations and SSL certificate.

[msach22]

@nnaig08 Thanks for raising this. Could you verify the time clock on the application that's not working is up to date?

[nnaig08]

@nnaig08 Thanks for raising this. Could you verify the time clock on the application that's not working is up to date?

Hi @msach22 yup, the time is in sync and up to date. We are really out of options regarding this issue, had rendered almost half day searching for possible solutions but still no avail. :(

[slorello89]

Hi @nnaig08 - Sorry for the delay in getting back to you, the issue you're referring to is almost certainly not an issue with the SDK or even anything in your code - it's almost certainly an issue with either the cert store on the server or VM that you're running on or with how IIS is configured. Our API endpoints uses GoDaddy as a root CA - which is typically installed on windows by default. Can you ensure that those GoDaddy's certs are installed on your machines?

thanks!

[matt-lethargic]

As the last comment on this issue is approaching two years ago and with the fact that there have been two merged PRs to aid in fixing this, I am now going to close. If there are more outstanding issues relating to TLS versions please re-open or create a new issue.