Far too many do it. I think the technique is repugnant garbage that the browsers themselves should solve.
Spotify historically did this, too. The idea is that rich-client software on the PC has a daemon running in the background on one of a number of chosen TCP ports. Usually it implements WebSockets. When a user in a regular browser comes across an appropriate website, that website is able to cause the browser to load resources from the daemon on the localhost system. They use this for things like determining whether the rich-client is installed and if so, what version. Also for exercising simple control over the software on the PC. These certs started being used because Chrome would not allow WSS connections on non-https. It would be incredible if a page that loads from a URI not resolving to an IP endpoint on the local host were unable to load any sub-resources, any time, under any further conditions via connections to any IP endpoint on the local host. That change to the browser will kill the use case that keeps causing software companies to get certificates like this. It will also kill of a lot of use cases that should probably be killed. For example, is there ever a legitimate reason that visiting a website should be able to quietly access services running on various TCP sockets on your PC? (Yes, theoretically there are, but the risks seem to way outweigh the reward.) On Thu, Dec 21, 2017 at 9:18 AM, Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi, > > Tavis Ormandy recently tweeted this: > https://twitter.com/taviso/status/938503794098180096 > > What's happening here: The software battle.net by Blizzard has a domain > localbattle.net that points to localhost, allowing the software to > serve content there. The content is served via HTTPS with a valid cert, > making it obvious that the private key is part of the software. > > I talked to Tavis, reported the issue to the CA and to Mozilla's > bugtracker. I learned that there's a practically identical issue with > EAs origin.net software. > I also heard a claim that "everyone does this", however this seemed to > refer to examples from the past that are already known. I briefly > checked other gaming software (steam, uplay), but didn't find anything > alike. (Which doesn't mean it's not there - but I didn't see open > ports after running the software that were served with TLS.) > > Both certificates have been revoked. I don't have any detailed > information about what these local connections were used for, if they > changed anything and if anything broke due to the revocations, but I > haven't seen any reports of breakage (I checked twitter for signs of > it). > I also was not able to extract the private keys with simple methods > (grep), but it is almost certainly possible. (Full disclosure: Doing > anything on a Windows system is not my strength.) > > In any case: If you are aware of other software doing something alike > please report it. This is a key compromise. > > Bug EA: > https://bugzilla.mozilla.org/show_bug.cgi > Cert EA: > https://crt.sh/?id=54134792 > > Bug Blizzard: > https://bugzilla.mozilla.org/show_bug.cgi?id=1425166 > Cert Blizzard: > https://crt.sh/?id=277776142 > > -- > Hanno Böck > https://hboeck.de/ > > mail/jabber: ha...@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
