This would not matter if there was a md5 + sha1 hash check from a secure source.
It would matter still because without HTTPS it can be learned which downloads are being made and therefore target a person with a specific vulnerability to the specific download
@ekaris I'm just curious, you don't trust your ISP or always use tor\public anonymous proxy\public wi-fi hotspot to access all internet?
If not, then http or https will make a little difference in matter of how secure or insecure your connection.
Since you don't make financial transactions through these locations, or use authentication credentials to access those pages you are pretty safe.
Also, just to mention that SSL certificates could be stolen or faked and will require extra effort from you to check their validity since they will show up in your browser as perfectly valid.
"Other vulnerabilities that are favorite attack vectors? The personal devices employees bring into the office on which they’ve allowed their kids to load Steam games, and which the workers then connect to the network."
Rob Joyce (TAO, NSA) just said Steam games are a security threat #enigma2016
http://www.wired.com/2016/01/nsa-hacker-chief-explains-how-to-keep-him-out-of-your-system/
So ftp.debian.org, and many other mirrors (httpredir for Debian) is htttp/ftp. There is a reason why the packages are signed by a private GPG key against a public key known to everyone.
If you prefer less security and privacy and convenience that's your problem, go comment somewhere else.
I am wondering what the issue really is here. HTTPS would have a major impact on processing times and resources needed to use a Repository and it would add almost no benefits.
HTTPS (or TLS connections) are used to add the following features to a data stream (read: download)
TLS is often used for one of the following reason
http://repo.steampowered.com/steam/ precise steam endpoint, you have actually given them all data allready by requesting the DNS details of the repo, and / or by using the repo's domain.Steam still uses TLS connections to download the applications themselves using there own protocols (which is uniform over all platforms as far as I know).
The integrity of packages by steam are protected by other means (e.a. GPG integrity checks) on both the REPO files as well as the PACKAGE files. they need to have been signed by a key that is accepted by your APT process (or you get a big red warning!, NEVER EVER IGNORE THAT ONE!!!)
You already 'leak' your IP and the DNS & Domain details of the repo you are contacting. regardless of using TLS or not. Adding TLS would there for not add anything as protection against that.
The Repo for steam is ONLY for the Steam Client and Steam OS, and Steam OS Installer. it offers nothing else.
TLS is not the END-ALL solution, you need to understand the implications of using it.
Apt Repositories have several features that would make tls on the endpoint costly (for both client and server). Apt repositories already have an excellent protection system in place against abuse. Using HTTP makes it so that features like cahing / proxyies / mirrors can work without special work or MiTM techniques.
In conlusion these type of Issues should be closed as they are requesting an undesirable state.
I am wondering what the issue really is here. HTTPS would have a major impact on processing times and resources needed to use a Repository and it would add almost no benefits.
In the eye of the beholder. The impact of HTTPS is less CPU and more cost which even then is negligible for CDNs. The bigger impact comes from self inflicted stupidity. Using one connection per request, breaking TCP with low timeouts, etc.
Steam still uses TLS connections to download the applications themselves using there own protocols (which is uniform over all platforms as far as I know).
Very, very few things are over HTTPS with Steam, or the Linux client has other problems.
The integrity of packages by steam are protected by other means (e.a. GPG integrity checks) on both the REPO files as well as the PACKAGE files. they need to have been signed by a key that is accepted by your APT process (or you get a big red warning!, NEVER EVER IGNORE THAT ONE!!!)
Buys you nothing since the key is not cross signed by anyone afaik. The integrity of the install media itself cannot be validated. There is an md5sums file but it too would be intercepted.
You already 'leak' your IP and the DNS & Domain details of the repo you are contacting. regardless of using TLS or not. Adding TLS would there for not add anything as protection against that.
Ohh trust me I'm aware of that. SNI is equal to Satan, been saying that for years. One of my old posts from another site is frequently cross posted.
The Repo for steam is ONLY for the Steam Client and Steam OS, and Steam OS Installer. it offers nothing else.
Which for the sake of this, is basically everything.
TLS is not the END-ALL solution, you need to understand the implications of using it.
Apt Repositories have several features that would make tls on the endpoint costly (for both client and server). Apt repositories already have an excellent protection system in place against abuse.
APT does, yes.. when setup properly (ironically I don't think even their keys are cross signed, though the details are more widely distributed). What you're missing though is even apt, can be broken if a trusted key is installed or modified binaries. I realize that may sound far fetched but it isn't.
Using HTTP makes it so that features like cahing / proxyies / mirrors can work without special work or MiTM techniques.
You're half correct, HTTP does make transparent proxies possible and more likely the reason Valve is still using it. The cost of a cert certainly isn't part of the equation.
The second part of that however is a requirement - you have to MITM, it's what a traditional proxy does ( other acceleration techniques are outside the scope of this). If not, you're consciously using a proxy.
One of the advantages to using things like Let's Encrypt and the way some providers present their cdn (rackspace or cloudfront for example), isn't that they are magically more secure because they use a different version of SSL. It's the obfuscation of server names. Whether by design or not, that handles one of the biggest blunders in SSL - the sni leaking case.
From OCSP validation to hsts cert pinning, everything ELSE about SSL and current mitigations, are as fundamentally broken as Intel CPUs.
In conlusion these type of Issues should be closed as they are requesting an undesirable state.
Undesirable to clueless network operators and third parties, sure. End user is better off with SSL.
In the eye of the beholder. The impact of HTTPS is less CPU and more cost which even then is negligible for CDNs. The bigger impact comes from self inflicted stupidity. Using one connection per request, breaking TCP with low timeouts, etc.
I specifically mention resources (this is much more than just CPU) CDN's I did not even mention (and are the used delivery network strategy is not really important)
...
Very, very few things are over HTTPS with Steam, or the Linux client has other problems.
I just tested this with wireshark. as far as I can tell with a quick look at the protocol and its calls, it Steam uses the api.steampowered.com and that uses a TLS connection for all communication.
...
Buys you nothing since the key is not cross signed by anyone afaik. The integrity of the install media itself cannot be validated. There is an md5sums file but it too would be intercepted.
Since the initial installation is through a .deb file downloaded over HTTPS (using your browser), and this package includes the certificate details to verify the repository. Apt knowns what key to expect and use for validation. Unless you use a disreputable source that tries to hijack the steam repo's with there own the APT system protects the enduser with integrity checks (not just md5, but also cryptographic) and it also means that you can authenticate the source (its public key is present in the APT-Key repository and offers positive validation mechanism (e.a. it rejects if he key is not what it expects)
...
Ohh trust me I'm aware of that. SNI is equal to Satan, been saying that for years. One of my old posts from another site is frequently cross posted.
SNI is a solution for the problem of 1 IP per TLS certificate. It does leak the domain in clear text but it offers the capability to use more than 1 certificate on a specific endpoint.
...
Which for the sake of this, is basically everything.
I would inject that not beeing about PII is significant. Also it is not about the account details themselves.
APT does, yes.. when setup properly (ironically I don't think even their keys are cross signed, though the details are more widely distributed). What you're missing though is even apt, can be broken if a trusted key is installed or modified binaries. I realize that may sound far fetched but it isn't.
Cross signing mean just as much as CA's... diddly squat. (but that is a totally different discussion).
Yes, apt depends on proper care of its keys file (the GPG thrust database that is APT specific). This key file is not shared with the user directly. but indeed ROOT can mess them up. Also if the APT programs themselves are infected through some means you got a problem. The main theme with all of these attacks is that if they apply you got much bigger problems than just 'steam'
You're half correct, HTTP does make transparent proxies possible and more likely the reason Valve is still using it. The cost of a cert certainly isn't part of the equation.
Cost here is NOT the price of the certificate you 'buy' form a CA.
Cost is the price of implementation AND price of distribution of 'secrets'.
The second part of that however is a requirement - you have to MITM, it's what a traditional proxy does ( other acceleration techniques are outside the scope of this). If not, you're consciously using a proxy.
You do not want to know how many issues I get about people that use a proxy without there knowledge (getting old cached results from ISP / Corporate level Proxies)
One of the advantages to using things like Let's Encrypt and the way some providers present their cdn (rackspace or cloudfront for example), isn't that they are magically more secure because they use a different version of SSL. It's the obfuscation of server names. Whether by design or not, that handles one of the biggest blunders in SSL - the sni leaking case.
So you supplant SNI leaking with public listing of server names though Certificate Transparency Reports (Let's Encrypt uses that). What are the risks with SNI? the way DNS works means that any observer already knows what Domain you are trying to access. SNI Also lists this information. Yes SNI means that Every packet has the information and the DNS is only transmitted once in a while. It is a tradeoff, one that is reasonable in my opinion especially considering the alternative would mean most domains could not use TLS these days without it.
From OCSP validation to hsts cert pinning, everything ELSE about SSL and current mitigations, are as fundamentally broken as Intel CPUs.
what exactly about TLS is as broken as "lets fetch cache results with secrets even if we do not need them / are allowed to access them" ?
TLS is not perfect, its protection techniques are either broken, flowed or not proven. But I fail to see how a combination of techniques (like DNSSEC, CAA records, DANE records and HTST) are as broken as you describe. IT-SEC is a hard subject. and requires cooperation between many different parties and interests. All have to agree on hoe we solve these problems. So if you have issues with the current solutions, by all means tell the world. (and tell the https://datatracker.ietf.org/wg/tls/about/ commite especially about your issues). We as a community / society can than start to fix these issues.
Undesirable to clueless network operators and third parties, sure. End user is better off with SSL.
Everybody should stay clear of SSL (its broken). use TLS. Also I would suggest you read up on Debian / Ubuntu's policies regarding APT. or if you prefer Redhat's policies regarding RPM repositories they are more or less the same. Simply put. when other mechanisms are in place to ensure confidentiality, integrity and authenticity, do not use HTTPS as it will only nagatively impact your system and can even degrade the security that the other system offers. (Also, and this is as always a given. DO NOT ROLL YOUR OWN SECURITY! Use proven technology that has withstood the test of time)
In the eye of the beholder. The impact of HTTPS is less CPU and more cost which even then is negligible for CDNs. The bigger impact comes from self inflicted stupidity. Using one connection per request, breaking TCP with low timeouts, etc.
I specifically mention resources (this is much more than just CPU) CDN's I did not even mention (and are the used delivery network strategy is not really important)
What on Earth are you talking about?
I am wondering what the issue really is here. HTTPS would have a major impact on processing times and resources needed to use a Repository and it would add almost no benefits.
.. the "network strategy" has EVERYTHING to do with this. May not fit your narrative, sure.
Very, very few things are over HTTPS with Steam, or the Linux client has other problems.
I just tested this with wireshark. as far as I can tell with a quick look at the protocol and its calls, it Steam
uses the api.steampowered.com and that uses a TLS connection for all communication.
Right, I never said otherwise. Again, what are you talking about? It's everything ELSE that isn't.. But reading below I'm starting to understand where you're coming from.
Buys you nothing since the key is not cross signed by anyone afaik. The integrity of the install media itself cannot be validated. There is an md5sums file but it too would be intercepted.
Since the initial installation is through a .deb file downloaded over HTTPS (using your browser), and this package includes the certificate details to verify the repository.
Don't think you fully understand the attack surface but I'll address your initial install scenario: It's not. Unless you're referring to some other repo, the current download comes from
http://store.steampowered.com/about/
The deb itself is
https://steamcdn-a.akamaihd.net/client/installer/steam.deb
Neither the protections from SSL (nor if we are being pedantic, TLS), give you anything. The initial store page is over HTTP.
Apt knowns what key to expect and use for validation.
It knows what it's told, nothing more.
Unless you use a disreputable source that tries to hijack the steam repo's with there own the APT system protects the enduser with integrity checks (not just md5, but also cryptographic) and it also means that you can authenticate the source (its public key is present in the APT-Key repository and offers positive validation mechanism (e.a. it rejects if he key is not what it expects)
Which is what MITM does. Further steam does not require a system wide install.
Ohh trust me I'm aware of that. SNI is equal to Satan, been saying that for years. One of my old posts from another site is frequently cross posted.
SNI is a solution for the problem of 1 IP per TLS certificate. It does leak the domain in clear text but it offers the capability to use more than 1 certificate on a specific endpoint.
SNI is sold as that yes. My argument is the ends do not justify the means, it's an entirely false sense of security. You are correct however, it was implemented to satisfy that requirement. Unfortunately it throws everything else out the window.
Which for the sake of this, is basically everything.
I would inject that not beeing about PII is significant. Also it is not about the account details themselves.
It's absolutely about account details, and everything else.
APT does, yes.. when setup properly (ironically I don't think even their keys are cross signed, though the details are more widely distributed). What you're missing though is even apt, can be broken if a trusted key is installed or modified binaries. I realize that may sound far fetched but it isn't.
Cross signing mean just as much as CA's... diddly squat. (but that is a totally different discussion).
Yes, apt depends on proper care of its keys file (the GPG thrust database that is APT specific). This key file is not shared with the user directly. but indeed ROOT can mess them up. Also if the APT programs themselves are infected through some means you got a problem. The main theme with all of these attacks is that if they apply you got much bigger problems than just 'steam'
A trust which can easily be broken. Again, there is no security in it.
You're half correct, HTTP does make transparent proxies possible and more likely the reason Valve is still using it. The cost of a cert certainly isn't part of the equation.
Cost here is NOT the price of the certificate you 'buy' form a CA.
Cost is the price of implementation AND price of distribution of 'secrets'.
Unless you're planning to buy the certificate from some other budget (ie, not yours), it most certainly IS part of any implementation cost. That cost alone can be significant, my point was for valve it isn't.
The second part of that however is a requirement - you have to MITM, it's what a traditional proxy does ( other acceleration techniques are outside the scope of this). If not, you're consciously using a proxy.
You do not want to know how many issues I get about people that use a proxy without there knowledge (getting old cached results from ISP / Corporate level Proxies)
And you don't know how many times I've had to walk clients "IT Security department", through properly setting up their bastardized configs. Let alone explain caching to them. Here's a hint, remove advertisers abusing caching and HTTP works as it's supposed to. And yes, that includes chains of proxy authentication.
One of the advantages to using things like Let's Encrypt and the way some providers present their cdn (rackspace or cloudfront for example), isn't that they are magically more secure because they use a different version of SSL. It's the obfuscation of server names. Whether by design or not, that handles one of the biggest blunders in SSL - the sni leaking case.
So you supplant SNI leaking with public listing of server names though Certificate Transparency Reports (Let's Encrypt uses that). What are the risks with SNI? the way DNS works means that any observer already knows what Domain you are trying to access. SNI Also lists this information. Yes SNI means that Every packet has the information and the DNS is only transmitted once in a while. It is a tradeoff, one that is reasonable in my opinion especially considering the alternative would mean most domains could not use TLS these days without it.
There are some rather large sites that still set absurdly short TTLs, "once in a while", is quite misleading.
Again the ends do not justify the means. There is no security. The mere mention of the fact that tls blabs to the world about what you're connecting to, was enough to get you shadowbanned on some sites (slashdot for example). Regarding LE, I thought it used something similar to the others - cloudflare for example using sni#xxxxxx.cloudflaressl.com and ssl#xxxxxx.cloudflaressl.com addresses.
From OCSP validation to hsts cert pinning, everything ELSE about SSL and current mitigations, are as fundamentally broken as Intel CPUs.
what exactly about TLS is as broken as "lets fetch cache results with secrets even if we do not need them / are allowed to access them" ?
If you've taken the steps to implement proper cache expiry and your CDN is not adhering to them, open a support ticket. Otherwise that is an implementation problem not service provider. On the other hand if you are the provider.. start typing your resume? Or are you being pedantic again conflating DRM requirements with design oversights? Forcing something to expire in a browser and using that as a security argument is a flimsy one at best. Dangerous if used where actual data protection is required.
TLS is not perfect, its protection techniques are either broken, flowed or not proven. But I fail to see how a combination of techniques (like DNSSEC, CAA records, DANE records and HTST) are as broken as you describe. IT-SEC is a hard subject. and requires cooperation between many different parties and interests. All have to agree on hoe we solve these problems.
DNSSEC is a bit different from HTST. If you control the DNS you control anything asking, that includes removing any signing or authentication boltons. Absent any side channel data, the client is unaware of what to trust. See HTST for flawed solution.
HTST only protects sites that are part of the club.. and it's a small one. For the most part the attacks are the same as any WOT, you're agreeing to someone else vetting trust. To an even larger degree it's obscurity since less people know what it even is. I don't know that all browsers even support a way for users to see what is pinned vs preloaded let alone adequately allow consent. And don't get me even started on what happens when THOSE keys get compromised either through legal demand or otherwise.
So if you have issues with the current solutions, by all means tell the world. (and tell the https://datatracker.ietf.org/wg/tls/about/ commite especially about your issues). We as a community / society can than start to fix these issues.
Kind of ironic a lot of this is not new, the IEFT are well aware of the attacks if not complacent in their development of processes that do nothing more then move goal posts, allowing security companies to sell "updated" wares. If I had to guess I'd say webscokets were a quiet push toward fixing it but again, it's a technology being abused already not by Russians but high profile sites as a way around conventional protection. There's no reason a browser can't warn users by default, about persistent connections and crap like webworkers. Also no reason sites aren't called out for their crap either.
Undesirable to clueless network operators and third parties, sure. End user is better off with SSL.
Everybody should stay clear of SSL (its broken). use TLS. Also I would suggest you read up on Debian / Ubuntu's policies regarding APT. or if you prefer Redhat's policies regarding RPM repositories they are more or less the same.
.. and broken in this case for reasons outlined above.
Simply put. when other mechanisms are in place to ensure confidentiality, integrity and authenticity, do not use HTTPS as it will only nagatively impact your system and can even degrade the security that the other system offers. (Also, and this is as always a given.
Both have problems and afaic neither offer any of that since they are based on either preshared trust or ambiguous if not misleading promises of it.
DO NOT ROLL YOUR OWN SECURITY! Use proven technology that has withstood the test of time)
At least that we can agree on.
steam is HTTPS secured since some time now, using http://store.steampowered.com/about/ simply redirects to the HTTPS version, can close this and https://github.com/ValveSoftware/steam-for-linux/issues/4449 now
This issue report is for repo.steampowered.com, not the store. That detail set aside, this has been fairly thoroughly discussed and the original user has turned into a ghost.