Bug 41676 - Restsharp returning noContent response when calling https endpoints: Error: SecureChannelFailure
Summary: Restsharp returning noContent response when calling https endpoints: Error: S...
Alias: None
Product: Class Libraries
Classification: Mono
Component: General (show other bugs)
Version: 4.4.0 (C7)
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Martin Baulig
Depends on:
Reported: 2016-06-10 00:22 UTC by vinnievivace
Modified: 2016-07-31 16:41 UTC (History)
10 users (show)

See Also:
Is this bug a regression?: ---
Last known good build:

Test case as described in Comment 0 (346.89 KB, application/zip)
2016-06-10 20:12 UTC, Brendan Zagaeski (Xamarin Support)
Console app test case (3.45 KB, application/zip)
2016-06-10 20:21 UTC, Brendan Zagaeski (Xamarin Support)

Description vinnievivace 2016-06-10 00:22:36 UTC
# Steps to reproduce
Create Cocoa App (Mac > App > Classic API)
download RestSharp package

run code:

var client = new RestClient ("https://httpbin.org");
var request = new RestRequest ("get");
var response = client.Execute (request);

Debugger.Log (1, "Content", response.Content);
Debugger.Log (1, "Length", response.ContentLength.ToString ());
Debugger.Log (1, "Error", response.ErrorMessage);
Debugger.Log (1, "Status", response.StatusCode.ToString ());

# Expected behavior


Content: {
  "args": {}, 
  "headers": {
    "Accept": "application/json, application/xml, text/json, text/x-json, text/javascript, text/xml", 
    "Accept-Encoding": "gzip, deflate", 
    "Content-Length": "0", 
    "Host": "httpbin.org", 
    "User-Agent": "RestSharp/"
  "origin": "", 
  "url": "http://httpbin.org/get"
Length: 345Error: Status: OK

# Actual behavior


Content: Length: 0Error: Error: SecureChannelFailure (The authentication or decryption has failed.)Status: 0

# Supplemental info (logs, images, videos)

try again with the url set to http (not https), correct response received.

# Test environment (full version information)

=== Xamarin Studio Community ===

Version 6.0 (build 5174)
Installation UUID: 5c1fbdff-1568-4abb-8b12-48cbd164fbca
	Mono 4.4.0 (mono-4.4.0-branch-c7-baseline/5995f74) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 404000182

=== Xamarin.Profiler ===

Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Xamarin.Android ===

Version: (Xamarin Studio Community)
Android SDK: /Users/vinnie/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		5.0 (API level 21)
		5.1 (API level 22)
		6.0 (API level 23)

SDK Tools Version: 25.1.3
SDK Platform Tools Version: 23.1
SDK Build Tools Version: 23.0.3

Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-468-11M4833)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-468, mixed mode)

Android Designer EPL code available here:

=== Xamarin Android Player ===

Version: 0.6.5
Location: /Applications/Xamarin Android Player.app

=== Apple Developer Tools ===

Xcode 7.3.1 (10188.1)
Build 7D1014

=== Xamarin.Mac ===

Version: (Xamarin Studio Community)

=== Xamarin.iOS ===

Version: (Xamarin Studio Community)
Hash: 39ebb77
Branch: cycle7
Build date: 2016-06-01 21:23:15-0400

=== Build Information ===

Release ID: 600005174
Git revision: 694a75f040b7f2309bc43d4f78a3a6572ca898bf
Build date: 2016-06-01 17:28:08-04
Xamarin addins: 33f406fa2dcf214012c78cb846585f062b2e1d24
Build lane: monodevelop-lion-cycle7-baseline

=== Operating System ===

Mac OS X 10.11.5
Darwin MacPro.local 15.5.0 Darwin Kernel Version 15.5.0
    Tue Apr 19 18:36:36 PDT 2016
    root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
Comment 1 Lluis Sanchez 2016-06-10 08:11:48 UTC
This is not a Xamarin Studio bug. Please use the support forums if you need help with third party libraries.
Comment 2 vinnievivace 2016-06-10 08:12:51 UTC
This code was working fine until i upgraded to Xamarin 6. I do believe it is a Xamarin bug, hence posting it.
Comment 3 Lluis Sanchez 2016-06-10 08:18:37 UTC
It could be a regression in the runtime then, reassigning.
Comment 4 vinnievivace 2016-06-10 08:19:53 UTC
thank you. im 12 months into a huge project, about to launch. RestSharp has been working flawlessly until the update, so not really any doubt in my mind.
Comment 5 Brendan Zagaeski (Xamarin Support) 2016-06-10 20:12:59 UTC
Created attachment 16284 [details]
Test case as described in Comment 0

I have attached a Classic API Mac project that I created by following the steps listed in Comment 0.

## Steps attempted to replicate

Build and run the attached project in the Debug configuration in Xamarin Studio on Mac.

## Regression status: not a regression (according to my testing, for this precise test case)

It appear that the scenario described in Comment 0 also fails in the older Cycle 5 and Cycle 6 versions.  The error message has changed in Cycle 7, but it is not directly clear whether the underlying problem has changed.

## BAD Results with Cycle 7: Mono 4.4.0 (5995f74) + Xamarin.Mac (39ebb77) + Xamarin Studio 6.0 (build 5174) (694a75f)

> Content: Length: 0Error: Error: SecureChannelFailure (The authentication or decryption has failed.)Status: 0

## BAD Results with Cycle 6: Mono 4.2.4 (71b88f3) + Xamarin.Mac (d692e82) + Xamarin Studio 5.10.3 (build 51) (f3c0d98)

> Content: Length: 0Error: Error: SendFailure (Error writing headers)Status: 0

## BAD Results with Cycle 5: Mono 4.0.5 (1d8d582) + Xamarin.Mac (6db87c5) + Xamarin Studio 5.9.8 (build 0) (cc5f6e5)

> Content: Length: 0Error: Error: SendFailure (Error writing headers)Status: 0

## Additional testing environment info (brief)

OS X 10.11.5
Xcode 7.3 (10183.3), Build 7D175
Comment 6 Brendan Zagaeski (Xamarin Support) 2016-06-10 20:21:32 UTC
Created attachment 16285 [details]
Console app test case

I also observed precisely the same results as described in Comment 5 with a pure console C# test case: it failed on Cycle 5 and Cycle 6 with "SendFailure", and it failed on Cycle 7 with "SecureChannelFailure".

Testing with a plain console app has the advantage that the project can easily be tested on Windows .NET.  The attached test case does indeed run without error on Windows .NET.  So even though it's not clear that this test case demonstrates a _regression_, it certainly does demonstrate a difference in Mono behavior compared to .NET on Windows that would be nice to resolve for a future Mono release.
Comment 7 vinnievivace 2016-06-10 20:37:41 UTC
just to be clear, I have been successfully using Restsharp with a Classic API Mac project, calling https endpoints, using the previously most up to date public release of Xamarin (unsure of version / build).

I am unclear what Cycle 5 and 6 refer to (alpha versions?)

really hoping when you say "would be nice to resolve for a future Mono release." thats something with some urgency attached to it?
Comment 8 Rodrigo Kumpera 2016-06-10 20:40:11 UTC
CC'ing Marek so he's aware of this one.
Comment 9 Brendan Zagaeski (Xamarin Support) 2016-06-10 20:44:24 UTC
Ohhh.  The problem described in Comment 5 and Comment 6 is that https://httpbin.org only supports Diffie-Helmman key agreement, which is not supported by Mono's managed TLS implementation (that only supports up to TLS v1.0).

The following lines fail in the same way:

var request = WebRequest.CreateHttp ("https://httpbin.org");
request.GetResponse ();

So at the moment this bug is a duplicate of Bug 26658, and unfortunately the new "Apple TLS" feature that could allow us to test against a server that requires Diffie-Hellman agreement is a new feature in Cycle 7, so it would not be possible to test https://httpbin.org successfully using Cycle 6.

I will look around a little to see if I can find another suitable HTTPS endpoint to use for this test that supports TLS v1.0 RSA key agreement.  Suggestions for possible alternative endpoints are welcome.
Comment 10 vinnievivace 2016-06-10 20:49:31 UTC
any azure api will probably exhibit the same issue. I could set one up for you if neccessary, but assume you have that capacity?
Comment 11 Brendan Zagaeski (Xamarin Support) 2016-06-10 21:08:06 UTC
We can indeed work on setting something up for testing on our end, but now that the bug has gotten a bit messier, it would be helpful to sanity-check a few things about your original app where you observed the actual regression:

1. Is it a Xamarin.Mac app?

2. If so, does the problem stop if you change "Project Options > Mac Build > SSL/TLS implementation" back to the old default "Mono (TLS v1.0)"?

3. In the condition where the app is _failing_, does `HttpWebRequest()` still work successfully against your real endpoint?

var request = WebRequest.CreateHttp ("YOUR_ENDPOINT");
request.GetResponse ();

Thanks in advance.
Comment 12 Brendan Zagaeski (Xamarin Support) 2016-06-10 21:12:53 UTC
4. Can you provide the `response.ErrorMessage` from your original app?
Comment 13 vinnievivace 2016-06-10 21:14:31 UTC
have to come back to you regarding comment 11 (in the middle of something else unfortunetly)

response.ErrorMessage is as above:

SecureChannelFailure (The authentication or decryption has failed.)

Comment 14 vinnievivace 2016-06-10 21:26:06 UTC

changing SSL/TLS to Mono makes no difference
httpwebrequest returns the same SecureChannelFailure error

original project is a Xamarin.Mac classic app
Comment 15 Brendan Zagaeski (Xamarin Support) 2016-06-10 21:44:29 UTC
Ah interesting, thanks.  It's sounding like the TLS settings of your particular endpoint might be a key factor in the behavior you are seeing.

- Here's one counter-example of an endpoint that seems to work without any trouble for me:

var client = new RestClient ("https://api.github.com");
var request = new RestRequest ("users/xamarin");

Does this endpoint work correctly for you too in your original app?

- There is always a chance your endpoint might have coincidentally changed TLS settings recently.  If you downgrade temporarily to the previous version of Mono that you were using [1], do you still hit the same error when you try to access your endpoint using `HttpWebRequest` in a simple console C# app?

[1] For example was the last Stable version before Cycle 7: http://download.mono-project.com/archive/4.2.4/macos-10-x86/

- Another option to investigate the current TLS settings of your endpoint could be to use https://www.ssllabs.com/ssltest/.  You can check under the "Cipher Suites" section on the completed test and look for an entry that starts with "TLS_RSA".  If all of the entries start with "TLS_ECDHE" or "TLS_DHE", then the site only supports Diffie-Hellman key agreement.
Comment 16 vinnievivace 2016-06-11 23:52:54 UTC
laughing at the "There is always a chance your endpoint might have coincidentally changed TLS settings recently."

about to go away for a week, will try to find time today to try the various things you have outlined.

My endpoint is an API app hosted on Azure, as you guys are now microsoft, are you aware of the standard TLS settings, or any changes you have made??

Comment 17 vinnievivace 2016-06-12 08:34:30 UTC
No time to test any more before I go offline for a week.

Example Microsoft (Azure API App) endpoints:


GET request should return 

    "id": 6,
    "content": "this is the new one"
    "id": 7,
    "content": "this is the new one"
    .... etc

Xamarin Classic Mac app returns:

{"message":"The request is invalid."}Length: 37Error: Status: BadRequest

Example 2 ..............................


should return:

  "id": 36,
  "content": "string"

Xamarin Classic Mac app returns:

The resource you are looking for has been removed, had its name changed, or is temporarily unavailable. Status: NotFound
Comment 18 Brendan Zagaeski (Xamarin Support) 2016-06-13 22:24:47 UTC
Many thanks for the additional experimentation in Comment 17 and setting up those sample Azure endpoints!  Unfortunately, it looks like there is still something unique about your test environment that I have not yet managed to replicate locally.

## Steps followed to test Comment 17

1. Download the test case from Comment 5.  (I also tested the same steps with the console app from Comment 6 and a corresponding Xamarin.iOS app for good measure).

2. Replace the `var client =` and `var request =` lines with the following:

var client = new RestClient ("https://zenmaster.azurewebsites.net/api/DummyDatas");
var request = new RestRequest ("");

3. Run the app in the "Debug" configuration.

4. Replace the `var request=` line with the following:

var request = new RestRequest ("36");

5. Run the app again in the "Debug" configuration.

## Results

After step 3, the "Application Output" window shows:

> Content: [{"id":6,"content":"this is the new one"},{"id":7,"content":"this is the new one"},{"id":8,"content":"this is the new one"},

... etc.

After step 5, the "Application Output" window shows:

> Content: {"id":36,"content":"string"}Length: 148Error: Status: OK

## Possible next steps

The error you reported for the "36" endpoint _might_ be somehow similar to Bug 41699.  But I also have a suspicion Bug 41699 might be caused by the new default Apple TLS implementation, and I think Classic API Mac apps don't have access to that implementation, so the chances are maybe a bit slim.

- When you get back, I'll be curious to know if you continue to see the same error with the "36" endpoint.

- If you do continue to see the same errors with your "DummyDatas" test, does downgrading to the previous versions [1] stop the problem?

[1] https://store.xamarin.com/account/my/subscription/downloads#cycle6

- Comparing the error in Comment 13 against the different errors in Comment 17, it looks like the new test with the "36" endpoint might be hitting a separate issue from the original test.  Does downgrading also stop the problem in your original test?

Thanks again in advance!

## Additional test

As an additional test, I deployed another sample REST app [1] to Azure, and that sample also worked OK for me.  It returned the correct output for the `api/products` endpoint [2] accessed over HTTPS (again using the test app from Comment 5).

[1] http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api
[2] var request = new RestRequest ("api/products");
Comment 19 vinnievivace 2016-06-20 00:59:00 UTC
Hi Brendan. Thanks for the above.

Running steps 1 thru 5 in Comment 18 does indeed give the expected response.

Can you explain whats going on here, whats changed?

Comment 20 vinnievivace 2016-06-20 01:00:54 UTC
Also a question. Were you able to replicate the error using my code unchanged?
Comment 21 Mihail 2016-06-20 07:02:25 UTC

I have the same issue, but on iOS. The answers of your questions below:
1) No, I am using iOS;
2) Yes, if I switch back to MonoTLS everything is OK, but it would be nice it I don't have to in the future, since I saw that MonoTLS will be removed later;
3) No, the request doesn't work additionally
Comment 22 Brendan Zagaeski (Xamarin Support) 2016-06-20 17:33:39 UTC
@Mihail, the original reporter on this bug indicated that the "MonoTLS" setting did _not_ influence the results from his tests, so I suspect you are more likely seeing something more closely related to one of the following 2 symptoms:

- Bug 41697
- Bug 41206

Those 2 bugs have a candidate fix that will be included in "Cycle 6 – Service Release 0" that is due to be released this week.  You can keep an eye on https://releases.xamarin.com/ for the availability of that update.  If it doesn't help, then please do file a new bug report.  Since the issue you are seeing depends on some particular logic, it is highly recommended to minimize your full project to the smallest sample that still shows the problem and then attach the minimized version (optionally privately) on the bug report.  Thanks in advance!
Comment 23 Brendan Zagaeski (Xamarin Support) 2016-06-20 17:45:53 UTC

> Running steps 1 thru 5 in Comment 18 does indeed give the expected response.

> Can you explain whats going on here, whats changed?

> Were you able to replicate the error using my code unchanged?

Steps 1 - 5 were my best attempt to replicate your original code as closely as possible based on Comment 0 and Comment 17.  So I am not yet certain how the results for the "36" endpoint produced a different error in your initial tests.  If you like, you may zip up and attach (optionally privately) the actual original sample project you created that produces the "bad" result for the "36" endpoint in Comment 17.  I will then see if I can hit the error you saw for the "36" endpoint and see if I can find the difference between the two apps.

That said, the errors in Comment 17 might in the end even be unrelated to the error in your original app (comparing the error in Comment 13 against the different errors in Comment 17).  So as a double-check before we dig deeper into troubleshooting strategies for you original app (that still hits the "The authentication or decryption has failed" error), it might be worth double-checking that downgrading does indeed stop that problem in your original app.

Comment 24 Brendan Zagaeski (Xamarin Support) 2016-06-27 18:44:26 UTC
I just learned about another bug that might account for the original issue from Comment 0: Bug 41653.
Comment 25 vinnievivace 2016-06-30 21:47:03 UTC
Hey Brendan. I updated to the latest public build yesterday, created an empty Mac Classic API project and repeated the tests, success! Reading the release notes I could find nothing that suggested anything relating to this bug had been fixed, however something seemed to have changed....

However the original (full) project still exhibited the bug. So I methodically moved all classes/settings over to the new project and it continued to work as expected. I have used DiffMerge to try to identify any differences between the 2 projects, cannot find anything. The new one works, the old does not. Frustrating not to know what the issue is, however I am relieved to have the project working again.

Note You need to log in before you can comment on or make changes to this bug.