stripe-dotnet: TLS 1.0 vs 1.2 error (Am I missing something?)

@makerofthings7, thank you and I absolutely don’t mind you being a passive middleman. It’s definitely a Xamarin bug as I get the same error without using the stripe.net package. I think the issue may be in their statement, “We are working on adding full TLS 1.2 support, however that is still being planned.” My guess is, what we’re hitting is a direct result of it not being full featured TLS 1.2. Please point them to this post if possible.

As for a test project they can debug, they can literally take the snippet of code below verbatim, create a stripe account so they can replace the “test” keys and try it. They’ll get the error and as you can see, stripe.net isn’t implemented as part of the solution. Replacing Xamarin.Android.Net.AndroidClientHandler() with NativeMessageHandler() which is provided by “using ModernHttpClient” does work however. So there’s something going on with their handler.

var token = await StripeClient.CreateToken(cardHere, “pk_test_yourHaShHerE”); //public key

var client = new HttpClient(new Xamarin.Android.Net.AndroidClientHandler()) client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(“Bearer”, “sk_test_yourHaShHere”); //secret key, don’t store here client.BaseAddress = new Uri(“https://api.stripe.com/v1/”);

var formContent = new FormUrlEncodedContent(new[] { new KeyValuePair(“amount”, “7899”), new KeyValuePair(“currency”, “usd”), new KeyValuePair(“source”, token.Id), new KeyValuePair(“description”, “Some elaborate Description”), });

HttpResponseMessage response = await client.PostAsync(“charges”, formContent);

Hope you don’t mind me doing much more than acting as a passive middleman, but this is Xamarin’s response (2 parts). Feel free to take this offline if you want at my name at Gmail, and I can loop you into the reply

Hey,

Ah okay. Well TLS 1.2 is in a transition period right now. As you have stated, HTTPClient based calls are compatible with TLS 1.2 via the native handler. However, there are some caveats to this configuration. We are working on adding full TLS 1.2 support, however that is still being planned. To fully understand the situation and hopefully get a solution, I need to know where you are with the steps you have taken. It seems that the Stripe.net does not allow you to pass in an HTTPClient, and it will use the default with no overloads (https://github.com/jaymedavis/stripe.net/blob/6ae20e088d5ca2d74776f092b29438dd4bbe8620/src/Stripe/Infrastructure/Requestor.cs#L18).

Are you using the binary distribution of Stripe.net, or are you adding the source to the project and building from there?

If you are using the NuGet package, then adding the environment variable will not, in my understanding, change much. However, if you are building Stripe.net with your project, then the changes should take effect and the native handler should be being used. Based upon the native stacktrace:

at com.android.okhttp.internal.http.HttpConnection$FixedLengthSink.close(HttpConnection.java:314)

It seems you are calling the native handler.

With all of this in mind, it seems that there is some bug between the native handler, and Stripe.net. Are you able to provide a test project to debug with? I can work on creating one as well, but as of right now I do not have a Stripe account to test with 😃

Thanks!

------ Previous message ----

Hope you are well! Just to get a better understanding of what is happening, and what the desires are. You are attempting to use the Stripe.Net binding on an Android project. Stripe is about to disable TLS 1.0, so you are attempting to use the native handler in HTTPClient on Android. It is at this point that you get the above error.

Is that all correct?