The question is about forcing Win7 to use TLS 1.2 only. (Yes, I know that Win7 gets no more patches, nevermind that.)
The underlying issue is that Ubisoft Connect does not work properly. The logs suggest that this is related to using the wrong version of TLS, I think. Log:
Http status code is 404 for url
Http status code is none for url (HTTP status code is none? Other calls in the logfile work normally, suggesting that there is some fundamental issue with the request itself. Like TLS problems. But maybe not, so I would like to be able to check if TLS 1.2 is configured as the only available protocol correctly - I suspect it isn't.)
Using SSLLabs, I looked at the supported TLS versions of those websites:
It seems the difference is that wallet supports TLS 1.0 & 1.1 but not 1.3 and the channel-service doesn't support 1.0 & 1.1, but does support 1.3. (I'm not trying to use 1.3 though.)
Since 1.2 seems to be supported by both, that is the version I want Ubisoft Connect to use. So I'm trying to configure my Win7 to use TLS 1.2 only, and not use 1.0/1.1 at all. (Sadly, there is no support for 1.3.)
I already read through
So, how can I configure Windows 7 to use TLS 1.2 only and check whether the setting works properly?
81 Answer
I figured it out after all, here is the explanation. Maybe it is of use to someone else too.
The registry changes in SCHANNEL\Protocols are working fine. They can be tested with Internet Explorer. Firefox brings its own HTTPS code, so it's not possible to test with it.
When you set Enable=0 on all HTTPS cryptographic protocols, no HTTPS websites will work in Internet Explorer anymore. Neither will Ubisoft Connect, you cannot even login anymore. I deactivated all of them, (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1) with the exception of TLS 1.2. This way, TLS 1.2 will always be used. (Win7 does not support TLS 1.3.) The login then works again, as the server handling that, seems unaffected by the issue explained below.
The problem was, that does not allow any cipher suites supported by Windows 7. And Windows 7 does not allow you to install new ones. The list of supported ones by the Ubisoft endpoint is rather small:
# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) ECDH x25519 (eq. 3072 bits RSA) FS 256None of these seem to be available in Windows 7.
This can be tested by using Internet Explorer to access both Github.com and the Ubisoft endpoint. Github will work, but the Ubisoft endpoint won't. Both sites use TLS 1.2, but Github allows for a larger variety of cipher suites:
# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH x25519 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH x25519 (eq. 3072 bits RSA) FS 128
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) ECDH x25519 (eq. 3072 bits RSA) FS 256P
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) ECDH x25519 (eq. 3072 bits RSA) FS 256P
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH x25519 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH x25519 (eq. 3072 bits RSA) FS 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK 128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) WEAK 128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256So the conclusion I draw from this, is that Ubisoft should add at least one of the cipher suites supported in Windows 7 to the list of accepted ones for their endpoint server in question. That would be the sane, good solution. Are they going to do it? ... :|
My workaround "solution", was to spoof their endpoint server, by:
- Creating a self-signed certificate for the hostname
channel-service.upc.ubi.com, installing it as a root certificate on my machine, and another one (with Windows 10) in my network. This is needed, as we will be pretending to be the Ubisoft endpoint, when we are in fact not. The HTTPS client only checks if the certificate chain goes back to some root certificate, which it does, as we just added it. - Creating a webserver app with ASP.NET Core, that just receives connections, and "pipes" them to the real Ubisoft endpoint (the entire HTTP request), piping back the response. This is needed to accept a HTTPS connection and send back an appropriate response, encrypted by OUR server. (so not just TCP traffic forwarded)
- Adding an entry into the hosts file on my machine, to redirect
channel-service.upc.ubi.comto the other machine in my network. This is needed so that Ubisoft Connect communicates with our webserver app, rather than try to make a request into the internet. - Running the webserver app on the other (Windows 10) machine. This is needed because 1) we cannot connect to the actual Ubisoft endpoint on the machine with the hosts file modification and 2) we cannot use
HttpClientto connect to the Ubisoft endpoint on a Windows 7 machine, as that fails, just as Internet Explorer and Ubisoft Connect fails. But it does work for Windows 10. It does also work for Java programs.
Now I am able to provide a "gateway"? "proxy"? for all machines running Windows 7 on my network to communicate with the actual Ubisoft endpoint. They just need the Root Certificate and the hosts file modification. Hooray, I can now play multiplayer games and use the chat again. :)
I guess you could also configure a real proxy? Hm, not sure.