This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 45994 - TLS connections on non-standard ports result in incorrect Server Name Indication value
Summary: TLS connections on non-standard ports result in incorrect Server Name Indicat...
Alias: None
Product: iOS
Classification: Xamarin
Component: BCL Class Libraries (show other bugs)
Version: XI 10.0 (iOS10)
Hardware: PC Windows
: High major
Target Milestone: (C9)
Assignee: Sebastien Pouliot
Depends on: 46549
  Show dependency treegraph
Reported: 2016-10-27 09:36 UTC by Simon
Modified: 2017-02-17 23:09 UTC (History)
8 users (show)

See Also:
Is this bug a regression?: Yes
Last known good build: Xamarin iOS

Test case including an ASP.Net wepAPI, and a xamarin application. (85.68 KB, application/x-zip-compressed)
2016-10-28 09:31 UTC, Simon

Description Simon 2016-10-27 09:36:53 UTC
We expect that when making an HTTP request that uses TLS on a non-standard port that the server name extension value in the TLS ClientHello message should contain just the host name.

However; when making a HTTP request that uses TLS on a non-standard port from an app build with the updated cycle 8 release 0 packages the value for the server name extension in the TLS ClientHello message contains [Host Name]:[Port Number].

When you build the same app with ...
    Mono Framework
    Xamarin iOS
    Xcode 7.3
    Xamarin Studio
... the server name extension value correctly contains just the host name.

The build we have that exhibits correct behaviour was built by our CI host, which hasn't been updated in a while, hence the old packages. Our CI process builds the apps using Xamarin Studio on an machine running OS X.

The build that exhibits incorrect behaviour was built using Xamarin for Visual Studio, using the updated Cycle 8 Service Release 0 packages. This behaviour is observed when using either the Apple TLS provider or the Mono TLS provider.
Comment 1 Vincent Dondain 2016-10-27 13:03:26 UTC
Hi Simon,

I'm not sure how to reproduce this issue locally.

Could you please provide a small test case?

Also please include the full version informations of the products when it's not working (the ones when it's working, on your CI bot are fine).
Comment 2 Sebastien Pouliot 2016-10-27 14:03:38 UTC
@Martin, this sounds like an after effect of your TLS fix wrt non-standard ports.
Comment 3 Simon 2016-10-28 09:31:44 UTC
Created attachment 18259 [details]
Test case including an ASP.Net wepAPI, and a xamarin application.

To observe the issue you would need to:
- Set the web api up on port 9009, with an https binding (self-signed certificate is fine, I've deliberately ignored cert errors in the test app). 
- Fill out the HOST-NAME const in the UIViewController1 class. 
- Run the app and press the on-screen button. 
(Nb. We used IIS to run the API as opposed to IIS express)

Using Wireshark or a debugging proxy; you will be able to see the value of the Server Name Extension in the Client Hello Message.
Comment 4 Simon 2016-10-28 09:32:08 UTC
Version numbers of packages used to reproduce the issue:
  Mono Framework
  Xamarin iOS
  Xcode 8
  Xamarin for VS
Comment 5 Sebastien Pouliot 2016-10-28 13:16:29 UTC
Thanks for providing the extra information.
Comment 6 Sebastien Pouliot 2016-12-09 01:46:17 UTC
The same issue for BTLS (and MonoTLS) are tracked from

PR (master)
Comment 7 Sebastien Pouliot 2016-12-09 13:17:53 UTC
merged in master

and cherry-pick for cycle9 in b4a43820226dcb3ae4a1b9c9cecad4179e931648
Comment 8 Sebastien Pouliot 2016-12-09 14:48:19 UTC
Candidate for C8SR2 ->

Requires on the mono side first
Comment 9 Sebastien Pouliot 2016-12-09 20:27:28 UTC
C8SR2 froze before PR was merged. Moving it back to C9 until we decide if an SR3 will happen.

Also marking as FIXED since it's already merged in C9 and QA can verify it.

note: QA this only fix AppleTLS, MonoTLS is tracked in 46549
Comment 11 GouriKumari 2017-02-17 23:09:06 UTC
>> I am unable to verify this issue in Xamarin.iOS. 

I was testing with device config and this issue occurred because test machine and iOS device were on different networks. On changing both device and machine to same network it started  to work for device config. 

## Logs:
Build Log:
Application output:

Build Log:
Application Output:

## Test Env:

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