Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
Hundreds, and I wish I was joking.
I've seen it so wearingly often that I just started ignore them as honestly Microsoft's warnings cant be trusted when it comes to webpages for junk to start with anyways.
I did an experiment; I captured network traffic with Wireshark while Steam was starting up. Exactly one unencrypted http connection was made. Steam sent this to test.steampowered.com:
and test.steampowered.com replied with:
There's really nothing dangerous at all about that; basically, it's just like if you clicked on a http://test.steampowered.com/204 link. Judging by the hostname, it looks like they're testing for something specific; one thing you might want to test this way is if you're on a public WiFi network which makes you login through a web portal.
On networks like those, they'll intercept and modify HTTP connections, and other types of connections will fail. A test like this on those kinds of networks will return something other than "204 No Content", so it would be a good way to test for that.
And well, the use of HTTP isn't bad at all. In fact, for some specific usage it's even preferred. Meh, one of the main reasons major browsers like Edge and Chrome are pushing for HTTPS is pure commerce.
Just because a process is using HTTP does not imply insecurity, not at all!
It prevents anyone to look at the data and prevents anyone from modifying the data.
Which means it also prevents anyone from attempting to inject anything that would result in specific attacks on the software that originally started the request. Like, say, a buffer overflow attack - or a specific attack against a known bug in whatever code the software uses to parse the contents of a request that results in exploitable memory corruption. This type of exploit is a stupidly common attack vector, to the point that many, many man-hours are sunk into patching any vulnerabilities related to it.
The Steam Service (steamservice.exe) runs under the SYSTEM account. It has absolutely zero business making any network connections that are not encrypted. The OP is absolutely right that this is a huge security risk in the event that Valve manages or managed to stuff anything up in how they handle returned responses which could lead to an exploitable vulnerability to achieve remote code execution with full elevated system permissions.
There is zero added value for HTTP over HTTPS nowadays. HTTP/2 is stupidly fast compared to HTTP 1.1 and de-facto only allowed over secure connections, meaning HTTP 1.1 can't use it. The speed boost HTTP/2 gives means overhead for encryption on the connection has not just become negligible but downright an absolute non-issue - because a non-encrypted HTTP 1.1 connection literally can be 10 times slower than an encrypted HTTP/2 connection.
Try it out for yourself: http://www.httpvshttps.com/
You are right about one thing though:
The choice for HTTP vs HTTPS is one traditionally centered in commercial reasons.
That is: HTTPS certificates take money and upkeep that businesses are too cheapskate to afford.
Luckily nowadays there are well-received and recognized initiatives like Let's Encrypt that make basic certificate services available for free; if you can't afford to pay for them, or are too much of a penny-pincher to do do.
It is only not more unsafe if you work off of the dangerous assumption that the code processing the response will have been written absolutely perfect with no possible errors in it that could serve as an attack vector. As for valid reasons to use unencrypted connections. No; those don't really exist anymore. Maybe if you're still stuck needing to support extremely legacy devices that can't do HTTP/2 and you want to wholly cater your performance profile to them by using unencrypted HTTP/1.1 for e.g. assets like image or video, or something. But that is an outlier and possibly also simply not worth it anymore.
Because if a person actually has that kind of access to your data stream then it's childishly simple to set up a man in the middle attack: now the data between you and the attacker gets encrypted, the attacked decrypts it, modifies it and then sends it along onto their encrypted connection with the destination.
What you're completely overlooking here is that the encryption process is fully automated, worse yet: it's actually started by exchanging keys between client and server, which gives an attacker all the tools they need to intrude.
HTTPS is merely an encryption layer, no more and no less and in the end it provides 0 extra security.
Computer security isn't a switch you can turn on or off; it's an ever ongoing process.
It is possible the HTTP connection as mentioned in a previous post could be a probe to detect network tampering, and as such should not pose a security risk provided the receive buffer and parser are properly hardened against corrupted data exploits.
As for the httpvshttps site, Steam does not appear to have their Akamai CDNs set up to support HTTP/2 so it will only run at HTTP/1.1 performance levels. That site uses http/2 on their demo site, which by the way has a speed very much affected by processor speed; perhaps it's the browser rendering that becomes the bottleneck when https is loaded.
Most of all, let's not kid ourserves: certificates as you call them are nothing more but public keys either fully trusted and thus self-signed or signed by a trusted authority.
Signing is done through (public) keys.
As for trust... you really don't know what you're talking about: the trust factor is implied by certificates that are stored on your OS: they sign those other certificates. Unfortunately... those are also easily spoofed. Thanks to commerce.
LOOK at your trust factory for a change instead of spouting off nonsense and see that there are dozens of root certificates in your Windows or OSX trust store that do not uphold the same line of reasoning as you do. Weakest link in the chain anyone?
https://i.imgur.com/W3IBI5n.png
Do you really feel safe with that in your Windows trust library?
Also notice the amount of entries in there? Any one of those can issue a "wrong" certificate and lo and behold: that has happened before. In the past few years an increasing number of CA's have been warned about issuing certs for public domains, like google.com.
Sorry for the harsh words but you're completely delusional if you think that HTTPS helps keeping you safe, because it doesn't.
Kudos to you
Nice explanation and evidence, have some points
Someone else can't use that to sign a MITM device since the trust library only contains public keys and not the private keys required to sign a certificate.
The root you showed is a timestamping certificate which is kept solely for the purpose of backwards compatibility with code signing certificates timestamped during its validity and cannot be used to sign website domains.
CAs found to have inappropriately signed server certificates are always intermediates that get revoked by the CA above them, either another intermediate or the root CA.
One could argue HTTPS MITM happens at CDNs but keep in mind in the scope of this conversation the CDN is the webserver and is provably operating publicly on its advertised domain. MITM attacks against HTTPS connections between a client and a site on the public Internet occur when the attacker not only taps the line but installs a malicious root certificate on the client for which the attacker holds the private key and can sign certificates at will.
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.
I only focussed on Microsoft because of the long last expiration date and that is what makes your reaction hilarious and why I said the above things. Because that entry could never have done any of what you suggested. The certificate is invalid in the first place, there's no way around that.
If you knew what you were talking about you would have recognized the obvious.
If you knew what you were indeed talking about Shell you'd understand that you can literally open a notepad and type up a HTTP code, I did that in school for webpage design, guess whats funny? I didnt need cookies to do it.
For example: If you get an error that says you have a ASP NET error, thats normal as microsoft has long updated to just .NET protocol instead, thats just what is known as a token-mismatch error, the tokens are the same, its just that the site protocol name is not.
If we took Steam which uses Doctype HTTP format, or known as Document type declaration, this means its using a more modern set of HTTP tokens and codes related to Markup language, meaning that if one was to accept to access the page where ones account is, they'd meet an instant Syntax error as they dont have Steams special HTTP Doctype access framework.
Its funny how these things work but basically your PC is not understanding the off-grid remote sites, simply as it does not have the language HTTP framework to do so, thats rather normal actually if anything.