TLS connections with SFS 2.13.0

Post here your questions about the Unity / .Net / Mono / Windows 8 / Windows Phone 8 API for SFS2X

Moderators: Lapo, Bax

FreeBird
Posts: 7
Joined: 30 Jun 2018, 04:26

TLS connections with SFS 2.13.0

Postby FreeBird » 30 Jun 2018, 04:43

I have SFS 2.13.0 running on an AWS instance. When I try to connect to it using the sample code (Connector.cs with API v1.7.5) through Unity, I get an error:

Code: Select all

[SFS > ERROR] [WebSocketLayer] Connection error: An exception has occurred while connecting.   at WebSocketSharp.WebSocket.setClientStream () [0x00000] in <filename unknown>:0
  at WebSocketSharp.WebSocket.doHandshake () [0x00000] in <filename unknown>:0
  at WebSocketSharp.WebSocket.connect () [0x00000] in <filename unknown>:0
UnityEngine.Debug:Log(Object)
Connector:ShowLogMessage(String, String) (at Assets/ConnectorAssets/Scripts/Connector.cs:214)
Connector:OnErrorMessage(BaseEvent) (at Assets/ConnectorAssets/Scripts/Connector.cs:208)
Sfs2X.Core.EventDispatcher:DispatchEvent(BaseEvent)
Sfs2X.SmartFox:ProcessEvents()
Connector:Update() (at Assets/ConnectorAssets/Scripts/Connector.cs:57)


After a bit of troubleshooting, I think I have arrived at the root cause.

Code: Select all

nmap --script +ssl-enum-ciphers -p 8443 172.16.10.18
PORT     STATE SERVICE
8443/tcp open  https-alt
| ssl-enum-ciphers:
|   TLSv1.0: No supported ciphers found
|   TLSv1.1: No supported ciphers found
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|     compressors:
|       NULL
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 0.76 seconds


All ciphers on offer from the SFS server are using SHA256. But when I do a wireshark capture on the Unity client, I see:

Code: Select all

Secure Sockets Layer
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 69
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 65
            Version: TLS 1.0 (0x0301)
            Random: 5b36f41993cd5c90d858366f94855012e984255e8b5715dd...
                GMT Unix Time: Jun 30, 2018 08:38:09.000000000 India Standard Time
                Random Bytes: 93cd5c90d858366f94855012e984255e8b5715dd5f5eb833...
            Session ID Length: 0
            Cipher Suites Length: 26
            Cipher Suites (13 suites)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
                Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
                Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
                Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 (0x0060)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 (0x0061)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)


None of the cipher suits offered by the client have SHA256. Therefore there is none common, and hence the handshake fails.

1. Am I correct in my RCA?

2. If yes, how can I solve this? I don't want to use SHA1 or MD5 at the server side; my preference is to change things on the client side to work with SHA256.

Also, the server does not seem to be offering AES256. Is it something I can enable with a switch?
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: TLS connections with SFS 2.13.0

Postby Lapo » 30 Jun 2018, 08:43

Hello,
the IP address of the server seems local (i.e. runs in a private network).

If that's the case the SSL/TLS connection won't work because of the self-signed certificate. Unfortunately the WebsocketSharp library doesn't provide a proper error reporting. The exception make it sounds like there was a connection error while in actuality it's the SSL handshake that failed.

I am not sure if there's a way to test locally with a self signed certificate. You might try googling it, maybe there's some way to do it. In Java, for instance, you can force it to use a local self-signed certificate though it's a highly discouraged practice.

Hope it helps
Lapo
--
gotoAndPlay()
...addicted to flash games
FreeBird
Posts: 7
Joined: 30 Jun 2018, 04:26

Re: TLS connections with SFS 2.13.0

Postby FreeBird » 30 Jun 2018, 11:19

Lapo wrote:the IP address of the server seems local (i.e. runs in a private network).

If that's the case the SSL/TLS connection won't work because of the self-signed certificate. Unfortunately the WebsocketSharp library doesn't provide a proper error reporting. The exception make it sounds like there was a connection error while in actuality it's the SSL handshake that failed.


The IP address is local only because I edited out my actual public dns name. In any case (even for local) I don't use self-signed certificates; I have a setup that deploys Let's Encrypt certificates via CertBot. So that is not the problem.

I think the cipher suite collection on the Unity end is the culprit (no support for AES 128 / SHA 256 out of the box etc.).
FreeBird
Posts: 7
Joined: 30 Jun 2018, 04:26

Re: TLS connections with SFS 2.13.0

Postby FreeBird » 30 Jun 2018, 16:23

So I've had some success here. Once I figured that all of WebSocket stuff is to be in Jetty it didn't take long, except for a bit of trial-and-error.

SFS 2.13.0 ships with Jetty 9.3.11. This version has does not enable anything that can be construed as insecure in SSL/TLS context. In particular, only SHA256 and TLSv1.2 work out of the box.

Unity (Mono?) doesn't seem to have support for SHA256 or for that matter, TLSv1.1+.

So I simply had to follow Jetty documentation to enable these. I dropped a tweak-ssl.xml into jetty/etc and set the argument to setExcludeCipherSuites to an empty array. Now I can see common ciphers in Unity and Jetty (I have limited this to just one, TLS_RSA_WITH_AES_128_CBC_SHA). The sample Connector.cs works too. My developers will be back in office on Monday, after which I will get the final confirmation.

Though, before production rollout a decision needs to be made whether these compromises are to be persisted or not.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: TLS connections with SFS 2.13.0

Postby Lapo » 01 Jul 2018, 10:41

Hi,
SFS 2.13.0 ships with Jetty 9.3.11. This version has does not enable anything that can be construed as insecure in SSL/TLS context. In particular, only SHA256 and TLSv1.2 work out of the box.

Unity (Mono?) doesn't seem to have support for SHA256 or for that matter, TLSv1.1+.

I find all this quite strange, because we've done all the necessary tests for SSL/TLS connections with Unity and have not bumped into any issues such as this.

Out of the box there's no need to reconfigure Jetty at all besides installing a valid certificate.

Also, I don't even think Mono is involved at all in the client side once the app is built for WebGL. It uses the browser's own websocket client engine.

Cheers
Lapo

--

gotoAndPlay()

...addicted to flash games

Return to “SFS2X C# API”

Who is online

Users browsing this forum: No registered users and 34 guests