Steam client security concerns

[J Ventura]

I see that when the Steam client is started on a computer, both the "steamservice.exe" and the client "steam.exe" are making insecure HTTP connections to remote sites on the internet.

I find this to be an unacceptable risk for my computer. I would expect Steam to convert these and all other connections made to use a secure protocol such as HTTPS very soon. The conversion is simple and low effort. It is very irresponsible of Steam to have not done this to date.

[RiO]

引用自 Crashed：

Apparently this one HTTP connection may be solely to probe if the connection is getting redirected, like mentioned above by a captive portal, as the main HTTPS connections would fail in such a scenario with a certificate error.

Yes; and you don't need a potentially much more dangerous and susceptible HTTP connection for that. Because as you already point out: HTTPS connections would fail if the certificate doesn't match!
Specifically they would fail with a dedicated status that indicates the certificate isn't valid for the domain. Which is just about the clearest signal you can get that someone is trying to intercept your traffic.

[Crashed]

引用自 RiO：

引用自 Crashed：

Apparently this one HTTP connection may be solely to probe if the connection is getting redirected, like mentioned above by a captive portal, as the main HTTPS connections would fail in such a scenario with a certificate error.

Yes; and you don't need a potentially much more dangerous and susceptible HTTP connection for that. Because as you already point out: HTTPS connections would fail if the certificate doesn't match!
Specifically they would fail with a dedicated status that indicates the certificate isn't valid for the domain. Which is just about the clearest signal you can get that someone is trying to intercept your traffic.

Still, the connection isn't necessarily dangerous if the client is hardened against any manipulation of the buffers. It could also determine why a certificate error occurs in the first place.

[RiO]

引用自 Crashed：

It could also determine why a certificate error occurs in the first place.

Determining why the certificate error occurs is what the secure connection's certificate handling is already doing by returning explicit status error codes and ancillary information.

And if the connection fails for other reasons, such as a transient loss of connectivity or transient down time, then the request would already fail at the transport level and you'd get an explicit status error which indicates that.

There is literally zero; z-e-r-o reason such a probe has to be done over plain-text HTTP.

[aiusepsi]

引用自 RiO：

There is literally zero; z-e-r-o reason such a probe has to be done over plain-text HTTP.

Since Android 5.0 (API level 21), Android devices have detected captive portals and notified the user that they need to sign in to the network to access the internet. Captive portals were detected using cleartext HTTP probes to known destinations (such as connectivitycheck.gstatic.com), and if the probe received an HTTP redirect, the device assumed that the network was a captive portal.

https://developer.android.com/about/versions/11/features/captive-portal

Shill, the connection manager for Chromium OS, attempts to detect services that are within a captive portal whenever a service transitions to the ready state. This determination of being in a captive portal or being online is done by attempting to retrieve the webpage http://clients3.google.com/generate_204. This well known URL is known to return an empty page with an HTTP status 204. If for any reason the web page is not returned, or an HTTP response other than 204 is received, then shill marks the service as being in the portal state.

https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection/

Captive portal checks
Firefox's captive portal detector tests whether the network connection requires you to log in. This is sometimes the case when using a public Wi-Fi hotspot. Firefox does this by regularly connecting to http://detectportal.firefox.com/canonical.html. Firefox will also make connections to this URL to check if your current network supports certain technologies such as IPv6.

https://support.mozilla.org/en-US/kb/captive-portal

iOS (latest)
The standard flow for the Captive Network authentication process starts with Wi-Fi association. It doesn’t matter what kind of Wi-Fi association protocol is used (Hotspot 2.0 or other), in all cases just after the association is complete, the device makes a request for an IP-address (DHCP DISCOVER).

After receiving an IP-address, the device goes to check http://captive.apple.com/hotspot-detect.html (exact domain and URI could be different from this one: see appendix for complete list) via so-called CNA Helper.

https://captivebehavior.wballiance.com

[[N]ebsun]

What everyone seems to miss, is trying to understand the reason for the connection in the first place - that is the one and only thing that will determine whether encryption is necessary.
Best guess is that it is how Steam determines that you are online or offline - can you connect to the valve servers or not.. that explains the zero content and plain http connection - since there is no data, there is no need for encryption.
It's as good as if they used a raw tcp / udp packet

[[N]ebsun]

引用自 ShelLuser：

Thanks for proving yourself to be completely clueless on this topic.

ANY of those entries can sign off on certificates to be abused by others. And that's not all: they can also sign off to delegate responsibilities. You know? Allowing others to sign off for 'm.

This is where DNS CAA comes in to patch this type of issue.

[Crashed]

引用自 Nebsun：

What everyone seems to miss, is trying to understand the reason for the connection in the first place - that is the one and only thing that will determine whether encryption is necessary.
Best guess is that it is how Steam determines that you are online or offline - can you connect to the valve servers or not.. that explains the zero content and plain http connection - since there is no data, there is no need for encryption.
It's as good as if they used a raw tcp / udp packet

And it appears the connection is solely for probing the network characteristics of the client's connection. It appears all actual communication is encrypted. More recently this includes downloads, which broke local caching solutions that some used in settings involving multiple computers on the same Internet connection.