Comment by Saaster | Hacker News Reader

Comment by Saaster | Hacker News Reader

Parent Full thread

Companies receive so many "First, you have to be on the other side of this airtight hatch, then you..." reports that anything that looks even remotely like it will just get summarily closed. My personal favorite ones start with some form of "I copied the user's cookies from device A's file-system, and..."

Just some suggestion on how to report these kind of things, because there is an actual underlying issue here worth fixing. It's good that you didn't mention the reverse proxy. Next, don't say "spoofing an HTTP request" in your first sentence of the report, that's an immediate red flag. If you have access to spoof something on the network, it's already not an issue for 99% of people and an instant low priority. Instead, say "Steam insecurely relies on a redirect response to upgrade the hosted content from HTTP to HTTPS, instead of directly establishing the HTTPS connection". How this can be exploited is now much more general than just being a spoofing issue, with both the problem and solution clearly stated.

I've been on both sides of this, and sadly having HackerOne/BugCrowd as intermediaries often hurts more than it helps.

On one hand I've had to sort through the never ending stream of "if you bypass the safeguards first" issues and some guy in India copying and pasting open source vuln scanner reports. I get why people don't want to deal with this and outsource it.

On the other hand, I have a legitimate exploit against GitHub that is "working as intended" for months now. No amount of back and forth is going to convince them that leaking commit messages on enterprise accounts is serious apparently.

> No amount of back and forth is going to convince them that leaking commit messages on enterprise accounts is serious apparently.

If true, this deserves a write-up.

I'm sure a few enterprise accounts might agree, if anyone can see their dev-branch commit named "feature xyz" a month before they announce it.

Joke's on you:

    trying to fix bug
    maybe this?
    fuck
    idk
    idk
    idk
    maybe works
    k ready now

But also: "fix stupid fucking sql injection"

This sounds far worse than just leaking branch names. They said it’s leaking entire commit messages.

Those messages could contain very detailed descriptions of how a companies product works, or how a companies fraud controls operated.

Sorry, that's what I meant. I should rephrase: a commit message for a commit on the dev branch.

I was assuming a relatively lazy commit message as an example. You're correct in identifying that certain organizations might put a lot of information into a commit message.

Can you publish more details? Consider pastebin, github, personal blog, anywhere you can really.

Enterprises, as in publicly traded companies, should definitely not be leaking products and roadmaps because this affects their stock values. I bet you regulators won't like that and it will be fixed in a heartbeat.

edit: there is the CEO owner of github commenting on another front page article, might want to drop a word. https://news.ycombinator.com/item?id=22867627

Simply say that there is a typo in the steam configuration, it is connecting to the (insecure) URL http://...

This allows steam network traffic to be intercepted. It can be fixed by correcting the URL to https.

For example, somebody using steam from a coffee shop could have his credentials/cookies/accounts intercepted by the coffee shop operator or any other visitor.

I believe coffees and other gaming venues are a supported use case for steam and you do not wish to leave your users at risk.

IMO There is really no need to blow this out of proportion. It's just a typo. Developers make typos all the time. Bet they're more likely to double check something trivial like that if pointed to.

This is most likely not a typo. The redirect from http to http is most likely due to valve using a self signed ssl certificate and not directly exposing it to ATS, (iPhone). If they went directly to the https endpoint the OS would block the traffic to an invalid, (not CA authority signed), SSL certificate.

store.steampowered.com is a fully web accessible site with a CA signed certificate though. It's the main steam marketplace. I think the whole point is that they are leveraging this for their app, so using a self-signed CA doesn't make a lot of sense in that case (not that I'm sure it ever would for a company these days, SSL certs are cheap).

I don't think you understand. There is no such thing as a "self-signed" CA cert, (its one or the other). This not about money, it's about control. There are many benefits to using a self-signed SSL cert over purchasing a CA one. However, Apple and Android inherently distrust self-signed certs so you have to actually provide the cert directly to ATS/Android OS which involves bundling it within the app, (a messy process). The current industry "hack" is to use http within the app, and then re-direct to https, (which is exactly what the steam app does).

I understand, I mis-typed. I meant self-signed cert. That should have been pretty obvious from what I actually posted though.

https://store.steampowered.com is the official steam marketplace. It does not use a self-signed certificate.

> There are many benefits to using a self-signed SSL cert over purchasing a CA one.

I'm sure there are (not that any are immediately coming to mind), but this is the official web marketplace. It is NOT self-signed. It's signed by DigiCert, Inc, which is easy to check if you go there.

To clarify, store.steampowered.com is not some special app store subdomain. It's the official store, and where you are redirected in a browser if you go to steampowered.com. It is very unlikely they are using a self-signed certificate given it's an actual web address used by many tens of millions of people in their browsers primarily.

I'm not a valve developer so I can't tell you exactly what is happening, but you most certainly can serve different certificates to browser vs mobile. The apps are using WebViews which are not the same as Chrome and Mobile safari. It would make sense to us a CA cert for normal browser traffic as it is fairly sandboxed as far what you can and cannot do, the WebViews are a completely different environment.

Again I'm saying this based on real world experience with why someone would use http instead of https, so my point is just a guess. I might be giving Valve too much credit and trying to explain something that is just a mistake. I am basing my theory on the fact that the http endpoints immediately re-direct to https ones, so it seems to be intentional for one reason or another.

> I am basing my theory on the fact that the http endpoints immediately re-direct to https ones, so it seems to be intentional for one reason or another.

I don't know, that seems pretty bog-standard to me. You redirect to HTTPS when someone requests HTTP when you want your traffic to all be secure. At least, that's how it used to be, these days browsers be be more aggressive in trying to hand you to the HTTPS version of sites if port 80 doesn't respond, and in that case it might make more sense to turn down port 80 as long as all browsers do the right thing.

>There is no such thing as a "self-signed" CA cert, (its one or the other).

Not sure what you're trying to say here. What a cert is signed by and what a cert's usage is set to are orthogonal things. There are CA certs that are self-signed (look in your OS's trusted roots cert store) and there are CA certs that are signed by other CA certs (intermediate CA certs).

You can create your own CA and then add it to the trust/keystores of your applications. It's exactly the same thing that public CAs are doing. They strike a deal with browsers and operating systems and get added to those stores.

There is a lot of software that assumes that all connections signed with a given CA are trusted. You wouldn't want to use a public CA in that case because random people could access your services. Want to encrypt mongodb traffic? Create your own private CA. Want to encrypt zookeeper (or etcd for kubernetes) traffic? Create your own private CA. Each server and client gets its own certificate signed with that private CA and since only that private CA is marked as trusted it can be used to authenticate servers and clients. It's basically the same idea as if you had a cryptographically signed token such as JWT. (the private key of the CA is the shared secret)

Why does the redirected request accept a self-signed cert, but the initial request doesn't? That seems weird.

It depends on how the app is displaying the link. They could be setting all sorts of cookie info/metadata in the original http request. There are many answers as to why it is accepted. I'm obviously not the developer of the valve app so I can't tell you exactly.

What doe cookies and metadata have to do with certificate validation?

The http link could theoretically be serving the cert to the device. I'm not sure WHY they would do this, just guessing. However, the redirect makes it seem intentional for whatever reason.

> Companies receive so many [...] reports

If only Valve could hire a subcontractor whose task it was to triage and clarify theses reports...

The domain and what they are reading off of that filesystem matters though. Like for example, if there was a credential that is in the clear/poorly encrypted and used in other parts of your system.

Reply on news.ycombinator.com