-dev-security-policy
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 n
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 overridde
I sent the key to Jeremy on Tuesday as Hanno suggested, and it was revoked
at 9am the next morning.
The encrypted private key information is only in memory during startup, so
I identified that bit of code and broke into a debugger. You could pull the
parameters out of OpenSSL's internals too. Happ
I found there is actually no need to sign-in to battle.net client. Simply
running the battle.net client shortcut from the desktop opens the login screen.
At this point the server has already and is listning on port 22886. Also
confirmed ability to connect with browser to https://127.0.0.1:22886
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
> > wrote:
> >
> > > Wi
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 confirm
>> key compromise.
>
> I've pinged a few peopl
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 or
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
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 t
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
> s
+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
https://cabforum.org/wp-content/uploads/Guidance-
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.
>
> I've pinged a few people with the right ski
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) try
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 are people here who feel capable feel f
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 key/pair, i think that someone more capable
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.
>
> From my point of view as an observer it's
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 h
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
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 inter
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 account.
>
> the public certificate is atta
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 requirement for CT logging yet.
Right
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:
> https://crt.s
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
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 CERTI
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
> crt.sh yet
I'm not able to reproduce this.
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
specifie
> Bug Blizzard:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1425166
> Cert Blizzard:
> https://crt.sh/?id=26142
>
Blizzard went to DigiCert and got another certificate instead:
on any computer with BattleNet installed and active go to this url:
https://127.0.0.1:22886/
and currently it
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 runni
This is nasty.
Apparently, it's not actually a true Root CA cert (No CA: True) and it has
an EKU that would not include signing certificates.
That said, Blizzard's response is further to my point...
As long as the browser can access resources of the localhost under the
direction of a web page th
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
WebS
For the record: Blizzard's response to these certs being revoked was to deploy
a software update which installs their own root CA on their customer's
computers:
https://www.reddit.com/r/heroesofthestorm/comments/7lb8vq/hey_blizzard_whats_the_deal_with_this_sneaky_root/
__
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 vali
32 matches
Mail list logo