BTW - this certificate was revoked. -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Mark Steward via dev-security-policy Sent: Friday, December 29, 2017 11:30 AM To: Matthew Hardeman <mharde...@gmail.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)
On Mon, Dec 25, 2017 at 7:50 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Part of the trouble in relying upon the name alone is that on many > OS's (maybe all -- at least all the ones that matter for client side > work) can have localhost overridden to mean other things. > > The main issue I see is that it effectively breaks SOP. It's not reasonable to expect a user to know what app is listening on what port whenever a browser connects, or to ensure that only Battle.net could listen on 28866. > ... If I recall correctly, this is actually more of a thing for WebSockets. > > If my recollection is correct, Chrome already considers > http://localhost or is it http://127.0.0.1 to be a secure origin in > nature. Thus, code which arises from a request to localhost is > treated as running within a secure context, even if it is not wrapped > in a TLS connection. (You can run javascript and access APIs in such > circumstances on localhost via HTTP when ordinarily Chrome would > require HTTPS to enable that access.) > > However... That doesn't help the web developer who is trying to > access a WebSocket service on localhost. While Chrome regards the > localhost as a secure origin, WebSockets in Chrome (and every other > mainstream browser?) require the connection to be a TLS wrapped one, > regardless of whether or not it's from a secure origin. > > (I wonder if they even wrote a protocol handler for non-secure web > sockets? At the moment, it's Christmas and I'm being too lazy to > look.) > > If by non-secure websockets you mean ws://, then yes, and Chrome is lax here in that it allows access to ws://localhost from https:// without logging a Mixed Content warning (Firefox only allows ws://localhost from http://). I think the real issue is (anticipated) fallout of the move to HTTPS by default, possibly along with the deprecation of Flash. I don't think there's a clean solution for creating a socket from a website to an app on the local machine, except maybe via WebRTC? Mark _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
