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 the relevant sections from the Baseline Requirements, and DigiCert policies. The report was acknowledged, and has been escalated to Spotify's security team for review. On Tue, Jun 20, 2017, at 22:23, Rob Stradling via dev-security-policy wrote: > [CC'ing rev...@digicert.com, as per > https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00028] > > Annie, > > "but these have been known about and deemed acceptable for years" > > Known about by whom? Deemed acceptable by whom? Until the CA becomes > aware of a key compromise, the CA will not know that the corresponding > certificate(s) needs to be revoked. > > Thanks for providing the Spotify example. I've just found the > corresponding certificate (issued by DigiCert) and submitted it to some > CT logs. It's not yet revoked: > https://crt.sh/?id=158082729 > > https://gist.github.com/venoms/d2d558b1da2794b9be6f57c5e81334f0 does > appear to be the corresponding private key. > > On 20/06/17 15:57, annie nguyen via dev-security-policy wrote: > > 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, 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 > > instance of Spotify (which must be served over https because > > open.spotify.com is also delivered over https). > > > > This has happened for years, and these applications have certificates > > issued by DigiCert and Comodo all pointing to 127.0.0.1 whose private > > keys are trivially retrievable, since they're embedded in publicly > > distributed binaries. > > > > - GitHub: ghconduit.com > > - Discord: discordapp.io > > - Dropbox: www.dropboxlocalhost.com > > - Spotify: *.spotilocal.com > > > > Here is Spotify's, for example: > > https://gist.github.com/venoms/d2d558b1da2794b9be6f57c5e81334f0 > > > > ---- > > > > What I want to know is: how does this differ to Cisco's situation? Why > > was Cisco's key revoked and considered compromised, but these have been > > known about and deemed acceptable for years - what makes the situation > > different? > > > > 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 > > certificate on all their devices) > > > > Thank you so much, > > Annie > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > COMODO CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > sender by replying to the e-mail containing this attachment. Replies to > this email may be monitored by COMODO for operational or business > reasons. Whilst every endeavour is taken to ensure that e-mails are free > from viruses, no liability can be accepted and the recipient is > requested to use their own virus checking software. > _______________________________________________ > 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
