Websockets over TLS 1.2 cause an unexpected exception with some endpoints

The following code returns a 403 forbidden error on Microsoft .Net 4.7.1 runtime.

On Unity the following code returns the following exception :

       

var _webSocket = new ClientWebSocket();

        try

        {

            _webSocket.ConnectAsync(new Uri("wss://<ID>.iot.<REGION>.amazonaws.com/mqtt"), CancellationToken.None)

                               .ConfigureAwait(false)

                               .GetAwaiter()

                               .GetResult();

        }

        catch (Exception e)

        {

            Debug.LogError(e);

        }

System.Net.WebSockets.WebSocketException (0x80004005): Unable to connect to the remote server

  at System.Net.WebSockets.WebSocketHandle+<ParseAndValidateConnectResponseAsync>d__28.MoveNext () [0x00107] in <4ca7fa06156443beb88ec302e6e9783c>:0 

--- End of stack trace from previous location where exception was thrown ---

This example's URI is left unsigned on purpose as it does not change the result of the test.

Some endpoints works without issues such as this public test endpoint wss://echo.websocket.org.
The issue could be specific to AWS but is limited to the Unity environment as a successful connection can be made using the Microsoft .Net runtime.

 

I filed a bug report with a repro-project. Case number : 1028147

 

This might be the wrong spot, but I've also got WebSocketExceptions. It claims unknown host and no route to host... but the host domain is up and running... is there any version of Unity where TLS works correctly? It's listed as a new feature, but I'm using Firebase, which has been around a while, which tries to make use of it.

 

Thanks, andreasreich.
I've included a bit from the console... but I've now found some source on Google's github that makes me think that the Unity Firebase documentation may be inaccurate or incomplete. I'm going to check that out and report back if I am, in fact, using it correctly... so, false alarm, maybe.

Code (CSharp):

1.  
2. 4/24/2018 12:27:17 AM [Error] WebSocket: ws_0 - WebSocketException during handshake
3. Firebase.Database.Internal.TubeSock.WebSocketException: unknown host: redacted.firebaseio.com ---> System.Net.Sockets.SocketException: No route to host
4.   at System.Net.Sockets.Socket.Connect (System.Net.EndPoint remoteEP) [0x000b6] in <4ca7fa06156443beb88ec302e6e9783c>:0
5.   at System.Net.Sockets.TcpClient.Connect (System.Net.IPEndPoint remoteEP) [0x00033] in <4ca7fa06156443beb88ec302e6e9783c>:0
6.   at Firebase.Database.Internal.TubeSock.WebSocket.CreateSocket () [0x000f3] in <8cc1ef70e8084ebcad7aac4d9bf43a94>:0
7.    --- End of inner exception stack trace ---
8.   at Firebase.Database.Internal.TubeSock.WebSocket.CreateSocket () [0x0011e] in <8cc1ef70e8084ebcad7aac4d9bf43a94>:0
9.   at Firebase.Database.Internal.TubeSock.WebSocket.RunReader () [0x0001b] in <8cc1ef70e8084ebcad7aac4d9bf43a94>:0
10. UnityEngine.Debug:LogError(Object)
11. Firebase.Platform.FirebaseLogger:LogMessage(PlatformLogLevel, String)
12. Firebase.Unity.UnityLoggingService:LogMessage(PlatformLogLevel, String)
13. Firebase.Database.Internal.Logging.DefaultLogger:Error(String, String)
14. Firebase.Database.Internal.Logging.DefaultLogger:OnLogMessage(Level, String, String, Int64)
15. Firebase.Database.Internal.Logging.LogWrapper:Error(String, Exception)
16. Firebase.Database.Internal.TubeSock.WebSocket:LogError(String, Exception)
17. Firebase.Database.Internal.TubeSock.WebSocket:RunReader()
18. Firebase.Database.Internal.TubeSock.Runnable101:Run()
19. Google.Sharpen.Thread:InternalRun()
20. System.Threading.ThreadHelper:ThreadStart()
21.  

 

@andreasreich It is the same exception but I think it throws for a different reason. When authenticating my request it connects fine on both core 2.0 and net framework 4.7.1 but fail on Unity with the exception I posted above.

I have yet to find another endpoint with the bug beside AWS-IOT which lead me to believe it specific to how AWS handle the protocol.

I found out AWS enforce the RFC TLS ALPN extension, is it supported by Mono/Unity?

 

I came across this thread after making this post:
https://forum.unity.com/threads/clientwebsocket-wss-issues.528598/

Seems to be somehow related, would this be a unity bug or a mono bug? If it's a mono bug what options would there possibly be really?

 

I submitted a better example representing the use case we're trying to solve.

Here's a summary of the report.

---
Case : 1031144

Websocket over TLS with mqtt fails connection during handshake.

The example has been tested on with Microsoft .Net 4.7.1,Core 2.0 and Unity. It connects fine on all platforms but Unity.

So the example is using the library MQTTnet but I have a strong suspicion it is besides the point. Reason being:

1) It is not a custom websocket implementation. It uses the implementation given by whichever framework it runs on. (in opposition to SuperSocket and co.)
2) We get the same errors when only connecting a pure TLS 1.2 Websocket without any subprotocols specified. This leads us to believe that the handshake fails before even the specifics of the library kicks in to handle the subprotocol.

For reference here is a Github link referencing the line where a .Net websocket breaks down in the MQTT lib:
https://github.com/chkr1011/MQTTnet...d/Implementations/MqttWebSocketChannel.cs#L76
---

If we can provides you any forms of additional assistance let us know; it's our last roadblock in regards to some importants parts of our project.

 

This could potentially happen if the server does not serve a specifically requested SubProtocol, as well as if the certificates are not working as they should.

wss://echo.websocket.org
Seems to be serving "Sec-Websocket-Version: 13" in chrome, so if you are able to connect to that, then you must also ensure that your endpoint is serving the same version I suppose. (I think this would be WebSocket.SubProtocol)

I had a similar problem and it turns out Unity beta 2018.2 solved it for me; I wasn't able to connect to my WebSocket server through wss:// until I got 2018.2b.

 

@andreasreich Can you tell if I am running into the bug you mentioned based on my new example project? (case 1031144)

 

It ended up being a compatibility issue when using .Net Sockets + Aws IOT Sigv4 + Xamarin. A slight difference of header is probably causing the Sigv4 signature to mismatch, nobody has figured it out yet. I solved my issue by using a custom web socket implementation as mentioned in this Github's issue https://github.com/chkr1011/MQTTnet/issues/211
Thanks for pointing me in the right direction!