9 ms·

Blizzard's Battle.net Updater Installs Root Certificate

198 points by roblabla 9y ago

HenryBemis 9y ago
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.
- johansch 9y ago
  Why in the world would they do this, though? I'm at a loss. Arent' they making lots of money off these poor addicts already?
  - AFNobody 9y ago
    There is stuff they do for cheat/crack detection that involve https is the only thing I can think of.
    - nrhk 9y ago
      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.
      - deleted 9y ago
        [deleted]
      - skate22 9y ago
        Kickbots in WoW are annoying as hell too.
    - revelation 9y ago
      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.
      - Fnoord 9y ago
        It is just one of the many defenses they use. 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.
  - scrollaway 9y ago
    The actual reason they'd do this is a follow up to this thread from @taviso: https://twitter.com/taviso/status/939634523137966080 https://twitter.com/taviso/status/939634523137966080
- PeterStuer 9y ago
  Small correction. I think that the average WoW player's age is well above 30 at this point.
  - dogma1138 9y ago
    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.
- cyansmoker 9y ago
  Correction: Innocent version: we did nothing wrong and you are reacting before having even looked at that certificate.
mikestew 9y ago
“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?
- noncoml 9y ago
  Is the word "silently" your only concern here? Not the fact that Blizzard installs a root CA, silently or not? Or are you trying to derail the conversation on purpose?
  - mikestew 9y ago
    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.
    - noncoml 9y ago
      Oh. Apologies then.
- enzanki_ars 9y ago
  It wasn't silently added: > 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.
  - taneq 9y ago
    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.
- bagacrap 9y ago
  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.
5ilv3r 9y ago
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.
- kodablah 9y ago
  > This is how the system was meant to work. 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.
  - 5ilv3r 9y ago
    They could. That would be a bit tricky though since http libs usually use the shared system cert store.
    - kodablah 9y ago
      Any reasonable one would allow you to change the trust store or approach programmatically.
      - 5ilv3r 9y ago
        My argument was that centralizing trust as a service is unsustainable. That's all.
    - xxs 9y ago
      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.
- 1_2__4 9y ago
  You appear to lack any authority or knowledge here because almost every part of your comment is completely wrong.
gnu8 9y ago
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.
- hrrsn 9y ago
  Buying a wildcard cert means they can mismanage their keys for *.battle.net. Having a CA means they can mismanage any domain.
  - wyldfire 9y ago
    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" 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.
- chacham15 9y ago
  Not just that, blizzard themselves could pretend to be Google.
kup0 9y ago
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.
- kodablah 9y ago
  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).
  - kup0 9y ago
    Oh, didn't think about the issue happening on multiple platforms. That does complicate things.
kbd 9y ago
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.
Ajedi32 9y ago
I'm guessing this is Blizzard's response to [their previous cert being revoked][1]. [1]: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/pk039T_wPrI https://groups.google.com/forum/#!topic/mozilla.dev.security...
- kbwt 9y ago
  So it may have been intentional. Couldn't this expose Blizzard employees to criminal charges? Edit: This was written assuming CA bit = 1.
kondbg 9y ago
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.
- tptacek 9y ago
  Good catch.
- tialaramex 9y ago
  "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.
  - zaroth 9y ago
    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.
    - tialaramex 9y ago
      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.
ChuckMcM 9y ago
For what ever reason I always assumed this was to prevent the game client from being used with unoffical servers.
AaronFriel 9y ago
I just checked and found "Blizzard Battle.net Local Cert" in certmgr on my home Windows 10 desktop. The thumbprint is e8e6a2932ae8de6eb3b555270b55fdc72b7db7b7, but it's limited to the subject alternative name "DNS Name=localbattle.net".
- kbwt 9y ago
  Could you (or anyone else) upload the certificate file for inspection?
  - AaronFriel 9y ago
    -----BEGIN CERTIFICATE----- MIID1jCCAr6gAwIBAgIDAKCkMA0GCSqGSIb3DQEBCwUAMIGSMQswCQYDVQQGEwJV UzETMBEGA1UECAwKQ2FsaWZvcm5pYTEPMA0GA1UEBwwGSXJ2aW5lMR8wHQYDVQQK DBZCbGl6emFyZCBFbnRlcnRhaW5tZW50MRMwEQYDVQQLDApCYXR0bGUubmV0MScw JQYDVQQDDB5CbGl6emFyZCBCYXR0bGUubmV0IExvY2FsIENlcnQwHhcNMTcxMjIx MjEzNDAxWhcNMjcxMjE5MjEzNDAxWjCBkjELMAkGA1UEBhMCVVMxEzARBgNVBAgM CkNhbGlmb3JuaWExDzANBgNVBAcMBklydmluZTEfMB0GA1UECgwWQmxpenphcmQg RW50ZXJ0YWlubWVudDETMBEGA1UECwwKQmF0dGxlLm5ldDEnMCUGA1UEAwweQmxp enphcmQgQmF0dGxlLm5ldCBMb2NhbCBDZXJ0MIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAv4ih+a9V+dd+l97hTyWYLg+b1aj6UrgREMvLv0PFoE63eozs oFAvjr/0QVCt8RJg2aIF1OZSfc4c9PWkSktFvKB2vMRbVkSwhZvlpDLdQdgD89q9 XZnWv8KmB1w7R7RUzYhNv5IBfqx77hdpMsdfhMAsVu9UNi7Bowhk2Lyk+NSIMMbY f6TvgoWLLz6Glw1mGSl8ki2SzaFj6xTNdKo56knZBy9wHQlmjv7GVltwmcVeyARC 3Q4qG/tG7t9CchCNUWHMP1Uxc9t2hZbQIjJRIE+h7Njp7A5nNIO0XXkJpKdtank/ Q2+CJNdoX7kNi7frB3y+TVSNYTNxh6bfDyueEwIDAQABozMwMTATBgNVHSUEDDAK BggrBgEFBQcDATAaBgNVHREEEzARgg9sb2NhbGJhdHRsZS5uZXQwDQYJKoZIhvcN AQELBQADggEBABFtIjAcF6vgXBWUACc+nvKwLUUAuIDigK+PpTJZ+eqvJd2gjPG+ i9tfSe3Y0uWeHgNAtV3bwV/pEp8jPj0KyS7aYM2QhS2Gezy2NN7RjXtU+tFItwQ3 ykHQsqG5F+KqpDFZrbmuPkXUB9TihxG9aGATBOzhw18RV7hlf/y+60LDMF+8BoYY AVJ6wDUcYsuO4PQ2DE3DlJJokUsITUlzWYn60Kmo96NG0MST/Zg3bLLC3gxclZb/ vkK/pVha6I8kRyPFkfwIS/4Z/HCwHX9RAxbBaOxGqaN3XgcsR9hGBZD6DRA6iF1u XfkZ9zz/NfgVIx+AJmyw32X1T5HRcmMhZZ4= -----END CERTIFICATE-----
    - jwilk 9y ago
      "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>
szastupov 9y ago
Well, they are very sloppy about security, look at the permissions they set for battle.net files https://pbs.twimg.com/media/DOvhmJ1WkAAFCSD.jpg https://pbs.twimg.com/media/DOvhmJ1WkAAFCSD.jpg (sorry for screenshot)
- sannee 9y ago
  I mean, sure, it's not exactly in good taste, but noone really uses multi-user desktop setups these days...
jwilk 9y ago
> The expiration day is December 19th, and since certificates are usually generated for a certain number of years, that means it was just created. You could look at the "Not Valid Before" date, which is 2017-12-21.
xwvvvvwx 9y ago
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? [1]: https://twitter.com/chort0/status/943933566596952065 https://twitter.com/chort0/status/943933566596952065
- xg15 9y ago
  I think the root problem is that apparently connections to http://localhost http://localhost from a https:// 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 http://localhost not possible due to mixed content and connections to https://localhost 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-arent-mixed-content-connections-allowed-on-localhost https://security.stackexchange.com/questions/104801/why-aren...
  - user5994461 9y ago
    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.
    - xg15 9y ago
      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.
bitL 9y ago
Have a separate gaming machine for games only. You can't trust anyone these days.
- Cookiesaurusbex 9y ago
  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?
  - explainplease 9y ago
    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.
barbs 9y ago
Response from Blizzard: https://us.battle.net/forums/en/bnet/topic/20760626838 https://us.battle.net/forums/en/bnet/topic/20760626838 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.
theossuary 9y ago
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?
- codinghorror 9y ago
  Yes this, Blizzard is a very conscientious company in everything they do. I'd absolutely trust them. (Also not sure if anti-cheat is a factor here?)
- TaylorSwift 9y ago
  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?
throw7 9y ago
The issue exposes the trust issue of the CA house of cards. You, as the user, are really trusting in a third party to "do the right thing".

198 points by roblabla 9y ago

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.

johansch 9y ago
Why in the world would they do this, though? I'm at a loss. Arent' they making lots of money off these poor addicts already?
- AFNobody 9y ago
  There is stuff they do for cheat/crack detection that involve https is the only thing I can think of.
  - nrhk 9y ago
    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.
    - deleted 9y ago
      [deleted]
    - skate22 9y ago
      Kickbots in WoW are annoying as hell too.
  - revelation 9y ago
    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.
    - Fnoord 9y ago
      It is just one of the many defenses they use. 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.
- scrollaway 9y ago
  The actual reason they'd do this is a follow up to this thread from @taviso: https://twitter.com/taviso/status/939634523137966080 https://twitter.com/taviso/status/939634523137966080
PeterStuer 9y ago
Small correction. I think that the average WoW player's age is well above 30 at this point.
- dogma1138 9y ago
  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.
cyansmoker 9y ago
Correction: Innocent version: we did nothing wrong and you are reacting before having even looked at that certificate.

mikestew 9y ago

“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?

noncoml 9y ago
Is the word "silently" your only concern here? Not the fact that Blizzard installs a root CA, silently or not? Or are you trying to derail the conversation on purpose?
- mikestew 9y ago
  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.
  - noncoml 9y ago
    Oh. Apologies then.
enzanki_ars 9y ago
It wasn't silently added: > 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.
- taneq 9y ago
  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.
bagacrap 9y ago
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.

5ilv3r 9y ago

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.

kodablah 9y ago
> This is how the system was meant to work. 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.
- 5ilv3r 9y ago
  They could. That would be a bit tricky though since http libs usually use the shared system cert store.
  - kodablah 9y ago
    Any reasonable one would allow you to change the trust store or approach programmatically.
    - 5ilv3r 9y ago
      My argument was that centralizing trust as a service is unsustainable. That's all.
  - xxs 9y ago
    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.
1_2__4 9y ago
You appear to lack any authority or knowledge here because almost every part of your comment is completely wrong.

gnu8 9y ago

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.

hrrsn 9y ago
Buying a wildcard cert means they can mismanage their keys for *.battle.net. Having a CA means they can mismanage any domain.
- wyldfire 9y ago
  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" 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.
chacham15 9y ago
Not just that, blizzard themselves could pretend to be Google.

kup0 9y ago

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.

kodablah 9y ago
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).
- kup0 9y ago
  Oh, didn't think about the issue happening on multiple platforms. That does complicate things.

kbd 9y ago

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.

Ajedi32 9y ago

I'm guessing this is Blizzard's response to [their previous cert being revoked][1]. [1]: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/pk039T_wPrI https://groups.google.com/forum/#!topic/mozilla.dev.security...

kbwt 9y ago
So it may have been intentional. Couldn't this expose Blizzard employees to criminal charges? Edit: This was written assuming CA bit = 1.

kondbg 9y ago

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.

tptacek 9y ago
Good catch.
tialaramex 9y ago
"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.
- zaroth 9y ago
  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.
  - tialaramex 9y ago
    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.

ChuckMcM 9y ago

For what ever reason I always assumed this was to prevent the game client from being used with unoffical servers.

AaronFriel 9y ago

I just checked and found "Blizzard Battle.net Local Cert" in certmgr on my home Windows 10 desktop. The thumbprint is e8e6a2932ae8de6eb3b555270b55fdc72b7db7b7, but it's limited to the subject alternative name "DNS Name=localbattle.net".

kbwt 9y ago
Could you (or anyone else) upload the certificate file for inspection?
- AaronFriel 9y ago
  -----BEGIN CERTIFICATE----- MIID1jCCAr6gAwIBAgIDAKCkMA0GCSqGSIb3DQEBCwUAMIGSMQswCQYDVQQGEwJV UzETMBEGA1UECAwKQ2FsaWZvcm5pYTEPMA0GA1UEBwwGSXJ2aW5lMR8wHQYDVQQK DBZCbGl6emFyZCBFbnRlcnRhaW5tZW50MRMwEQYDVQQLDApCYXR0bGUubmV0MScw JQYDVQQDDB5CbGl6emFyZCBCYXR0bGUubmV0IExvY2FsIENlcnQwHhcNMTcxMjIx MjEzNDAxWhcNMjcxMjE5MjEzNDAxWjCBkjELMAkGA1UEBhMCVVMxEzARBgNVBAgM CkNhbGlmb3JuaWExDzANBgNVBAcMBklydmluZTEfMB0GA1UECgwWQmxpenphcmQg RW50ZXJ0YWlubWVudDETMBEGA1UECwwKQmF0dGxlLm5ldDEnMCUGA1UEAwweQmxp enphcmQgQmF0dGxlLm5ldCBMb2NhbCBDZXJ0MIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAv4ih+a9V+dd+l97hTyWYLg+b1aj6UrgREMvLv0PFoE63eozs oFAvjr/0QVCt8RJg2aIF1OZSfc4c9PWkSktFvKB2vMRbVkSwhZvlpDLdQdgD89q9 XZnWv8KmB1w7R7RUzYhNv5IBfqx77hdpMsdfhMAsVu9UNi7Bowhk2Lyk+NSIMMbY f6TvgoWLLz6Glw1mGSl8ki2SzaFj6xTNdKo56knZBy9wHQlmjv7GVltwmcVeyARC 3Q4qG/tG7t9CchCNUWHMP1Uxc9t2hZbQIjJRIE+h7Njp7A5nNIO0XXkJpKdtank/ Q2+CJNdoX7kNi7frB3y+TVSNYTNxh6bfDyueEwIDAQABozMwMTATBgNVHSUEDDAK BggrBgEFBQcDATAaBgNVHREEEzARgg9sb2NhbGJhdHRsZS5uZXQwDQYJKoZIhvcN AQELBQADggEBABFtIjAcF6vgXBWUACc+nvKwLUUAuIDigK+PpTJZ+eqvJd2gjPG+ i9tfSe3Y0uWeHgNAtV3bwV/pEp8jPj0KyS7aYM2QhS2Gezy2NN7RjXtU+tFItwQ3 ykHQsqG5F+KqpDFZrbmuPkXUB9TihxG9aGATBOzhw18RV7hlf/y+60LDMF+8BoYY AVJ6wDUcYsuO4PQ2DE3DlJJokUsITUlzWYn60Kmo96NG0MST/Zg3bLLC3gxclZb/ vkK/pVha6I8kRyPFkfwIS/4Z/HCwHX9RAxbBaOxGqaN3XgcsR9hGBZD6DRA6iF1u XfkZ9zz/NfgVIx+AJmyw32X1T5HRcmMhZZ4= -----END CERTIFICATE-----
  - jwilk 9y ago
    "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>

szastupov 9y ago

Well, they are very sloppy about security, look at the permissions they set for battle.net files https://pbs.twimg.com/media/DOvhmJ1WkAAFCSD.jpg https://pbs.twimg.com/media/DOvhmJ1WkAAFCSD.jpg (sorry for screenshot)

sannee 9y ago
I mean, sure, it's not exactly in good taste, but noone really uses multi-user desktop setups these days...

jwilk 9y ago

> The expiration day is December 19th, and since certificates are usually generated for a certain number of years, that means it was just created. You could look at the "Not Valid Before" date, which is 2017-12-21.

xwvvvvwx 9y ago

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? [1]: https://twitter.com/chort0/status/943933566596952065 https://twitter.com/chort0/status/943933566596952065

xg15 9y ago
I think the root problem is that apparently connections to http://localhost http://localhost from a https:// 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 http://localhost not possible due to mixed content and connections to https://localhost 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-arent-mixed-content-connections-allowed-on-localhost https://security.stackexchange.com/questions/104801/why-aren...
- user5994461 9y ago
  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.
  - xg15 9y ago
    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.

bitL 9y ago

Have a separate gaming machine for games only. You can't trust anyone these days.

Cookiesaurusbex 9y ago
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?
- explainplease 9y ago
  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.

barbs 9y ago

Response from Blizzard: https://us.battle.net/forums/en/bnet/topic/20760626838 https://us.battle.net/forums/en/bnet/topic/20760626838 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.

theossuary 9y ago

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?

codinghorror 9y ago
Yes this, Blizzard is a very conscientious company in everything they do. I'd absolutely trust them. (Also not sure if anti-cheat is a factor here?)
TaylorSwift 9y ago
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?

throw7 9y ago

The issue exposes the trust issue of the CA house of cards. You, as the user, are really trusting in a third party to "do the right thing".