3

I am developing an Xmarain.Forms app to initially work on Android along with a service it will be connecting to. The service is a WCF service and needs to use a secure transport to send messages so is set to use https.

I can correctly connect and use the service with both SoapUI and a console program built using the same client proxy library but when I try using the Xamarin App it fails. When run in the emulator the exception is a TimeoutException but when installed on an actual device the exception is WebException with message of "Error: SecureChannelFailure (The authentication or decryption has failed" with inner exception stack of:

  • IOException with message "The authentication or decryption has failed"
  • IOException with message "Error while sending TLS Alert (Fatal:InternalError)"
  • IOException with message "The authentication or decryption has failed.
  • IOException with message "Unable to read data from the transport connection: Connection reset by peer"

The full stack trace is included below as attachments. The full code is available at https://github.com/staircase27/WcfXamarinHttpBugExample along with the instructions of how to set it up and use it. The example code has connections using both http and https to show the difference and to show that one works and the other doesn't. I have also checked while testing that the devices can access the service using their web browsers so it's not a firewall or routing issue.

I have also wiresharked the connection to see where exactly the connection is failing and it's failing at the TLS v1.0 level. The app (on both devices I've tested) is sending a Client Hello and the service is responding with a TCP RST packet rather than a Server Hello. I have also performed a connection from the testing device using a web browser that succeeded and the main differences are in the types of encryption supported specifically the app only offers to use

  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_RSA_WITH_RC4_128_SHA
  • TLS_RSA_WITH_RC4_128_MD5
  • TLS_RSA_WITH_DES_CBC_SHA

where as the working connections both used

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

A filtered wireshark with two connections is at https://github.com/staircase27/WcfXamarinHttpBugExample/raw/master/Mobile%20WCF%20https%20Capture%20-%20Filtered.pcapng. The first connection is from the app and fails with a tcp rst. The second is the start of the connection from the android web browser.

I have enabled all versions of TLS and all cypher suites but it hasn't changed the wireshark trace or exception in the app.

I have also checked the SChannel Event Logs as recommended by @tomasr and found the following event:

  • An SSL client handshake completed successfully. The negotiated cryptographic parameters are as follows. Protocol: TLS 1.0. CipherSuite: 0xc014. Exchange strength: 256

(Before enabling all version of TLS the events were:

  • An TLS 1.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.
  • The following fatal alert was generated: 40. The internal error state is 1205.

)

Nexus 7 - part 1 Nexus 7 - part 2 Android Emulator

staircase27
  • 267
  • 3
  • 12
  • Your best bet is probably to capture a network trace. Sounds like the SSL handshake is failing. Possibly the same as http://stackoverflow.com/questions/4926676/mono-https-webrequest-fails-with-the-authentication-or-decryption-has-failed which is related to failure to validate the server certificate on the Xamarin side. – tomasr Feb 16 '17 at 13:13
  • Are you sure it is not related to this http://stackoverflow.com/questions/38528616/tls-exception-unknown-secure-transport-error-closed-graceful/38530317#38530317 – ClintL Feb 16 '17 at 15:49
  • @ClintLandry I don't think so as I'm using android not ios. I have also tried the nearest equivalent to the fix they suggest there and it makes no difference. – staircase27 Feb 17 '17 at 09:42
  • @tomasr I have already set ServicePointManager.ServerCertificateValidationCallback to a delegate that always returns true which is the main suggestion on that question. Also I'm not entirely sure it's even getting that far and isn't failing much earlier in the SSL connection process. I will have a go at wiresharking both the failing and a successful connection later and will post what I find as an edit. – staircase27 Feb 17 '17 at 10:02
  • 1
    Looking at the wireshark trace, I don't think it's the cypher suite list, since I'd expect that would cause an SSL alert rather than an immediate connection reset. I wonder if perhaps is the lack of a server name indicator (SNI) extension on the Client Hello (if all your SSL bindings on your server are SNI-based, then no SNI would mean server is unable to select the certificate to present to client). However, this doesn't fully make sense either, as the working trace has an SNI with an IP address, not a host name.. – tomasr Feb 17 '17 at 13:05
  • 1
    Is the server Windows/IIS? If so, SCHANNEL logging might help: https://support.microsoft.com/en-us/help/260729/how-to-enable-schannel-event-logging-in-iis – tomasr Feb 17 '17 at 13:06
  • @tomasr I have checked the error logs and have added the entries in above but still not sure how to fix the issue. Any ideas? – staircase27 Feb 17 '17 at 17:39
  • 1
    That's actually a pretty clear error message! And yeah, the set of ciphers being offered by the xamarin client is just... not very good. You can use a tool such as https://www.nartac.com/Products/IISCrypto on your server to check what ciphers are enabled at the server and, optionally, enable one of the ones offered by xamarin. Not the greatest option, but not sure there are better ones. – tomasr Feb 18 '17 at 02:41
  • @tomasr does that work even if not using IIS? I'm using the built in windows service hosting currently. I will give it a go on monday when I'm back at work. Thanks for the help :) – staircase27 Feb 18 '17 at 10:01
  • @tomasr I have enabled all versions of TLS and it's made no changes to the exception in the app or the wireshark trace it has though changed the messages in the SCHANNEL event viewer. – staircase27 Feb 20 '17 at 12:16
  • How did the error messages on the app change after the change? – tomasr Feb 20 '17 at 14:20
  • @tomasr I updated the question above. It's not an error message any more but a success message and is "An SSL client handshake completed successfully. The negotiated cryptographic parameters are as follows. Protocol: TLS 1.0. CipherSuite: 0xc014. Exchange strength: 256". It is still showing exactly the same in wireshark and the app though which is very very odd. – staircase27 Feb 20 '17 at 14:30
  • Do you have an updated Wireshark trace? Because if the connection handshake completed, it should *not* look the same at all. – tomasr Feb 20 '17 at 17:21
  • @tomasr: The wireshark was identical as was the error message in the app which I agree was very odd given what the SChannel message said. I will give it another go later but I tried it multiple times yesterday and every time it the same output – staircase27 Feb 21 '17 at 09:10
  • @tomasr: I have had another check and wireshark and error in app are still the same. The message I said above is the only likely looking entry appearing in the logs but it doesn't actually appear every time and there are now a few other entries appearing. The main other ones are: The SSL server credential's private key has the following properties: CSP name: Microsoft Strong Cryptographic Provider CSP type: 1 Key name: ************** Key Type: signature Key Flags: 0x20 The attached data contains the certificate. and ...continued below – staircase27 Feb 22 '17 at 11:34
  • @tomasr: and "Creating an SSL server credential." – staircase27 Feb 22 '17 at 11:36

1 Answers1

0

Sadly as none of the suggestions in the comments worked I have had to work around this and am now using a RESTful WCF API and have implemented the client manually using HttpClient.

staircase27
  • 267
  • 3
  • 12