“Silently”? macOS will pop a prompt for new root CA, and from what I’m reading in the thread, Windows will, too. Did I miss the part where a software vendor can slip in a new root CA without me knowing about it?
At this point, admin escalations are common and random enough that I'd imagine most users just click OK. You're installing a patch, that's changing software on your computer, right? So I guess it needs admin, right? I'm not sure how a normal user is meant to know what's legit and what's not.
Most users have no idea what a root ca even is, so they have no ability to judge whether to accept or decline. Even with a prompt, they are not aware of what is happening.
So? This strawman user you've constructed has no idea what any of the blinkenlights in front of them are for. How much are you willing to make the desktop experience suck to cater to them?
That was rhetorical. It's obvious from the state of modern desktop OSs what the answer is.
Yeah, why did we ever get away from the glory days of bare-metal programming. Computers are only for people who understand them.
Sarcasm aside, I'm a software engineer with a very superficial understanding of the certificate system. I'm not even convinced of my own ability to notice when something's wrong.
I don't agree with your characterization as somebody who doesn't understand the significance of a root CA as a drooling idiot.
The text of one of your post's siblings is:
> A root lets you make a valid cert for any domain. It can be used to create a man-in-the-middle attack if paired with a proxy.
If you were to walk down the street tomorrow and ask 10 people to define "cert", "domain", "MITM", and "proxy" I'd wager you'd get 0 correct responses. I'd also wager those 10 people use computers every day -- and I don't think that's a problem. You shouldn't have to study and understand byzantine systems just to use a computer.
What I disagree with is the characterization of the user as someone who a) cares[1], and b) doesn't realize they're clicking through something they don't understand. After all, they do it all the time on EULAs and when they ignore their "check engine" light.
Could the message explain the problem better? Maybe, but when you characterize the user the way the parent did, you're not going to stop there, you're going to make them jump through all sorts of hoops or just outright deny the ability all together in the name of saving them from themselves, and that's a huge pain in the ass for the people who do know what's going on and are just trying to get some shit done and use their computer as the tool it was meant to be.
[1]Even if the user knew what it was saying it seems unlikely that they'd think it was malicious. They trust blizzard enough to install their software anyway, so if blizzard says they need this thing, why wouldn't they say ok?
You know, it was an honest question asking for clarification, because my observation differs from what’s reported. Feel free to move along if you don’t the answer.
I understand this, but that wasn’t my question. And the only comment in all this typing under my original comment that even made an attempt to answer my question of whether or not a piece of software can install a root CA without my knowledge, well, that got downvoted, too.
To reply to your question. It's possible to install a CA without one's knowledge.
The battle update this week requested to run with admin rights, like a million of setup software. It didn't ask specifically "Allow setup.exe to install a system CA? Yes/No".
This is how the system was meant to work. The irresponsibility of the centralized CA infra has been known for a little while now, and it's time to let the users see how shaky this trust model really is. Let them have certs that are actually made by the companies they trust instead of some stupid third party.
No, not across all applications on your computer. This is not about using your own CA, it's about making other software use your CA. They could just issue an update to their software to trust their own certs instead of infecting the rest of the OS.
This is nonsense (the tricky part), esp. when it comes to a software giant as Blizzard.
Virtually any ssl/https library allows custom certs that can be shipped along with the executable.
It's awfully common to see clients (enterprise) with trust-all keystore.
Former WOW and D3 player here. Think that majority of players are minors/teenagers with next-to-zero knowledge of what a "root CA" is and what it can do to your encrypted traffic.
I don't understand why Battle.net would do this, but I guess NOW they have to issue a statement about this.
Innocent version: oops we made a mistake.
Actual version: oops we got caught with our hand in the cookie-jar.
That must be it, the more intrusive it can be, the better the anti-cheat will preform.
I'm sure with Overwatch trying to become legit and the hundreds of millions that will go towards the Overwatch League, they need to ensure a level playing field.
The first assumption of anti-cheat is that the system you are running on is compromised because someone is trying to cheat. It starts with memory being modified out of order, then code being modified, then syscalls and APIs intercepted, and frankly by now it probably goes all the way up to running a cheat hypervisor, because why would you not.
So HTTPS is just adding entropy through waste heat, it achieves nothing, whatever a client is sending or receiving is trivially intercepted after the decryption.
Anti-cheat in the game client is all about hiding. WoW had this big thing with their Warden system where they downloaded code from the game server, loaded it into the client at runtime and then had some encrypted communication channel back. It was an utterly pointless waste of time because it was so obvious to anyone looking for an anti-cheat mechanism and trivially defeated. What worked for them in the end was doing an "unintentional" out of bounds/uninitialized memory read when assembling a network packet. It looks completely innocuous looking at it in a disassembler (and you wouldn't notice when it's one of 10000 changes in a big patch) but it just happened to send back some bytes of memory that were patched in a cheating client. By now you would probably skip the in-client cheat detection altogether and just do ML classification on movement/interaction/time data at the server.
For example, when a player makes an in-game screenshot [in WoW], this contains a watermark with the account number of that player. So if someone posts a screenshot how they cleverly exploited in the game, and remove their character name, Blizzard can still easily find out their PII because they have the info linked to the account number which is hidden in the screenshot. And its even hidden in partial screenshots.
That’s assuming that the players who played since 2004 stayed which isn’t the case really.
While the entire “gamer” demographic is now considerably older than it was 10-15 years ago on average I don’t think that WoW has an exceptional demographic in this regard.
If anecdotal evidence to be used than I would say that WoW probably skews younger now despite being a subscription MMO which tended to attract more adults than teens.
Not many 30+ year olds have time for MMOs anymore but we can still log into a CoD or BF multiplayer match over the weekend.
What's the practical difference between operating their own root and potentially mismanaging it, versus buying a wildcard cert and potentially mismanaging that?
edit: to answer my own dumb question, the major issue is that Blizzard or someone who steals Blizzard's root CA private key would be able to impersonate any domain they wanted, instead of just Blizzard's.
I think you understand what having a Root CA means but you haven't clearly explained what "mismanage any domain" means in real terms to folks who don't know these details.
It means that employees of Blizzard (hopefully not many of them but who knows) can now create certificates that will be accepted as "Wells Fargo" when the user tries to go to "https://wellsfargo.com". Their browser will show the green icon because the browser relies on the Root CAs in the trust store. I think/hope this will break for HSTS sites like most banks. I also think this was likely not intended maliciously by Blizzard. But it's incompetent and opens up unnecessary risk.
From some various comments on that thread, it appears it may have been a mistake, where they put the cert in the wrong store? Blizzard has a good reputation in my mind personally, so I'm giving the benefit of the doubt here.
Initially this was troubling news though, and will continue to be without some kind of confirmation.
If, as the comments say, this was in the OS-level store for both macOS and Windows, the only way I could see it being an accident would be if they are using a very high level cross-platform abstraction. Which I doubt. But of course we should always wait for official word before judging (still your choice whether to believe it).
So this is why "Agent" has been asking for my root password randomly recently? It doesn't need root to upgrade itself or its games so I had no idea what it was doing. I'm glad I kept denying it.
This isn't a CA certificate -- it is missing the CA basic constraints as well as missing the "certificate sign" key usage from X509v3, so most TLS libraries will not validate a chain that is signed by this certificate.
"most TLS libraries" is vague. Microsoft and Apple each include one with their OS. The Microsoft one definitely accepts total garbage as a valid CA root. I know because my employer pushed such a root to enable their MitM proxy and it worked fine... in Windows (and thus IE/ Edge). They had to replace it because Firefox and other systems threw a fit.
I'm happy to be proved wrong about this, but my experience tells me "most TLS libraries" is misleading even if technically true.
If you add a non-CA enabled certificate to the Trust store and a TLS library decides to trust it to sign a cert chain, that TLS library is horribly broken and needs a critical CVE. File a bug an earn a $10k bounty, but I’m guessing this is FUD and Blizzard did nothing wrong here and exposed exactly no one to any kind of risk.
In fact it appears they did exactly the right thing to get https working correctly in their mixed-mode (localhost + outside world) environment.
The fact you think this makes Microsoft's TLS library (SChannel) "horribly broken" doesn't magically mean I get a $10k bounty award. Microsoft considers that if you put a cert which lacks CA:TRUE into your local trust store you must know what you're doing and want to trust it as a CA anyway. They're entitled to whatever opinion they want, and don't have to pay third parties just because somebody on HN disagrees.
Now, if you want you can argue that Blizzard weren't to know this would happen. And that, depending on what else they've done this might be safe anyway, but I wasn't commenting on either of those, only pointing out that SChannel doesn't care about basic constraints on trusted roots.
"openssl x509 -text" output (with boring parts omitted):
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 41124 (0xa0a4)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = California, L = Irvine, O = Blizzard Entertainment, OU = Battle.net, CN = Blizzard Battle.net Local Cert
Validity
Not Before: Dec 21 21:34:01 2017 GMT
Not After : Dec 19 21:34:01 2027 GMT
Subject: C = US, ST = California, L = Irvine, O = Blizzard Entertainment, OU = Battle.net, CN = Blizzard Battle.net Local Cert
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<boring>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:localbattle.net
Signature Algorithm: sha256WithRSAEncryption
<boring>
This was triggered by Tavis Ormandy and he says it's fine [1]. I honestly don't know enough to tell, is he correct when he says that it doesn't actually make any difference?
I think the root problem is that apparently connections to http://localhost from a https:// site are considered mixed content and therefore blocked. I thought there was an exception for localhost, but apparently there isn't. [1] (I don't really understand the rationale for this)
So with connections to http://localhost not possible due to mixed content and connections to https://localhost not possible because your cert will be blocked, there doesn't seem to be any obvious way left to connect from https to localhost at all.
Remember than any page in your browser can run scripts from your computer. Browsers have a security model of what is allowed or not, that is a huge super-complicated mess. One of the protection is blocking mixed http and https.
localhost and 127.0.0.1 never get exceptions to security rules, including mixed content.
The rational is that there are many intranet and local applications that might be accessible on 127.0.0.1, they were not designed or secured to be accessible from the internet.
I don't think that really makes sense in that context. The current situation is that you can happily access localhost from unencrypted sites - even though those sites are more likely to contain malicious code.
Additionally, localhost services are treated as a separate origin, so if a service is non-cooperating, you can only send fire-and-forget GETs which reduces the attack surface considerably.
The https everywhere movement really caused this. Until google figures out a way to make money serving ads off localhost I cannot imagine they give a flying shit. :)
Ok, so apparently there is a security exception: "localhost" is blocked but "127.0.0.1" is treated as a secure origin [1] - but only if you cantact it via http, not via websocket. (though they might allow websocket in the future too) [2]
(A related chrome bug even specifically mentions the "people installing local root certs" workaround as a reason they are doing this. [3])
This still seems like an enormous mess but it's good to see the use-case is acknowledged and someone at Mozilla cares about it.
So I guess Blizzard could have avoided the whole scare if they had just used "127.0.0.1" instead of "localbattle.net"
Does it need to be a whole septate machine? If I run Linux as my daily driver and a Windows install on a separate drive/partition for gaming only, then I'll only be exposed to any potential risks for this when I boot to Windows, right?
Is the Linux drive still connected when you boot into Windows?
Of course, in practice, I don't think any average bad guy is going to spend the time to write Windows malware that installs Linux malware on other drives or partitions. Just like any security practice, it's a matter of tradeoffs. Is it worth the trouble to disconnect the Linux drive every time you want to play a game in Windows?
So, theoretically, any malware with root-equivalent privileges can do whatever it wants to anything on the system. Also, theoretically, malware can be remotely installed on your WAN-exposed router, infiltrate your network, and install malware using zero-days on every machine on your network. Is it worth the risk to air-gap your machines?
More practically, non-gaming stuff doesn't require a high-end machine, and average/SFF machines are plenty powerful, so it's probably reasonable to have a separate machine for gaming. Just get a KVM switch and put a Mac Mini-type machine next to it for your non-gaming machine. Then do all your gaming, using whatever awful incarnation of Windows is currently required, on the other machine, and never do any banking/email/etc. on the Windows machine, never type any passwords into it (except for gaming-related, of course). Treat the Windows installation as a throwaway, ready to be nuked and reinstalled at any time.
Our recent update to the Blizzard Battle.net desktop app made sure players could properly use features like logging in to Battle.net via a social network, or joining a Blizzard group via an invite link. To facilitate these features, we updated the local webserver to use a self-signed certificate to be consistent with current industry security standards.
For those interested in more detail, using these features requires your web browser to communicate with the Blizzard Battle.net desktop app. Previously, the desktop app used a certificate signed by a public Certificate Authority, meaning that no modifications to your system certificates were necessary; however, this technique is incompatible with Certificate Authority policies and we can no longer use it.
While some browsers such as Chrome and Firefox are equipped to handle browser-to-app communication techniques, the changes were necessary for other browsers. For the time being, the desktop app generates a self-signed certificate that’s unique to your machine and configures your system to trust it.
Looking at the certificate posted lower in this thread, everyone is throwing a fit over nothing. This is the correct way to do what they want to do, unless they want to register/use an application protocol.
They have a REST server running locally, and they want to link to it from websites on the internet. So they created the domain localbattle.net which points to 127.0.0.1. But there's a problem, they can't use http traffic (because of mixed content warnings, even though it wouldn't really be insecure), so they have to use https traffic. They can't use a public CA because the CA would throw a fit if they found out keys for certs were being distributed in an application (they could lose trust in major browsers due to something like that). So they generate a non-ca certificate (notice the cert doesn't have basicConstraints: CA=true) during setup, install it in the OS so the browsers trust it, and use it in their local webserver. The key is only available on the computer (and I assume it's stored in a secure manner). The only way they could use this cert to mitm your SSL traffic, or phish/pharm you is to do that same process with a different domain in the subjaltname extension.
I think this is a clever and secure solution to the problem they face.
At the end of the day you're already running their code on your computer and have given it admin privileges in the past, so you can't say you don't trust the application, and this doesn't introduce any supply-chain type vulnerabilities that could be exploited down the line (that didn't already exist in the auto-updater, which is a much bigger issue I have with the Blizzard client).
So I guess I'm asking, what am I missing, why is everyone freaking out at Blizzard?
As a non-techie, can someone expand the reddit post below, and why each individual's person private key is thought to be secured? Is the private key like a super password?
This is very concerning. The implication of this is super super dangerous. If anyone gets hold of the private key (which I sure hope is secure, but I'm not holding my breath), they can snoop on all of your traffic, and steal your password and credit card numbers. Usual Root CAs (Commodo, etc...) are held to very very very high standards in how securly they store their private key because of just how bad it is for it to leak. They are forced to undergo a very thorough audit process before being trusted. But since blizzard is not an official CA, they don't have to undergo the same process, even though a failure would be equally disastrous.
There is no valid reason whatsoever to install a Root CA here. What blizzard is doing is simply wrong, from a technical and ethical perspective. From what I understand, it is used to implement facebook login. There are other, better ways to do this. They could use an embedded browser instead of the default browser. They could use http instead of https (the url should be local anyway, and as such, secure). They could have registered a Custom URI scheme. The alternative, secure solutions are plenty.
Furthermore, Battle.net is failing in other ways. Everyone that has battle.net has a permanent server on localhost:22885. From what I gather, this is what they use to implement the facebook login, but the server is always on, instead of being only enabled when facebook login is actually in use. This is another big can of worm. We've seen previously that such things can lead to Remote Code Execution (basically a very convenient way to spread viruses) because any browser can make connections to it.
Blizzard needs to fix this shit now.
So far what I've done under my Windows 7 machine is to placed the certificate under "Untrusted Certificates" and under properties, turned on "Disable all purposes for this certificate". Are there any other measures that I should take to completely prevent this certificate from causing potential harm?
According to commits in this HN thread, including the one you're replying to (which I have not independently verified), that Reddit post is factually mistaken about crucial points. There is no reason to be alarmed, to worry about the certificate, or try to disable it.
There may be some merit to the point about running the local permanent HTTPS server but that's unrelated to the certificate.
I tried to expand this comment to include a technical explanation of the issues, but it became quite long. I'll try to simplify and summarize: there are legitimate security concerns about applications that install their own Certificate Authorities (CAs, aka root certificates), especially when the same one is being installed on all computers. A Certificate Authority has the ability to issue certificates for any website, so it has the ability to compromise the user's traffic to any website if mismanaged. Blizzard didn't do that. Blizzard installs a randomly generated, unique-to-the-user certificate (not certificate authority) for Blizzard's own website domain name. This does not present any of the security issues alleged by the Reddit comment.
So there is no root certificate or CA involved -- the title of this HN article is incorrect and the Reddit thread is mistaken. (To caveat again: I have not personally verified this, and am digesting information supplied by other HNers) However, if you don't plan to log in to Battle.net using Facebook, then there's probably no downside to disabling this certificate either.
Thanks, so from my reading of this, this certificate had no functions of an actual root certificate and thus having MITM or other attack vectors aren't possible.
77 comments
[ 2.8 ms ] story [ 106 ms ] thread> I got a strange prompt that Agent wanted to make changes on my computer and needed my admin password
An admin/mod should change the title here, but the concern is still the same.
That was rhetorical. It's obvious from the state of modern desktop OSs what the answer is.
Sarcasm aside, I'm a software engineer with a very superficial understanding of the certificate system. I'm not even convinced of my own ability to notice when something's wrong.
Because that's what you're doing when you say shit like this. Thinking like that is what gave us forced automatic updates.
The text of one of your post's siblings is:
> A root lets you make a valid cert for any domain. It can be used to create a man-in-the-middle attack if paired with a proxy.
If you were to walk down the street tomorrow and ask 10 people to define "cert", "domain", "MITM", and "proxy" I'd wager you'd get 0 correct responses. I'd also wager those 10 people use computers every day -- and I don't think that's a problem. You shouldn't have to study and understand byzantine systems just to use a computer.
Could the message explain the problem better? Maybe, but when you characterize the user the way the parent did, you're not going to stop there, you're going to make them jump through all sorts of hoops or just outright deny the ability all together in the name of saving them from themselves, and that's a huge pain in the ass for the people who do know what's going on and are just trying to get some shit done and use their computer as the tool it was meant to be.
[1]Even if the user knew what it was saying it seems unlikely that they'd think it was malicious. They trust blizzard enough to install their software anyway, so if blizzard says they need this thing, why wouldn't they say ok?
Or are you trying to derail the conversation on purpose?
Attention: You must click OK to play this game.
The battle update this week requested to run with admin rights, like a million of setup software. It didn't ask specifically "Allow setup.exe to install a system CA? Yes/No".
No, not across all applications on your computer. This is not about using your own CA, it's about making other software use your CA. They could just issue an update to their software to trust their own certs instead of infecting the rest of the OS.
https://news.ycombinator.com/newsguidelines.html
I don't understand why Battle.net would do this, but I guess NOW they have to issue a statement about this.
Innocent version: oops we made a mistake.
Actual version: oops we got caught with our hand in the cookie-jar.
Arent' they making lots of money off these poor addicts already?
I'm sure with Overwatch trying to become legit and the hundreds of millions that will go towards the Overwatch League, they need to ensure a level playing field.
So HTTPS is just adding entropy through waste heat, it achieves nothing, whatever a client is sending or receiving is trivially intercepted after the decryption.
Anti-cheat in the game client is all about hiding. WoW had this big thing with their Warden system where they downloaded code from the game server, loaded it into the client at runtime and then had some encrypted communication channel back. It was an utterly pointless waste of time because it was so obvious to anyone looking for an anti-cheat mechanism and trivially defeated. What worked for them in the end was doing an "unintentional" out of bounds/uninitialized memory read when assembling a network packet. It looks completely innocuous looking at it in a disassembler (and you wouldn't notice when it's one of 10000 changes in a big patch) but it just happened to send back some bytes of memory that were patched in a cheating client. By now you would probably skip the in-client cheat detection altogether and just do ML classification on movement/interaction/time data at the server.
For example, when a player makes an in-game screenshot [in WoW], this contains a watermark with the account number of that player. So if someone posts a screenshot how they cleverly exploited in the game, and remove their character name, Blizzard can still easily find out their PII because they have the info linked to the account number which is hidden in the screenshot. And its even hidden in partial screenshots.
While the entire “gamer” demographic is now considerably older than it was 10-15 years ago on average I don’t think that WoW has an exceptional demographic in this regard.
If anecdotal evidence to be used than I would say that WoW probably skews younger now despite being a subscription MMO which tended to attract more adults than teens.
Not many 30+ year olds have time for MMOs anymore but we can still log into a CoD or BF multiplayer match over the weekend.
Innocent version: we did nothing wrong and you are reacting before having even looked at that certificate.
edit: to answer my own dumb question, the major issue is that Blizzard or someone who steals Blizzard's root CA private key would be able to impersonate any domain they wanted, instead of just Blizzard's.
Having a CA means they can mismanage any domain.
It means that employees of Blizzard (hopefully not many of them but who knows) can now create certificates that will be accepted as "Wells Fargo" when the user tries to go to "https://wellsfargo.com". Their browser will show the green icon because the browser relies on the Root CAs in the trust store. I think/hope this will break for HSTS sites like most banks. I also think this was likely not intended maliciously by Blizzard. But it's incompetent and opens up unnecessary risk.
Initially this was troubling news though, and will continue to be without some kind of confirmation.
[1]: https://groups.google.com/forum/#!topic/mozilla.dev.security...
Edit: This was written assuming CA bit = 1.
I'm happy to be proved wrong about this, but my experience tells me "most TLS libraries" is misleading even if technically true.
In fact it appears they did exactly the right thing to get https working correctly in their mixed-mode (localhost + outside world) environment.
Now, if you want you can argue that Blizzard weren't to know this would happen. And that, depending on what else they've done this might be safe anyway, but I wasn't commenting on either of those, only pointing out that SChannel doesn't care about basic constraints on trusted roots.
The thumbprint is e8e6a2932ae8de6eb3b555270b55fdc72b7db7b7, but it's limited to the subject alternative name "DNS Name=localbattle.net".
You could look at the "Not Valid Before" date, which is 2017-12-21.
[1]: https://twitter.com/chort0/status/943933566596952065
So with connections to http://localhost not possible due to mixed content and connections to https://localhost not possible because your cert will be blocked, there doesn't seem to be any obvious way left to connect from https to localhost at all.
[1] https://security.stackexchange.com/questions/104801/why-aren...
localhost and 127.0.0.1 never get exceptions to security rules, including mixed content.
The rational is that there are many intranet and local applications that might be accessible on 127.0.0.1, they were not designed or secured to be accessible from the internet.
Additionally, localhost services are treated as a separate origin, so if a service is non-cooperating, you can only send fire-and-forget GETs which reduces the attack surface considerably.
Ok, so apparently there is a security exception: "localhost" is blocked but "127.0.0.1" is treated as a secure origin [1] - but only if you cantact it via http, not via websocket. (though they might allow websocket in the future too) [2]
(A related chrome bug even specifically mentions the "people installing local root certs" workaround as a reason they are doing this. [3])
This still seems like an enormous mess but it's good to see the use-case is acknowledged and someone at Mozilla cares about it.
So I guess Blizzard could have avoided the whole scare if they had just used "127.0.0.1" instead of "localbattle.net"
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=903966
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1376309
[3] https://chromium.googlesource.com/chromium/src.git/+/130ee68...
Of course, in practice, I don't think any average bad guy is going to spend the time to write Windows malware that installs Linux malware on other drives or partitions. Just like any security practice, it's a matter of tradeoffs. Is it worth the trouble to disconnect the Linux drive every time you want to play a game in Windows?
So, theoretically, any malware with root-equivalent privileges can do whatever it wants to anything on the system. Also, theoretically, malware can be remotely installed on your WAN-exposed router, infiltrate your network, and install malware using zero-days on every machine on your network. Is it worth the risk to air-gap your machines?
More practically, non-gaming stuff doesn't require a high-end machine, and average/SFF machines are plenty powerful, so it's probably reasonable to have a separate machine for gaming. Just get a KVM switch and put a Mac Mini-type machine next to it for your non-gaming machine. Then do all your gaming, using whatever awful incarnation of Windows is currently required, on the other machine, and never do any banking/email/etc. on the Windows machine, never type any passwords into it (except for gaming-related, of course). Treat the Windows installation as a throwaway, ready to be nuked and reinstalled at any time.
Our recent update to the Blizzard Battle.net desktop app made sure players could properly use features like logging in to Battle.net via a social network, or joining a Blizzard group via an invite link. To facilitate these features, we updated the local webserver to use a self-signed certificate to be consistent with current industry security standards.
For those interested in more detail, using these features requires your web browser to communicate with the Blizzard Battle.net desktop app. Previously, the desktop app used a certificate signed by a public Certificate Authority, meaning that no modifications to your system certificates were necessary; however, this technique is incompatible with Certificate Authority policies and we can no longer use it.
While some browsers such as Chrome and Firefox are equipped to handle browser-to-app communication techniques, the changes were necessary for other browsers. For the time being, the desktop app generates a self-signed certificate that’s unique to your machine and configures your system to trust it.
They have a REST server running locally, and they want to link to it from websites on the internet. So they created the domain localbattle.net which points to 127.0.0.1. But there's a problem, they can't use http traffic (because of mixed content warnings, even though it wouldn't really be insecure), so they have to use https traffic. They can't use a public CA because the CA would throw a fit if they found out keys for certs were being distributed in an application (they could lose trust in major browsers due to something like that). So they generate a non-ca certificate (notice the cert doesn't have basicConstraints: CA=true) during setup, install it in the OS so the browsers trust it, and use it in their local webserver. The key is only available on the computer (and I assume it's stored in a secure manner). The only way they could use this cert to mitm your SSL traffic, or phish/pharm you is to do that same process with a different domain in the subjaltname extension.
I think this is a clever and secure solution to the problem they face. At the end of the day you're already running their code on your computer and have given it admin privileges in the past, so you can't say you don't trust the application, and this doesn't introduce any supply-chain type vulnerabilities that could be exploited down the line (that didn't already exist in the auto-updater, which is a much bigger issue I have with the Blizzard client).
So I guess I'm asking, what am I missing, why is everyone freaking out at Blizzard?
(Also not sure if anti-cheat is a factor here?)
This is very concerning. The implication of this is super super dangerous. If anyone gets hold of the private key (which I sure hope is secure, but I'm not holding my breath), they can snoop on all of your traffic, and steal your password and credit card numbers. Usual Root CAs (Commodo, etc...) are held to very very very high standards in how securly they store their private key because of just how bad it is for it to leak. They are forced to undergo a very thorough audit process before being trusted. But since blizzard is not an official CA, they don't have to undergo the same process, even though a failure would be equally disastrous.
There is no valid reason whatsoever to install a Root CA here. What blizzard is doing is simply wrong, from a technical and ethical perspective. From what I understand, it is used to implement facebook login. There are other, better ways to do this. They could use an embedded browser instead of the default browser. They could use http instead of https (the url should be local anyway, and as such, secure). They could have registered a Custom URI scheme. The alternative, secure solutions are plenty.
Furthermore, Battle.net is failing in other ways. Everyone that has battle.net has a permanent server on localhost:22885. From what I gather, this is what they use to implement the facebook login, but the server is always on, instead of being only enabled when facebook login is actually in use. This is another big can of worm. We've seen previously that such things can lead to Remote Code Execution (basically a very convenient way to spread viruses) because any browser can make connections to it.
Blizzard needs to fix this shit now.
So far what I've done under my Windows 7 machine is to placed the certificate under "Untrusted Certificates" and under properties, turned on "Disable all purposes for this certificate". Are there any other measures that I should take to completely prevent this certificate from causing potential harm?
There may be some merit to the point about running the local permanent HTTPS server but that's unrelated to the certificate.
I tried to expand this comment to include a technical explanation of the issues, but it became quite long. I'll try to simplify and summarize: there are legitimate security concerns about applications that install their own Certificate Authorities (CAs, aka root certificates), especially when the same one is being installed on all computers. A Certificate Authority has the ability to issue certificates for any website, so it has the ability to compromise the user's traffic to any website if mismanaged. Blizzard didn't do that. Blizzard installs a randomly generated, unique-to-the-user certificate (not certificate authority) for Blizzard's own website domain name. This does not present any of the security issues alleged by the Reddit comment.
So there is no root certificate or CA involved -- the title of this HN article is incorrect and the Reddit thread is mistaken. (To caveat again: I have not personally verified this, and am digesting information supplied by other HNers) However, if you don't plan to log in to Battle.net using Facebook, then there's probably no downside to disabling this certificate either.