Bug 45994

Summary: TLS connections on non-standard ports result in incorrect Server Name Indication value
Product: iOS Reporter: Simon <simon.hodson>
Component: BCL Class LibrariesAssignee: Sebastien Pouliot <sebastien>
Severity: major CC: brock.holum, daniel.wright, gouri.kumari, masafa, mono-bugs+monotouch, sebastien, simon.hodson, vincent.dondain
Priority: High    
Version: XI 10.0 (iOS10)   
Target Milestone: (C9)   
Hardware: PC   
OS: Windows   
Tags: Is this bug a regression?: Yes
Last known good build: Xamarin iOS
Bug Depends on: 46549    
Bug Blocks:    
Attachments: Test case including an ASP.Net wepAPI, and a xamarin application.

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 [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
  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 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:
Build Log: https://gist.github.com/GouriKumari/b60efe7132443d6ff4cf41fb3e6b94fb
Application output: https://gist.github.com/GouriKumari/b177135d9de2be547960c0fc259480e7

Build Log: https://gist.github.com/GouriKumari/7ec255bd61515fb85137e784725a30f7
Application Output: https://gist.github.com/GouriKumari/9038f8317c271ecf0c1e80608362ae5b

## Test Env: