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).
> 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)
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.
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.
