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 18.104.22.168
Xamarin iOS 22.214.171.124
Xamarin Studio 126.96.36.199-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.
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).
@Martin, this sounds like an after effect of your TLS fix wrt non-standard ports.
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.
Version numbers of packages used to reproduce the issue:
Mono Framework 188.8.131.52
Xamarin iOS 10.0.1.10
Xamarin for VS 184.108.40.2063
Thanks for providing the extra information.
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
merged in master https://github.com/xamarin/xamarin-macios/commit/9e528354f86ef8f17a3a47c46bf931660afd0a60
and cherry-pick for cycle9 in b4a43820226dcb3ae4a1b9c9cecad4179e931648
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
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
>> 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.
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: