Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, Dec 25, 2017 at 5:01 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, December 25, 2017 at 10:24:30 AM UTC-6, Hanno Böck wrote: > > On Mon, 25 Dec 2017 14:43:21 + > > Jeremy Rowley via dev-security-policy > >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

I’m pretty sure EA revoked the cert. > On Dec 25, 2017, at 9:23 AM, Hanno Böck wrote: > > On Mon, 25 Dec 2017 14:43:21 + > Jeremy Rowley via dev-security-policy > wrote: > >> Without the private key, im not sure how we're supposed to

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

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. Taking it back to the IP layer has the advantage of certainty for the constrained question of whether

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Matthew Hardeman wrote: > 6. Thus, the direction this goes is that the developer creates a self-signed > cert and imports it into the trust store. The developer may do this on the > software host, but historically is more likely to just create one and package > it just like they did with the

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Monday, December 25, 2017 at 11:27:00 AM UTC-6, Adrian R. wrote: > +1 > imho that would be the best idea, and the local/non-local check should happen > inside the same PKI-validation logic flow that is used for certificate > validation. > > If the url resource resolves to local IP addresses

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

P.S. i assumed only a TLS context, but the same rule should probably apply for any connection, whether plaintext or SSL/TLS: > If the url resource resolves to local IP addresses then only reserved names > from > https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

+1 imho that would be the best idea, and the local/non-local check should happen inside the same PKI-validation logic flow that is used for certificate validation. If the url resource resolves to local IP addresses then only reserved names from

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Monday, December 25, 2017 at 10:24:30 AM UTC-6, Hanno Böck wrote: > On Mon, 25 Dec 2017 14:43:21 + > Jeremy Rowley via dev-security-policy > wrote: > > > Without the private key, im not sure how we're supposed to confirm > > key compromise. > >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

those cases can be easily ruled out like this: 1) after authentication in the BattleNet app and the app starts properly, disconnect the device from any network. In my case i physically unplugged the ethernet cable from the PC, and it has no other connection available, not even wireless. 2)

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, 25 Dec 2017 14:43:21 + Jeremy Rowley via dev-security-policy wrote: > Without the private key, im not sure how we're supposed to confirm > key compromise. I've pinged a few people with the right skillset to try to extract the key. But if there

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, Dec 25, 2017 at 07:59:12AM -0800, Peter Bowen via dev-security-policy wrote: > On Mon, Dec 25, 2017 at 7:10 AM, Adrian R. via dev-security-policy > wrote: > > since it's a webserver running on the local machine and is using that > > certificate

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, Dec 25, 2017 at 7:10 AM, Adrian R. via dev-security-policy wrote: > since it's a webserver running on the local machine and is using that > certificate key/pair, i think that someone more capable than me can easily > extract the key from it. > >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

since it's a webserver running on the local machine and is using that certificate key/pair, i think that someone more capable than me can easily extract the key from it. >From my point of view as an observer it's plainly obvious that the private key >must be on my local machine too, even if i

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

I think this raises a question on what level of investigation and assumption is required by the ca. Let's encrypt, for example, requires submission of the private key for revocation (https://letsencrypt.org/docs/revoking/). Is simply providing a reference rather than the key sufficient? On Dec

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

1) get a virtual machine 2) install windows, install the Blizzard BattleNet client. 3) create a BattleNet account with any email address - it's free, subscription/payment is not required for this. 4) login in the BattleNet app client with the account from step 3. 5) after the main BattleNet

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Without the private key, im not sure how we're supposed to confirm key compromise. > On Dec 25, 2017, at 3:32 AM, Adrian R. via dev-security-policy > wrote: > > The BattleNet app needs to be installed and running, i am logged in with a > battlenet

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, 25 Dec 2017 04:19:58 -0800 (PST) "Adrian R. via dev-security-policy" wrote: > Side question: why wasn't the certificate from DigiCert logged into > Certificate Transparency logs when it was issued and it had to be > discovered this way? There's no

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Side question: why wasn't the certificate from DigiCert logged into Certificate Transparency logs when it was issued and it had to be discovered this way? On Monday, 25 December 2017 12:42:05 UTC+2, Hanno Böck wrote: > Thanks, I also got it in the meantime and submitted it to CT: >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Thanks, I also got it in the meantime and submitted it to CT: https://crt.sh/?id=287530764 Bugreport: https://bugzilla.mozilla.org/show_bug.cgi?id=1427034 -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

The BattleNet app needs to be installed and running, i am logged in with a battlenet account. the public certificate is attached below and i don't know how to get the private key from inside the app, but it must be there since it runs as local webserver on 127.0.0.1 Adrian R. -BEGIN

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Sun, 24 Dec 2017 23:07:56 -0800 (PST) "Adrian R. via dev-security-policy" wrote: > on any computer with BattleNet installed and active go to this url: > > https://127.0.0.1:22886/ > and currently it uses this certificate... which doesn't appear on >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

p.s. 1) i posted here because i don't even have access to viewing the Blizzard bug on Bugzilla, even if i'm logged in with a Bugzilla account I get the message " You are not authorized to access bug 1425166. " 2) i also sent the same message to the certificate problem-reporting address