|Summary:||TLS connections on non-standard ports result in incorrect Server Name Indication value|
|Component:||BCL Class Libraries||Assignee:||Sebastien Pouliot <sebastien>|
|Severity:||major||CC:||brock.holum, daniel.wright, gouri.kumari, masafa, mono-bugs+monotouch, sebastien, simon.hodson, vincent.dondain|
|Version:||XI 10.0 (iOS10)|
|Tags:||Is this bug a regression?:||Yes|
|Last known good build:||Xamarin iOS 126.96.36.199|
|Bug Depends on:||46549|
|Attachments:||Test case including an ASP.Net wepAPI, and a xamarin application.|
Description Simon 2016-10-27 09:36:53 UTC
Expectation: 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. Issue: 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]. History: When you build the same app with ... Mono Framework 188.8.131.52 Xamarin iOS 184.108.40.206 Xcode 7.3 Xamarin Studio 220.127.116.11-0 ... 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 [MSFT] 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 18.104.22.168 Xamarin iOS 10.0.1.10 Xcode 8 Xamarin for VS 22.214.171.1243
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 https://bugzilla.xamarin.com/show_bug.cgi?id=46549 PR (master) https://github.com/xamarin/xamarin-macios/pull/1327
Comment 7 Sebastien Pouliot 2016-12-09 13:17:53 UTC
merged in master https://github.com/xamarin/xamarin-macios/commit/9e528354f86ef8f17a3a47c46bf931660afd0a60 and cherry-pick for cycle9 in b4a43820226dcb3ae4a1b9c9cecad4179e931648
Comment 8 Sebastien Pouliot 2016-12-09 14:48:19 UTC
Candidate for C8SR2 -> https://trello.com/c/tDKlHTEu/17-bug-45994-47064-https-on-non-standard-port Requires https://github.com/mono/mono/pull/4123 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: Device: Build Log: https://gist.github.com/GouriKumari/b60efe7132443d6ff4cf41fb3e6b94fb Application output: https://gist.github.com/GouriKumari/b177135d9de2be547960c0fc259480e7 Simulator: Build Log: https://gist.github.com/GouriKumari/7ec255bd61515fb85137e784725a30f7 Application Output: https://gist.github.com/GouriKumari/9038f8317c271ecf0c1e80608362ae5b ## Test Env: https://gist.github.com/GouriKumari/0e13534e413041de105873fcea7754a1