Researchers have uncovered an extremely critical vulnerability in recent versions of OpenSSL, a technology that allows millions of Web sites to encrypt communications with visitors. Complicating matters further is the release of a simple exploit that can be used to steal usernames and passwords from vulnerable sites, as well as private keys that sites use to encrypt and decrypt sensitive data.
Credit: Heartbleed.com
From Heartbleed.com:
“The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop communications, steal data directly from the services and users and to impersonate services and users.”
An advisory from Carnegie Mellon University’s CERT notes that the vulnerability is present in sites powered by OpenSSL versions 1.0.1 through 1.0.1f. According to Netcraft, a company that monitors the technology used by various Web sites, more than a half million sites are currently vulnerable. As of this morning, that included Yahoo.com, and — ironically — the Web site of openssl.org. This list at Github appears to be a relatively recent test for the presence of this vulnerability in the top 1,000 sites as indexed by Web-ranking firm Alexa.
An easy-to-use exploit that is being widely traded online allows an attacker to retrieve private memory of an application that uses the vulnerable OpenSSL “libssl” library in chunks of 64kb at a time. As CERT notes, an attacker can repeatedly leverage the vulnerability to retrieve as many 64k chunks of memory as are necessary to retrieve the intended secrets.
Jamie Blasco, director of AlienVault Labs, said this bug has “epic repercussions” because not only does it expose passwords and cryptographic keys, but in order to ensure that attackers won’t be able to use any data that does get compromised by this flaw, affected providers have to replace the private keys and certificates after patching the vulnerable OpenSSL service for each of the services that are using the OpenSSL library [full disclosure: AlienVault is an advertiser on this blog].
It is likely that a great many Internet users will be asked to change their passwords this week (I hope). Meantime, companies and organizations running vulnerable versions should upgrade to the latest iteration of OpenSSL – OpenSSL 1.0.1g — as quickly as possible.
Update, 2:26 p.m.: It appears that this Github page allows visitors to test whether a site is vulnerable to this bug (hat tip to Sandro Süffert). For more on what you can do you to protect yourself from this vulnerability, see this post.
So what should a full https ecommerce site do besides upgrade OpenSSL on their server?
Do they need to request new SSL certs from their provider?
Reset all customer passwords?
Reset all passwords pertaining to anything on the server… api, ssh?
The OS will protect against applications encroaching on other applications memory, so you only need to be concerned about passwords and keys used by the web server software, applications, and anything else that uses OpenSSL itself. This may include OpenSSH keys.
The bug potentially means that any information transferred over HTTPS to your webserver, at any time, now or in the future could be read by an attacker.
At minimum, you will need to
1 – apply the patch
2 – revoke your SSL certificates and replace them with new certificates
3 – Carefully examine all your server logs for evidence of any other attacks or suspicious usage of passwords, etc. (The actual heartbleed vuln leaves no trace if exploited)
You should also inform your customers that the site was potentially vulnerable, but the vuln has been closed. Advise customers that this might mean that any data they sent to the site may not be secure.
Customers should be advised to change their passwords, especially if the same password was used other sites. Additionally, as credit card numbers/CVV numbers, etc. might have been exposed, customers may wish to replace their credit cards.
It’s also plausible that if someone had a dump of encrypted data in the past, it’s more exploitable now (One can get the key, then the data, or get the data, and then the key).
If the above is true, then your statement becomes “any data past, present, or future”. The patching of code and changing of certificates doesn’t protect the old encrypted data captured (and stored for this event) being decrypted with old keys (they certainly would not use new keys to decrypt that old data. :). The old captured data will still be encrypted with the old key.
This is why I’ve previously pointed out that the value of data isn’t linear and doesn’t always decline with age. Like an antique car, it can change and become valuable again.
Whether this particular exploit becomes the poster child of the problem is unclear. However it is close enough that folks should be able to see how the risks can carry forward indefinitely.
It’s worth noting that perfect forward secrecy mitigates the damage done by key recovery. Since it uses an ephemeral (one-time-use) key for every connection, the attacker would have to recover the key for your specific connection; the instant the SSL implementation is patched, this is no longer possible. Past connections are not vulnerable, and even if they have the website’s RSA private key, they can still only perform man-in-the-middle attacks and not just passively decrypt data. Not that man-in-the-middle attacks aren’t a serious threat; if they weren’t there would be no need for CAs in the first place.
Note that I’m only talking about the damage of recovering the static private key. They might still get your passwords, credit card data, etc.
I agree with you that implementing a ‘one time’ encryption like the so called perfect forward secrecy (FPS) mitigates that particular problem. Though I imagine a long running connection, or concurrent connection would be exposed, so I would be hesitant to call it “perfect” (I know it’s the name, not your choice). 🙂
However one could imagine that PFS someday has a flaw announced that makes it not so perfect, and not so forward.. and it’s back to the present problem of old data creating problems in the future. If there is a non-zero chance of that event happening, or to put it stronger, if there is a chance a library for security has a flaw that compromises previous data then if we gamble long enough that event will happen.
As of today, if PFS is found to be broken then it’s a smaller problem than the SSL bug given it’s smaller implementation footprint. If we move the ‘best practices’ to PFS then we pile up the risk into PFS.. so that it takes SSL’s role in a future “goto fail”. Interestingly, it’s success would make it a bigger ‘prize’, so it’s arguable that it’s safer now than it will be if adoption is more widespread. While security by obscurity is a statistical game, it does change the odds of the game for any given finite period.
JasonLA mentioned the problem briefly in another post; it’s the problem of putting all one’s eggs in one basket. At some point folks are going to have to realize that addressing the size of the basket is essential for aggregate security instead of hardening the hard targets while softening the soft targets.
In any event, I agree with you FPS would address the specific problem of giving up keys to allow easy decryption of past data streams. The aggregation, in this case within the SSL library allowed the co-mingling of data that should never have been co-mingled, and there is where I think real progress can be made (The design, as I understand it, was to re-use (aka share) the same memory blocks for different users). Like sharing eating utensils it’s all fine so long as no one is sick.
anyway, I agree that PFS addresses some of the temporal issues and would love to see it used more widely. My fear is that folks may think they have things handled again (“we have it now!.. ooops.. ok..now we surely have it.. oops.. etc) and build up scale even more.
regards,
Lee
LastPass has released a Heartbeat site test tool that offers more helpful info than any of the others I’ve tried, such as the security cert issue date.
See https://lastpass.com/heartbleed
That checker is almost useless. It says “system runs Apache so it might be vulnerable”. Big help. It could have just displayed that as a static string and had a better than 50/50 chance of being right.
that lastpass checker is just about worthless when it ends up saying almost every site that you check is vulnerable!!! doesn’t give any indication if a site is fixed when other news reports may say a particular site is fixed.
Cloud Identity providers like Okta were affected, their customers will likely have to do a lot of clean up as a result of having usernames/password, cookie and certificate information being exposed
NOT True, either you are grossly misinformed or you are intent in spreading false truths for the purpose to hurt vendors like Okta or benefit your own agenda
Everything for all their customers was exposed, simple fact man. Know what wasn’t exposed? ADSF
I tested the exploit against a number of servers still vulnerable to it and…found nothing interesting. There was nothing that stood out to me as looking like a password or even a username. Are passwords really just floating around, in plaintext, in cached RAM? This is something that actually happens?
It depends on the web server. Before I updated one of my web services, I was able to observe the complete last web request made to that specific nginx process. If the last request was a login request then both the username and password were visible. For most other requests I could steal the cookie, though my cookies are bound to IP address, so fortunately, that’s not terribly useful.
Great that I use a password manager and changing passwords is easy for me. But changing all those 500 of them will be hard. And I use Sticky Password manager http://www.stickypassword.com if anyone is interested.
I’m not really worried about websites like Facebook and Twitter…my banking information is a LOT more important than someone hacking my social media accounts.
I’m hoping that corporations like Wells Fargo, Bank of America and Capital One are updated to the latest non-vulnerable version of SSL…don’t want to have to see another major headline about the millions of compromised data…
TOR’s client uses OpenSSL!
Most Apache servers use it as well.
Brian, thanks for the heads-up on this. Have already identified a couple of banking sites that we use which appear to be vulnerable. Keep up the GREAT work!
Care to share how and
the names of the compromised,
(ie: still vulnerable) banking sites you found?
That would help us all…
and would certainly get their behinds moving to fix it!.
Nothing like exposing those security-lazy companies
in the limelight…
“Security lazy” <– seriously? Sheesh that's harsh man.
For the non-techies among us (like me), when I check the Top 1000 list you linked to, some sites are listed “not vulnerable” and some say “no SSL” — what’s the difference??
The difference is subtle between “not vulnerable” vs “no SSL”.
It’s basically similar to the difference between a bank where the vault is secured, vs a bank that doesn’t have a vault at all.
The ‘not vulnerable’ might turn into ‘vulnerable’ in the future.
Another way to say it: “not perceived as hackable” vs “nothing to hack”.
Thank you for that information, Brian. Recently my Discover Card account was hacked. They logged in to my account, changed email address, and had the cash back reward sent to their account. I couldn’t figure out how they would have been able to get my information.
What is optimal time to change passwords? My understanding is that fixes will be applied by various servers over next few days/weeks. Is it too early to change now, since few are fixed? Or should I change PW now and again in a week or so?
Excellent question!! (Anyone know the answer?) If I am told that my email server is vulnerable, won’t my changed password be compromised too.
When do we know to change pw, so it is safe. In the meantime, is there ANYTHING we can do??
Don’t log in until they fix it (and possibly replace the cert as well) and your password can’t be stolen (if it hasn’t already been).
Sounds reasonable. (So it steals from fairly recent memory, I’m guessing…) Thanks for the tip!
Good advice!
But…
how will I know when a particular bank, etc
has fixed their server/site?
By email?
What if the miscreants have sent the email
requiring entering a new pwd,
instead of sent by the bank, itself?
See the multiple dangers here?
You can use one of the online tools referenced in the other posts to see if they are vulnerable periodically. You can also check the cert to see if it’s been reissued since the site flipped from vulnerable to not. It’s not easy, but it’s possible.
And a site shouldn’t send you a link to change your password. They should send you an email telling to you go to the site and change it yourself from there. If they send you one, type in the address yourself.
Used that http://filippo.io/Heartbleed/ site to check the major sites of my accounts to see if “safe” (of course no guarantees there) and then changed passwords. BUT probably will change again in a few days or a week, and then maybe again.
What if I have an older version installed (0.9.8x)? I just inherited this box (AIX 7.1), and haven’t had the time yet to determine if I even need openssl on it.
Then you aren’t vulnerable to *this* bug.
OpenSSL maintains a list of vulnerabilities: http://www.openssl.org/news/vulnerabilities.html
You could be vulnerable to:
CVE-2013-0169: 4th February 2013
A weakness in the handling of CBC ciphersuites in SSL, TLS and DTLS which could lead to plaintext recovery by exploiting timing differences arising during MAC processing.
Damn.
OpenSSL Heartbleed Bug.
WinXP no more support.
Apple GotoFail Bug.
California DMV Hack.
Target Hack….
And, of course, all the fallout from the Snowden leaks.
It’s like the End of the World with all these dominos falling.
Almost makes you want to give up, and not use the internet anymore, and want to cut up my visa cards and mastercards, and take all my money out of my bank accounts, etc. etc. etc., and go off grid.
All the dominoes except the ones on Wall Street.
;-]
Don’t forget BITCOIN! 😀
Is that you, fonestar? 😉
Until we have a better sense of how websites are working to address this risk, is it “safe” to use banking apps on a smart phone just to keep an eye on things? I want to avoid logging into my bank account via the website. Thank you!
Hi, mobile apps rely on SSL just the same. They are fancy “web sites” with an application as the front end. But behind the scenes it’s basically doing the same thing. In fact, they often use different networks. So a mobile site could be vulnerable while the online banking site is not. It’s harder to check mobile sites unless you know the URL. Most banks are coming out with press releases…..which I would trust. We are so highly regulated, they will not lie about vulnerability. If a bank says they are not vulnerable, the only way they are is if they are ignorant.
I’d still trust online banking over snail mail any day. When you mail a check……
Does the heartbleed bug affect certificate-based VPN?
I run my own OpenVPN server with server and client certificates created by openssl v 1.0.1e. I presume that my certificate authority, server certificate, all client certificates, and my Diffie-Hellman certificate are all compromised. Is this actually true? I’d like to test the VPN server at filippo.io/Heartbleed, but my VPN server is configured for UDP.
Does anyone know if heartbleed compromises certificate-based VPN servers? If so, this bug is a lot worse than the already huge impact on web servers.
According to OpenVPN’s James Yonan,
I’d like to point out that storing your private keys in an HSM (Hardware Security Module) would avoid that part of this problem. The memory scraping is still horrible, but at least the key and cert wouldn’t be compromised. This problem is making me really glad that my employer mandates HSMs for these situations. (Luckily, we also use non-OpenSSL based external infrastructure too.)
There’s an opportunity here for some security company to put together a database of the top sites vulnerbility status and certifcate issuance date. Then you could lookup sites that had been compromised and were then fixed and the cert reissued. That would let you know when you need to change your password. Maybe even let people subscribe for notifications when a given site flips from compromised to safe(r).
It would also be possible to add a browser plugin to warn users of compromised sites and possibly even prompt them to change their password on the first visit after the site flipped from compromised to not.
For a plugin, the plugin could give a red status to vulnerable, yellow to not-vulnerable but was since the last cert issue date, and green to known good (and possibly allow a site ower to record the site as using HSM protected certs to also get the green status).
Question for Brian and anyone else expert in how the black market for the use and development of these exploits works:
Is it likely that, had this exploit been developed by a criminal enterprise or person, it would have been quickly sold in large quantities on the black market, thereby also alerting the rest of the world to the existence of the exploit?
Or is it likely that such an exploit would be kept confidential and used by a small number of enterprises or persons?
Are there any cases of exploits which were successfully kept confidential and used over a lengthy period of time without the security world becoming aware of their existence?
Analytically, there are good arguments for both possibilities assuming that criminals are somewhat rational. On the one hand, one can make a stream of income from an exploit kept confidential, but that’s a lot of additional work and risk; on the other hand, one can make faster money by selling the exploit to others, but this comes with risks of its own and the sale will have to be at a steep discount to any potential streams of revenue.
Curious as to how all this plays out in reality.
The exploit is trivial. The bug was in open source code and the mere fixing of it identified the vulnerability. There is no financial value to the exploit itself.
My main worry is that cybercrims have and will focus on collecting as much raw memory snaps as possible then look through the catch for goodies. I expect we may see phishing emails requesting people to change their password. Worst case is an spoofed web site with an exfiltrated cert that makes a link look legit.
I am sorry, I am not a web, computer or code language literate!! But I do know how to use them well, so can someone throw some basic light on What does an OpenSSL really mean and Do? – for eg. what really happens to my username and password, when I type in a web page, how does it travel? where does it stop to pick up another means of transport until it gets to the destination where it is checked that its is me that is asking for access to my account… so please let me access it. Also: who in my destination path will know what am I sending and who will copy or hijack it before it gets to the correct destination?
Also what does [if it exists] ClosedSSL mean? and why is it bad for majority of OpenSSL users NOT to use it?
Thanks! – hope this Qs make some sense?
In an effort to avoid recreating the wheel, developers usually rely on libraries as building blocks for parts of their applications. Each library implements a set of reusable functionality. For instance, if I were building a software car or a softwhere wheelbarrow, I could start both projects with a “wheel” library. OpenSSL is a library for doing asymmetric encryption operations such as the SSL that encrypts web traffic. OpenSSL also happens to be free so it’s widely used by many other software projects. Some of those projects (like Apache – a webserver) as also free and generally high quality, so they are widely used. The upside is quicker, cheaper products and most of the time, it’s higher quality than when a bunch of general developers are trying to code a very specialized technology. SSL and all of its building blcoks is very hard to do right so it would be bad if every product tried to write their own. Statistically, the vast majority of times they’d do it very poorly and generally insecurely. However, there is a bit of “putting all of your eggs in one basket” syndrome here. So when the library has a security (or other) defect, then many applications have that defect.
I like Jason’s answer to why developers use libraries. Nothing to add other than a good library makes developing software enjoyable, a bad library makes it a nightmare.
The net routing is another topic. You can get an idea of the route the data takes by tracing the route (various utilities such as ‘ping’ can do this for you). But the problem is that packets can take different routes (e.g. If there is congestion on route A, then packets are sent on route B) so you can’t be sure which route the packets will take, or have taken. If you are on a completely private topology then you have control over this, but for regular folks it’s basically “get it there anyway you can, and quicklly!”.
This often is why SSL is used (Secure Socket Layer). It relies on the encryption to make the data ‘safe’ from prying eyes and create a virtual pipe that the two ends can communicate through.
This particular SSL lib bug is like the Get Smart ‘cone of silence’. You are not likely to know what path your data took, but you can assume that the folks from Kaos heard and recorded every garbled word. Then you find they may have the decoder key and you get the picture that the SSL lib “missed it by that much”.
re: need for better user authentication of systems
When I read through the comments, I see that folks are basically asking “how do users authenticate the systems they are using?”
The heartbleed bug is similar to the problem with credit cards. We are focused on authenticating access by the users, not in authenticating the system TO the users. JasonLA’s note that ‘it’s not easy’ to find out if a website has actually repaired SSL is similar to the problem of consumers trying to figure out if the atm machine is a ‘real one’.
I’ve found a major discrepancy (as I’m sure that many of you have) within the online-media-world-of-hysteria, that one “expert” says that the typical end-browser-user should change all of their passwords immediately; whereas another will say to wait to change one’s passwords as changing passwords would involve a login, thusly loading fresh data into the plethora of compromised servers.
The latter seems to make sense to me. I would greatly appreciate anyone’s thoughts on that.
Yes, you’re right. It only compounds the issue for consumers if they change their password at sites that a) haven’t fixed this flaw and b) maybe they haven’t even visited recently. So, check the site with the various tools now available to see if it’s vulnerable, before changing a site password.
would really like to see a report as to WHEN major sites actually got fixed, like with the EXACT DATE and TIME when fixed (or when they publicly say it was fixed). that would help if you changed passwords already and want to know if you jumped the gun and have to change the passwords again.
of course, probably have to change passwords again. but more exact information of this sort would be helpful in this annoying worrisome situation.
Your comment/reply here differs with what the New York Times cites you as saying.
Ken,
It may surprise you, but often times when publications quote you, they don’t use everything you say.
So you are saying half the Yogi Berra quotes might not be Yogi Berra quotes? 🙂
ok.. I change my recommendation for folks to watch Ocean’s 11 while they wait for a site to be fixed to ‘watch it twice’. 🙂
Two serious observations: 1) people seem jittery 2) patience is a virtue
the popular news media (particularly when the reporters most likely don’t fully understand what they are reporting on) will tend to over exaggerate or somehow bend or somehow spin a fact or a quote to cover everything or to be about something else although the fact or the quote is really specific to one thing. it’s like they only hear one thing and want to apply that to everything or say it somehow is also with regard to something else. this is why you have to go the source or go search for more details to see for yourself to confirm what was the exact fact or what was exactly said and with regard to exactly what.
I agree with Brian, and while waiting for the site to be fixed before changing your password (or logging in) I suggest watching the movie “Ocean’s 11”.
As another poster noted, the exploit may also steal cookies, so having those muted (erased, disabled, blocked, or whatever technique you prefer) might be a good idea if visiting the site.
What Is Heartbleed? The Video , A very good explanation
http://techcrunch.com/2014/04/08/what-is-heartbleed-the-video/?ncid=tcdaily
sorry but a dumb question. if you have an account that is said to be vulnerable to this heartbleed bug, but you have two-factor authentication turned on for that account, are you still at a high risk or is your risk somewhat lower???
Like most things in security, it depends. If the 2FA system uses one time passcodes, then your authentication credentials are more secure. But the rest of the data (e.g. bank data if its a banking app) will still be vulnerable and if the cert isn’t hardware based, you’d also be vulnerable to a man-in-the-middle attack which could steal your authentication session.
Sounds like the ID part of the 2-factor authentication would also be compromised in his scenario. It is usually minor, but it is less secure than not being exposed (This is because one has to identify before authentication can proceed.).
Depending on the level of security desired, a second factor failure could trigger an alert and start a reset process (like the old call-back teletype.. if you could not reach the user on the call back, it’s a signal of attempted breach).
Such an alert could (and arguably should) cause the user account ID to be locked until recreated anew to restore the same level of security as before the attempted breach (both the ID and authentication returns to unknowns to the attacker).
anyway, excellent answers Jason.
Very well written answer.
I had considered suggesting 2FA for one of my earlier comments, but I decided against it. The problem indeed is the risk of a MITM attack.
What are banks doing? The certificate on my bank’s website has not bwe updated. I called to ask. I was told not to worry, that I was protected from any loss or liability.
I’ve checked my banks and none of them show as vulnerable. They are more likely to use SSL terminating firewalls and commercial, not apache web servers. Some even store their keys in hardware security modules which would keep them out of memory.
Technically, I agree with Jason. However, the idea that banks protect you from loss only works when the aggregate loss is one they can absorb, and even that cost is passed onto the economy. The idea of aggregated risk being safer was proved false with the financial disaster of combining many mortgages into collateralized mortgage backed securities (CMBS)and marketing them as ‘safe’ because there were lots of them in the CMBS. They then scaled up their bets under the false pretense it was safer.
The banks historically have equated a larger pile of stuff to being safer. All that does is move the risk into fewer, yet larger impact events. It’s surprising that after the financial crisis we see banks still peddling the Gaussian distribution fallacy.
In plain english translation,what the bank told him was don’t worry unless it’s really big, in which case you are paying for it (just like the housing crash where we all paid). Of course the costs of smaller breaches are passed along, but he won’t notice it.
In this particular case the bank is likely right that it’s small enough that they can absorb those risks. Yet even on this it’s not out the question that some entities pull an MFGlobal and trigger a bigger mess.
The actual costs, even on small issues are ultimately borne by everyone (including hackers), in higher bank fees, higher prices, taxation/services, or even slower velocity of money in the economy (reduced GDP). I would like to see banks and others cease propagating the myth that these things don’t cost anything to the consumer.
anyway, I wish the banks would stop saying that stuff as they become part of the problem when they do that. I understand that it’s part of the ‘difuse a bank run’ PR, but there must be a more responsible way of instilling confidence other than false promises (CEO of IEX made this very point during the recent impromptu HFT debate on CNBC). To the banks that might read this, please look for a more accurate tactic than the ‘don’t worry, we have you covered’ line. As one can see by the poster’s question, they didn’t know whether they can believe their bank. That should tell the bank that their credibility needs work.
I agree with Jason’s technical reply, but the question highlights the problem of scale. Instead of ‘too big to fail’ we have “too big to be hacked”. I’m still hopeful we will learn something from the financial crisis, but the jury is still out on that.
That’s a valid point Lee. The other layer is that call center staff just parrot whatever line they were fed by their lawyer 8th hand. That smacks of a stock answer that’s accurate and useless all at the same time.
Can someone comment on the impact of this bug on a site that requires client certificates?
I suspect that it would still be vulnerable but only an attacker with a trusted client certificate would be ankle to establish a session and trigger the exploit.
I was wrong. I found this statement on heartbleed.com:
“Does TLS client certificate authentication mitigate this?
No, heartbeat request can be sent and is replied to during the handshake phase of the protocol. This occurs prior to client certificate authentication.
“
Amazing that I haven’t seen anything from my cloud based identity provider on this issue. I think my info was exposed.
Outlook.com is (or was) vulnerable? Here it says “NO SSL”
https://github.com/musalbas/heartbleed-masstest/blob/master/top1000.txt
:S:S
Interesting. Can i republish this in our site….
http://zerocoolstuff.com
You are quoted in the New York Times as recommending that people change there password now and then again later. It seems to me that doing this would have large numbers of people exchanging passwords with servers at just the time when the largest number of potential attackers are most aware of the opportunity. Wouldn’t it be better to stay off the websites entirely until those sites “test positive” on updating their software and only then change your password?
I told the reporter that people should do their level best to worry about only those sites they’d visited in the past few days, and to check the sites that they wish to change their passwords for against some of the many online checking tools available to see if the sites were still vulnerable.
Brian, you should have told the nytimes that all their employee data was exposed on their okta site.
Where is the proof of that?
Here’s an interesting writeup on some major social, email, banking, and tax sites vulnerbility status (past and current): http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/#:eyJzIjoiZiIsImkiOiJfY2d4NmsyMDdpbnZycTBpbiJ9
Interestingly, a couple of them contridict what I’d seen from some other sources including some linked here (e.g. Google was impacted).