Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Thursday, June 22, 2017 at 6:29:17 AM UTC-5, Jakob Bohm wrote: > The most obvious concern to me is random web servers, possibly through > hidden web elements (such as script tags) gaining access to anything > outside the Browser's sandbox without clear and separate user > action. For example,

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On 21/06/2017 22:01, andrewm@gmail.com wrote: On Wednesday, June 21, 2017 at 1:35:13 PM UTC-5, Matthew Hardeman wrote: Regarding localhost access, you are presently incorrect. The browsers do not allow access to localhost via insecure websocket if the page loads from a secure context.

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

Looking into this, we revoked the cert on our end at 2:20 MST (within 24 hours after the certificate problem report was processed), but we distribute all of our OCSP responses through CDNs. Distribution through the CDN took approximately an hour plus. I couldn't find a definition of revoked in

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Tue, 20 Jun 2017 21:23:51 +0100 Rob Stradling via dev-security-policy wrote: > [CC'ing rev...@digicert.com, as per > https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00028] > >

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Wednesday, June 21, 2017 at 1:35:13 PM UTC-5, Matthew Hardeman wrote: > Regarding localhost access, you are presently incorrect. The browsers do not > allow access to localhost via insecure websocket if the page loads from a > secure context. (Chrome and Firefox at least, I believe do not

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

And a common practice. Old Microsoft documentation used to recommend it. > On Jun 21, 2017, at 12:22 PM, Santhan Raj via dev-security-policy > wrote: > > On Wednesday, June 21, 2017 at 12:02:51 PM UTC-7, Jonathan Rudenberg wrote: >>> On Jun 21, 2017, at

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Wednesday, June 21, 2017 at 12:02:51 PM UTC-7, Jonathan Rudenberg wrote: > > On Jun 21, 2017, at 14:41, urijah--- via dev-security-policy > > wrote: > > > > Apparently, in at least one case, the certificate was issued directly(!) to > > localhost by

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

> On Jun 21, 2017, at 14:41, urijah--- via dev-security-policy > wrote: > > Apparently, in at least one case, the certificate was issued directly(!) to > localhost by Symantec. > > https://news.ycombinator.com/item?id=14598262 > >

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Wednesday, June 21, 2017 at 12:41:53 PM UTC-5, andre...@gmail.com wrote: > I feel like this is getting sort of off-topic. Web pages can communicate > directly with applications on the local machine regardless of whether they > abuse certificates in this way or not. (Such as, for example, by

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Wednesday, June 21, 2017 at 11:51:27 AM UTC-5, Matthew Hardeman wrote: > On Wednesday, June 21, 2017 at 4:59:01 AM UTC-5, Ryan Sleevi wrote: > > > > > There are several distinct issues: > > 127.0.0.0/8 (and the associated IPv6 reservations ::1/128) > > "localhost" (as a single host) > >

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Wednesday, June 21, 2017 at 4:59:01 AM UTC-5, Ryan Sleevi wrote: > > There are several distinct issues: > 127.0.0.0/8 (and the associated IPv6 reservations ::1/128) > "localhost" (as a single host) > "localhost" (as a TLD) > > The issues with localhost are (briefly) caught in >

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

Does anyone have an idea of how good browser support is for the W3C Secure Contexts standard? Could it be that vendors are abusing certificates in this way in order to get around communications with loopback addresses being blocked as insecure mixed content by non-conforming browsers? On Wed, Jun

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Wed, Jun 21, 2017 at 5:32 AM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I believe the underlying issue for many of these cases pertains to > initiating a connection to a WebSocket running on some port on 127.0.0.1 as > a sub-resource of an

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Wednesday, June 21, 2017 at 1:43:18 AM UTC-5, jacob.hoff...@gmail.com wrote: > > It's been an on-going question for me, since the use case (as a software > > developer) is quite real: if you serve a site over HTTPS and it needs to > > communicate with a local client application then you need

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

> It's been an on-going question for me, since the use case (as a software > developer) is quite real: if you serve a site over HTTPS and it needs to > communicate with a local client application then you need this (or, you > need to manage your own CA, and ask every person to install a >

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

On Tuesday, June 20, 2017 at 2:15:57 PM UTC-5, annie nguyen wrote: > Dropbox, GitHub, Spotify and Discord (among others) have done the same > thing for years: they embed SSL certificates and private keys into their > applications so that, for example, open.spotify.com can talk to a local >

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

For your information: I have reported this issue to Spotify on Monday (yesterday) through their official vulnerability disclosure channel (HackerOne). The (not-yet-public) issue was assigned ID 241222. In the report I have included all the necessary (technical) details, including citations of

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

[CC'ing rev...@digicert.com, as per https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00028] Annie, "but these have been known about and deemed acceptable for years" Known about by whom? Deemed acceptable by whom? Until

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

Previous certificates for GitHub and Dropbox have been revoked for this reason. If this problem has been reintroduced, they similarly need to be revoked. On Tue, Jun 20, 2017 at 4:57 PM annie nguyen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi! > > I'm not sure

When are public applications embedding certificates pointing to 127.0.0.1 OK?

Hi! I'm not sure if this is the correct place to ask (I'm not sure where else I would ask). I'm so sorry if this message is unwanted. Earlier this week, a certificate for a domain resolving to 127.0.0.1 in a Cisco application was revoked, because it was deemed to have been compromised. Dropbox,