STE WILLIAMS

Website analytics outfit Mixpanel has admitted to harvesting passwords.

Mixpanel provides a suite of services to help web publishers improve engagement. Among those services is “Autotrack”, which promised the chance to track just about every aspect of a user’s visit to a website. Including, it has been revealed, their passwords.

The issue became public when a user uploaded Mixpanel’s mea culpa to Reddit.

“On January 5th, 2018, a customer informed us that they observed Autotrack sending the values of password fields in events,” the message said. “We confirmed that this was unexpected behavior; by design, Autotrack should not send the values of hidden and password form fields.”

The note goes on to explain that the bug was introduced in a change to the React JavaScript library dating back to March 2017, but it does not believe any third party accessed the information.

Princeton privacy professor Steven Englehardt, who last year warned that replay analytics breached privacy, Tweeted his opinion that Mixpanel meant to filter out sensitive information, but its heuristic failed.

[2/7]How does one retroactively collect form inputs? From what I can tell, Mixpanel saves all input data from the time of install and uses a heuristic to filter out “sensitive fields such as password or hidden fields”.

The password leak was caused by a failure in that heuristic.

— Steven Englehardt (@s_englehardt) February 5, 2018

Later in that thread, Englehardt added that scraping user data should be considered an “inherently insecure process”.

Mixpanel users need to update their SDK version to stop grabbing passwords, and the company said “we’re adding some additional explicit checkpoints in our product development processes to help ensure that we’ve considered all of the impacts of the changes we make.”

The company also discovered a second slip-up in its own software, noting that since August 2016, password scraping could happen if the Website visitor used plugins that “place sensitive data into form element attributes.” ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/02/07/mixpanel_slurped_passwords_in_library_update_slip/

Website analytics outfit Mixpanel has admitted to harvesting passwords.

Mixpanel provides a suite of services to help web publishers improve engagement. Among those services is “Autotrack”, which promised the chance to track just about every aspect of a user’s visit to a website. Including, it has been revealed, their passwords.

The issue became public when a user uploaded Mixpanel’s mea culpa to Reddit.

“On January 5th, 2018, a customer informed us that they observed Autotrack sending the values of password fields in events,” the message said. “We confirmed that this was unexpected behavior; by design, Autotrack should not send the values of hidden and password form fields.”

The note goes on to explain that the bug was introduced in a change to the React JavaScript library dating back to March 2017, but it does not believe any third party accessed the information.

Princeton privacy professor Steven Englehardt, who last year warned that replay analytics breached privacy, Tweeted his opinion that Mixpanel meant to filter out sensitive information, but its heuristic failed.

[2/7]How does one retroactively collect form inputs? From what I can tell, Mixpanel saves all input data from the time of install and uses a heuristic to filter out “sensitive fields such as password or hidden fields”.

The password leak was caused by a failure in that heuristic.

— Steven Englehardt (@s_englehardt) February 5, 2018

Later in that thread, Englehardt added that scraping user data should be considered an “inherently insecure process”.

Mixpanel users need to update their SDK version to stop grabbing passwords, and the company said “we’re adding some additional explicit checkpoints in our product development processes to help ensure that we’ve considered all of the impacts of the changes we make.”

The company also discovered a second slip-up in its own software, noting that since August 2016, password scraping could happen if the Website visitor used plugins that “place sensitive data into form element attributes.” ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/02/07/mixpanel_slurped_passwords_in_library_update_slip/

The researcher behind the teaser of a new method to crack Amazon.com’s “Key” connected door locks has revealed how his method works, and criticised Amazon’s response to his work because it detailed the flaw before shipping a fix.

In a Medium Post, the researcher known as “MG” explained that he revealed his riff on an attack vector identified by Rhino Security Labs and publicised his activities.

“A professional researcher saw this and reached out to me, offering to broker a disclosure with Amazon,” MG explained. “Unfortunately, this attempt failed. Amazon turned down the offer by demanding a working PoC be made for them.” MG was also told that Amazon has no bug bounties “or other reward pathways.”

“I wasn’t interested in a reward, but this level of arrogance was off-putting,” he wrote. “So I made the PoC”.

Amazon Key door-entry flaw: No easy fix to stop rogue couriers burgling your place unseen

READ MORE

The Register and others reported his handiwork and – surprise! – Amazon suddenly wanted to talk and MG “started helping them understand the attack.”

“I was impressed with the security response team,” he said, but found that when they asked for his code it “was a bit frustrating in context of the initial ‘lol we won’t give you anything but do work for us’ interaction”.

Amazon’s security team then went quiet. But the company’s PR team started saying MG’s hack was nothing to worry about and then explained it in full to Forbes – but before a fix had been implemented (and without even acknowledging The Register’s inquiries about MG’s initial post

With Amazon revealing details in public, MG decided there was no reason not to disclose his method, which involves scanning the rate of frames produced by Key’s companion camera. That rate spikes when a delivery is made, because the camera records it.

Next, MG employed a WiFi “deauth” attack – a kind of DDOS – on the camera and lock with his Raspberry-Pi-powered WiFi snooper.

“If the timing is right, you prevent a response from the lock informing the consumer app from knowing that the lock event was successful. For whatever reason, the app was not created to handle this error condition. The UI is also nonresponsive, which opens up the opportunity for an inattentive app user to believe they actually pressed the button requesting a re-lock.”

To make the attack more convincing, the RPi plays audio of the Key locking.

MG’s post ends with a host of questions for Amazon about different ways to fool homeowners, delivery staff, or both, that would make this crack or others easier to pull off, and expressed his hope that Amazon takes the ideas seriously because its response to his ideas suggests it’s not thinking too hard about how the Key can unlock criminal possibilities. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/02/07/amazon_key_crack_revealed_before_fix/

The researcher behind the teaser of a new method to crack Amazon.com’s “Key” connected door locks has revealed how his method works, and criticised Amazon’s response to his work because it detailed the flaw before shipping a fix.

In a Medium Post, the researcher known as “MG” explained that he revealed his riff on an attack vector identified by Rhino Security Labs and publicised his activities.

“A professional researcher saw this and reached out to me, offering to broker a disclosure with Amazon,” MG explained. “Unfortunately, this attempt failed. Amazon turned down the offer by demanding a working PoC be made for them.” MG was also told that Amazon has no bug bounties “or other reward pathways.”

“I wasn’t interested in a reward, but this level of arrogance was off-putting,” he wrote. “So I made the PoC”.

Amazon Key door-entry flaw: No easy fix to stop rogue couriers burgling your place unseen

READ MORE

The Register and others reported his handiwork and – surprise! – Amazon suddenly wanted to talk and MG “started helping them understand the attack.”

“I was impressed with the security response team,” he said, but found that when they asked for his code it “was a bit frustrating in context of the initial ‘lol we won’t give you anything but do work for us’ interaction”.

Amazon’s security team then went quiet. But the company’s PR team started saying MG’s hack was nothing to worry about and then explained it in full to Forbes – but before a fix had been implemented (and without even acknowledging The Register’s inquiries about MG’s initial post

With Amazon revealing details in public, MG decided there was no reason not to disclose his method, which involves scanning the rate of frames produced by Key’s companion camera. That rate spikes when a delivery is made, because the camera records it.

Next, MG employed a WiFi “deauth” attack – a kind of DDOS – on the camera and lock with his Raspberry-Pi-powered WiFi snooper.

“If the timing is right, you prevent a response from the lock informing the consumer app from knowing that the lock event was successful. For whatever reason, the app was not created to handle this error condition. The UI is also nonresponsive, which opens up the opportunity for an inattentive app user to believe they actually pressed the button requesting a re-lock.”

To make the attack more convincing, the RPi plays audio of the Key locking.

MG’s post ends with a host of questions for Amazon about different ways to fool homeowners, delivery staff, or both, that would make this crack or others easier to pull off, and expressed his hope that Amazon takes the ideas seriously because its response to his ideas suggests it’s not thinking too hard about how the Key can unlock criminal possibilities. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/02/07/amazon_key_crack_revealed_before_fix/

Namecheap has admitted it let customers set up and control subdomains for domain names belonging to other customers, allowing miscreants to distribute malware from strangers’ websites.

These hijacked sites were subsequently flagged up as malicious by Google’s search engine, blocking netizens from visiting them, and piling further misery on webmasters.

Namecheap customer Kirk McElhearn found this out to his cost when he received an alert from Google that three subdomains on his website were hosting and serving out spammy content or malicious software. This was news to him since his hosting administration tool Cpanel was showing no such subdomains existed.

When McElhearn turned to ICANN-accredited registrar Namecheap for help, he got a rather disturbing response. The technical support staff at the US-based biz told him that the issue was down to a “misconfiguration on our nameservers.”

Essentially, some scumbag with a Namecheap account had abused a vulnerability in Namecheap’s DNS setup to tack extra subdomains onto McElhearn’s kirkville.com website, point said subdomains at a web server, and use them to dish out naughty stuff.

“In short, it was another user that added the subdomains to their hosting account,” he was told.

To make matters worse, the subdomains were outside his control. Also, while his legit site uses encrypted HTTPS by default, visitors to the new subdomain were redirected to standard HTTP pages. Ultimately, the subdomains were exploiting McElhearn’s website’s search rankings to lure in netizens.

“If you get a lot of traffic, the bogus pages set up on the sub-domain may inherit some of your website’s prominence, allowing malicious users to serve spam or malware, or to make money by displaying Google ads,” McElhearn explained.

“Interestingly, even though Google flagged these pages as ‘hacked content’ they were still serving Google ads; as if Google really doesn’t care how they make their money.”

After the subdomains were removed, and McElhearn detailed his experiences in a report on Monday, noted infosec pundit Graham Cluley took the registrar to task on Twitter. Namecheap’s response was not what you’d call reassuring:

The issue should be completely resolved very soon. Just an update: https://t.co/K72Dz8mAfI – Additionally, this affected a teeny tiny group of users of our web hosting service, and anyone registering domains are completely safe.

— Namecheap.com (@Namecheap) February 5, 2018

“The issue should be completely resolved very soon,” it said on Twitter. “Additionally, this affected a teeny tiny group of users of our web hosting service, and anyone registering domains are completely safe.”

The biz said it is conducting an audit, and will contact any of its customers who have been affected by its security cockup. Judging from the language used, the issue potentially affected Namecheap’s entire customer base, it’s just that miscreants only got round to targeting a select bunch, and the registrar is now scrambling to find out who got hit.

“They certainly haven’t contacted me about it, outside of the tweet which isn’t what you’d call official” McElhearn told The Register. “And Teeny tiny is not a useful term.”

Thankfully, the subdomains on his site turned out to just be categorized links to daily news articles. But it could have been a lot worse.

So far Namecheap isn’t responding to requests for comment, but if the company is hosting your website you may want to check that you’re not hosting anything nasty. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/02/07/namecheap_subdomain_security_hole/

Namecheap has admitted it let customers set up and control subdomains for domain names belonging to other customers, allowing miscreants to distribute malware from strangers’ websites.

These hijacked sites were subsequently flagged up as malicious by Google’s search engine, blocking netizens from visiting them, and piling further misery on webmasters.

Namecheap customer Kirk McElhearn found this out to his cost when he received an alert from Google that three subdomains on his website were hosting and serving out spammy content or malicious software. This was news to him since his hosting administration tool Cpanel was showing no such subdomains existed.

When McElhearn turned to ICANN-accredited registrar Namecheap for help, he got a rather disturbing response. The technical support staff at the US-based biz told him that the issue was down to a “misconfiguration on our nameservers.”

Essentially, some scumbag with a Namecheap account had abused a vulnerability in Namecheap’s DNS setup to tack extra subdomains onto McElhearn’s kirkville.com website, point said subdomains at a web server, and use them to dish out naughty stuff.

“In short, it was another user that added the subdomains to their hosting account,” he was told.

To make matters worse, the subdomains were outside his control. Also, while his legit site uses encrypted HTTPS by default, visitors to the new subdomain were redirected to standard HTTP pages. Ultimately, the subdomains were exploiting McElhearn’s website’s search rankings to lure in netizens.

“If you get a lot of traffic, the bogus pages set up on the sub-domain may inherit some of your website’s prominence, allowing malicious users to serve spam or malware, or to make money by displaying Google ads,” McElhearn explained.

“Interestingly, even though Google flagged these pages as ‘hacked content’ they were still serving Google ads; as if Google really doesn’t care how they make their money.”

After the subdomains were removed, and McElhearn detailed his experiences in a report on Monday, noted infosec pundit Graham Cluley took the registrar to task on Twitter. Namecheap’s response was not what you’d call reassuring:

The issue should be completely resolved very soon. Just an update: https://t.co/K72Dz8mAfI – Additionally, this affected a teeny tiny group of users of our web hosting service, and anyone registering domains are completely safe.

— Namecheap.com (@Namecheap) February 5, 2018

“The issue should be completely resolved very soon,” it said on Twitter. “Additionally, this affected a teeny tiny group of users of our web hosting service, and anyone registering domains are completely safe.”

The biz said it is conducting an audit, and will contact any of its customers who have been affected by its security cockup. Judging from the language used, the issue potentially affected Namecheap’s entire customer base, it’s just that miscreants only got round to targeting a select bunch, and the registrar is now scrambling to find out who got hit.

“They certainly haven’t contacted me about it, outside of the tweet which isn’t what you’d call official” McElhearn told The Register. “And Teeny tiny is not a useful term.”

Thankfully, the subdomains on his site turned out to just be categorized links to daily news articles. But it could have been a lot worse.

So far Namecheap isn’t responding to requests for comment, but if the company is hosting your website you may want to check that you’re not hosting anything nasty. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/02/07/namecheap_subdomain_security_hole/

Uber’s confessed that it didn’t use multifactor authentication on its GitHub account, an omission ultimately led to the data breach it revealed in 2017 after keeping it secret for more than a year, after using its bug bounty program to bribe the hacker to stay schtum.

It’s now stopped using GitHub for anything other than open source projects.

The not-a-taxi company’s chief information security officer John Flynn revealed the GitHub gaffe in testimony (PDF) before the US Senate Senate Subcommittee on Consumer Protection, Product Safety, Insurance, and Data Security, which on Tuesday February 6th conducted a hearing titled “Data Security and Bug Bounty Programs: Lessons Learned from the Uber Breach and Security Researchers”.

The breach saw a hacker access oodles of data from one of Uber’s AWS S3 buckets. Flynn told the hearing “that the intruder found the credential [for AWS] contained within code on a private repository for Uber engineers on GitHub.”

Flynn did not explain how the hacker accessed that repository, but we can guess at a brute-force or password-guessing attack from Flynn’s testimony that “We immediately took steps to implement multifactor authentication for GitHub and rotated the AWS credential used by the intruder.”

“Despite the complexity of the issue and the limited information with which we started, we were able to lock down the point of entry within 24 hours.”

“We ceased using GitHub except for items like open source code,” he added.

Flynn also confessed that its bug bounty program was “not an appropriate vehicle for dealing with intruders who seek to extort funds from the company.” But he also defended its use on grounds that doing so “assisted in the effort to gain attribution and, ultimately, assurances that our users’ data were secure”, while also noting that extortion is not what bug bounty programs should ever reward.

Video testimony from the hearing was not available at the time of writing, so we’re unable to report on Flynn’s answers to any questions directed his way.

We asked GitHub if it was aware Uber all-but-dumped it, and if it has responded to the breach in any way. We did so partly to see what it knew, and partly because Uber dumping GitHub when it hadn’t secured its own repos properly seems a bit harsh.

GitHub responded, telling us “This was not the result of a failure of GitHub’s security. We cannot provide further comment on individual accounts due to privacy concerns.”

“Our recommendation is to never store access tokens, passwords, or other authentication or encryption keys in the code. If the developer must include them in the code, we recommend they implement additional operational safeguards to prevent unauthorized access or misuse.”

Uber’s followed that advice: Flynn said its code now includes only auto-expiring AWS creds. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/02/07/uber_quit_github_for_custom_code_after_2016_data_breach/

Uber’s confessed that it didn’t use multifactor authentication on its GitHub account, an omission ultimately led to the data breach it revealed in 2017 after keeping it secret for more than a year, after using its bug bounty program to bribe the hacker to stay schtum.

It’s now stopped using GitHub for anything other than open source projects.

The not-a-taxi company’s chief information security officer John Flynn revealed the GitHub gaffe in testimony (PDF) before the US Senate Senate Subcommittee on Consumer Protection, Product Safety, Insurance, and Data Security, which on Tuesday February 6th conducted a hearing titled “Data Security and Bug Bounty Programs: Lessons Learned from the Uber Breach and Security Researchers”.

The breach saw a hacker access oodles of data from one of Uber’s AWS S3 buckets. Flynn told the hearing “that the intruder found the credential [for AWS] contained within code on a private repository for Uber engineers on GitHub.”

Flynn did not explain how the hacker accessed that repository, but we can guess at a brute-force or password-guessing attack from Flynn’s testimony that “We immediately took steps to implement multifactor authentication for GitHub and rotated the AWS credential used by the intruder.”

“Despite the complexity of the issue and the limited information with which we started, we were able to lock down the point of entry within 24 hours.”

“We ceased using GitHub except for items like open source code,” he added.

Flynn also confessed that its bug bounty program was “not an appropriate vehicle for dealing with intruders who seek to extort funds from the company.” But he also defended its use on grounds that doing so “assisted in the effort to gain attribution and, ultimately, assurances that our users’ data were secure”, while also noting that extortion is not what bug bounty programs should ever reward.

Video testimony from the hearing was not available at the time of writing, so we’re unable to report on Flynn’s answers to any questions directed his way.

We asked GitHub if it was aware Uber all-but-dumped it, and if it has responded to the breach in any way. We did so partly to see what it knew, and partly because Uber dumping GitHub when it hadn’t secured its own repos properly seems a bit harsh.

GitHub responded, telling us “This was not the result of a failure of GitHub’s security. We cannot provide further comment on individual accounts due to privacy concerns.”

“Our recommendation is to never store access tokens, passwords, or other authentication or encryption keys in the code. If the developer must include them in the code, we recommend they implement additional operational safeguards to prevent unauthorized access or misuse.”

Uber’s followed that advice: Flynn said its code now includes only auto-expiring AWS creds. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/02/07/uber_quit_github_for_custom_code_after_2016_data_breach/

Tens of thousands of websites are going to find themselves labeled as unsafe unless they switch out their HTTPS certificate in the next two months.

Thanks to a decision in September by Google to stop trusting Symantec-issued SSL/TLS certs, from mid-April Chrome browser users visiting websites using a certificate from the security biz issued before June 1, 2016 or after December 1, 2017 will be warned that their connection is not private and someone may be trying to steal their information. They will have to click past the warning to get to the website.

The change will come in build 66 of Chrome – due for public release on April 17 – and the problem will get even bigger on October 23 when build 70 is released and all Symantec certificates will be listed as not being trustworthy.

Of course, not everyone uses Chrome and not everyone will instantly upgrade to the latest version, but it’s safe to say that it will become a very big headache very quickly for those sites that haven’t obtained new HTTPS certs from other authorities.

The question is: how big a headache? Early beta testers of the Chrome build have been warning that they keep coming across websites with untrusted certificates and seeing the danger message. Fortunately, one person has gone to the trouble of running a script to figure quite how ugly it’s going to get.

Security engineer Arkadiy Tetelman, who works at Airbnb according to his blog, decided to run a test in which he grabbed the certificate information from the one million biggest websites on the internet, in terms of traffic as rated by Alexa, and tested to see if they would break.

The script took 11 hours to run and turned up some very interesting results: of the one million websites, just 11,510 are going to go TITSUP in April, with 91,627 on the chopping block in October.

When businesses collide

It’s still a large number and there are some big names there – car company Tesla.com, water filter company Brita.com, Australia’s energy regulator at aer.gov.au, and, well, 11,507 others. It’s not Y2K – these outfits can buy certs from other authorities or get free ones – but it’s safe to say that there are going to be a lot of unhappy people come April if action isn’t taken. And then even more unhappy people a few months later.

Fortunately, Mr Tetelman has uploaded a plain text list, so if you are a sysadmin or webmaster, we would strongly recommend doing a search to make sure you’re not on it. Or, of course, be even smarter and move all your sites away from Symantec certificates.

The issue doesn’t raise the slightly troubling fact that Google has basically put an entire company’s certificate-issuing operation out of business by declaring that it would no longer accept Symantec certificates. That’s a scary amount of power to have.

But on the other hand, it wouldn’t be doing it if Symantec hadn’t repeatedly screwed up and undermined trust in its own product by wrongly issuing SSL/TLS certs, including, unfortunately, the one for google.com. Not a smart move.

If you are an organization that exists purely to ensure that people can trust you, then you should expect some fallout if it turns out you can’t be trusted. Symantec wasn’t very happy, of course, and used a whole range of angry words in a blog post about it: words like irresponsible, exaggerated, and misleading.

It claims only 127 certificates were wrongly issued, not the 30,000 previously claimed. But here we are. A few months after its blog post and with Google refusing to budge, Symantec threw in the towel and sold off its certificate business to DigiCert.

Don’t say you haven’t been warned.

By the way, if it’s the morning of Tuesday, April 17, and you are frantically skimming this article in between furious email alerts about your site being down, and phone keeps ringing, focus here: IT’S YOUR HTTPS CERTIFICATE! YOU NEED TO CHANGE IT. RIGHT NOW. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/02/07/beware_the_coming_chrome_certificate_apocalypse/

Tens of thousands of websites are going to find themselves labeled as unsafe unless they switch out their HTTPS certificate in the next two months.

Thanks to a decision in September by Google to stop trusting Symantec-issued SSL/TLS certs, from mid-April Chrome browser users visiting websites using a certificate from the security biz issued before June 1, 2016 or after December 1, 2017 will be warned that their connection is not private and someone may be trying to steal their information. They will have to click past the warning to get to the website.

The change will come in build 66 of Chrome – due for public release on April 17 – and the problem will get even bigger on October 23 when build 70 is released and all Symantec certificates will be listed as not being trustworthy.

Of course, not everyone uses Chrome and not everyone will instantly upgrade to the latest version, but it’s safe to say that it will become a very big headache very quickly for those sites that haven’t obtained new HTTPS certs from other authorities.

The question is: how big a headache? Early beta testers of the Chrome build have been warning that they keep coming across websites with untrusted certificates and seeing the danger message. Fortunately, one person has gone to the trouble of running a script to figure quite how ugly it’s going to get.

Security engineer Arkadiy Tetelman, who works at Airbnb according to his blog, decided to run a test in which he grabbed the certificate information from the one million biggest websites on the internet, in terms of traffic as rated by Alexa, and tested to see if they would break.

The script took 11 hours to run and turned up some very interesting results: of the one million websites, just 11,510 are going to go TITSUP in April, with 91,627 on the chopping block in October.

When businesses collide

It’s still a large number and there are some big names there – car company Tesla.com, water filter company Brita.com, Australia’s energy regulator at aer.gov.au, and, well, 11,507 others. It’s not Y2K – these outfits can buy certs from other authorities or get free ones – but it’s safe to say that there are going to be a lot of unhappy people come April if action isn’t taken. And then even more unhappy people a few months later.

Fortunately, Mr Tetelman has uploaded a plain text list, so if you are a sysadmin or webmaster, we would strongly recommend doing a search to make sure you’re not on it. Or, of course, be even smarter and move all your sites away from Symantec certificates.

The issue doesn’t raise the slightly troubling fact that Google has basically put an entire company’s certificate-issuing operation out of business by declaring that it would no longer accept Symantec certificates. That’s a scary amount of power to have.

But on the other hand, it wouldn’t be doing it if Symantec hadn’t repeatedly screwed up and undermined trust in its own product by wrongly issuing SSL/TLS certs, including, unfortunately, the one for google.com. Not a smart move.

If you are an organization that exists purely to ensure that people can trust you, then you should expect some fallout if it turns out you can’t be trusted. Symantec wasn’t very happy, of course, and used a whole range of angry words in a blog post about it: words like irresponsible, exaggerated, and misleading.

It claims only 127 certificates were wrongly issued, not the 30,000 previously claimed. But here we are. A few months after its blog post and with Google refusing to budge, Symantec threw in the towel and sold off its certificate business to DigiCert.

Don’t say you haven’t been warned.

By the way, if it’s the morning of Tuesday, April 17, and you are frantically skimming this article in between furious email alerts about your site being down, and phone keeps ringing, focus here: IT’S YOUR HTTPS CERTIFICATE! YOU NEED TO CHANGE IT. RIGHT NOW. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/02/07/beware_the_coming_chrome_certificate_apocalypse/