On Thursday, December 21, 2017 at 7:38:59 PM UTC-5, Matthew Hardeman wrote:
> 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
> >

>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, there is and isn't this entirely the point of CORS/RFC1918? Nonetheless, 
web applications that offer remote desktop capabilities are going to need to 
eventually access resources on a local network. 

It is possible to do this properly. Building a PKI around Lets Encrypt is 
exactly how we avoided contributing to this mess; the suggestion of breaking 
websockets and removing all ability to connect to local resources in the name 
of "security" is pretty backwards.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to