Apple has decided that they will no longer support TLS/SSL certificates that have a valid period of more than 1 year (398 days to be exact) as of 1st September 2020. This means that if, after that date, you order a certificate for your website that has a longer valid period then it will not be trusted on any Apple system, including iPhones, iPads, Apple computers, Safari, etc.
The policy that was unveiled at a Certificate Authority Browser Forum (CA/Browser) meeting on Wednesday (19/02/2020). Accordingly certificates issued after 1st September 2020 will not be trusted if they are longer than 1 year (398 days) but those that were issued before that date will still be honoured.

Why have they done this

The move by Apple to not trust certificates longer than the 398 days is a move to make internet users safer on their platforms. This means that website admins will need to change their certificates on a yearly basis. This has it benefits and drawbacks as it means that technical expertise will be needed more frequently and that there is more chance for expiry dates to be forgotten but it does mean that old forgotten certificates will expire quicker and certificates will be using the latest up-to-date cryptographic standards.
There has been a call for more moving to automated systems rather than manual certificates. Whilst we use automated systems or ACME (Automated Certificate Management Environment), specifically Let’s Encrypt and those systems are great for a certain type of site, it is still necessary to have the higher grade certificates for those who need them. In fact larger websites still use professional certificates with stronger encryption and authentication mechanisms in place. ACME certificates are great as a base level certificate in these days when a website will not be trusted at all if it doesn’t have a certificate, in fact if it doesn’t have a certificate most browsers will actively block access to it.

Digicert’s Dean Coclin issued a memo, here is an excerpt:

“At one time, certificates were offered with a maximum validity of three years. A few years ago, they were reduced to two years. Fast forward to this week’s Apple announcement, which ultimately does what ballot SC22 failed to do: reduce certificate lifetimes to one year.
Why did Apple unilaterally decide to enforce a shorter certificate lifetime? Their spokesperson said it was to “protect users.” We know from prior CA/B Forum discussions that longer certificate lifetimes proved to be challenging in replacing certificates, in the case of a major security incident. Apple clearly wants to avoid an ecosystem that cannot quickly respond to major certificate-related threats. Short-lived certificates improve security because they reduce the window of exposure if a TLS certificate is compromised. They also help remediate normal operational churn within organizations by ensuring yearly updates to identity such as company names, addresses and active domains. As with any improvement, shortening of lifetimes should be balanced against the hardship required of certificate users to implement these changes.”

… “DigiCert agrees that shorter lifetimes help enhance the security of the ecosystem and has the tools necessary to help our customers automate the certificate lifecycle process. We support short-lived certificates, with lifetimes as short as a few hours for customers with advanced automation capabilities. Additionally, our CertCentral platform includes the ability to schedule and automate replacement of EV, OV and DV certificates. Using CertCentral admins may take advantage of continuous discovery, renewal notices, thorough API integration and documentation, as well as support for orchestration layers. CertCentral also allows for multi-year purchases to smooth planning and 24/7 global support enabling the best experience in the industry.
As certificate validity periods continue to decrease, automation will be a must for organizations’ ability to manage shorter lifetimes. DigiCert is prepared with the industry’s most advanced and reliable tools to help our customers take the necessary steps toward greater use of automation.”

Apple has finally fixed the FaceTime Flaw we reported on week before last. They issued a patch (12.1.4) for iPhones (5S+) and iPad Air+ and iPod Touch 6th gen+ on Friday after initially disabling the group chat on the server side. They fixed the server side early last week but still needed to patch the software on the phones, iPads and iPods. This has now been done.

If you disabled FaceTime on your devices, as was advised, then after you install the latest update for your device, it is safe to turn it on again.

The issue was discovered by a 14 year old boy, who was thanked by Apple in their statement, which is here:

We have fixed the Group FaceTime security bug on Apple’s servers and we will issue a software update to re-enable the feature for users next week. We thank the Thompson family for reporting the bug. We sincerely apologize to our customers who were affected and all who were concerned about this security issue. We appreciate everyone’s patience as we complete this process.

We want to assure our customers that as soon as our engineering team became aware of the details necessary to reproduce the bug, they quickly disabled Group FaceTime and began work on the fix. We are committed to improving the process by which we receive and escalate these reports, in order to get them to the right people as fast as possible. We take the security of our products extremely seriously and we are committed to continuing to earn the trust Apple customers place in us.

Don’t forget to install the update first before switching it back on.

Stay Safe.

CritchCorp Computers Ltd.

This is an urgent alert for Apple FaceTime users. A serious flaw has been discovered in Apples FaceTime app on all platforms.

The remedy

Until further notice, Apple recommends turning off FaceTime on your devices and Apple computers.

To do this, go to SETTINGS —> FaceTime and then turn off.

However

What has happened

If you regularly keep up-to-date with security news then you will have heard all about this story. This is intended for those who do not keep up with the news or find it too complicated or technical to follow, or just don’t have time to keep up to date with this stuff. As this is an important story, I have written this brief article about here.

Firstly, who is Mat Honan? He is reporter for Wired magazine and former senior reporter for Gizmodo. He knows a thing or two about technology.

This is a brief sumary about what happened to him a couple of weeks ago. Just so you can be aware and not make the same mistakes as he did. He thought he was safe because he used secure long gibberish passwords, but that did not help him in this case.

In the space of one hour Mat’s entire digital life was destroyed. Here is the order of things that were done:

1. Google account taken over, then deleted
2. Twitter account taken over
3. Apple ID taken over and remotely erased his iPhone, iPad and MacBook

Here is how they did it and what you need to watch out for.

The hackers were only after his Twitter account as he has a nice handle (@mat). To get to this they destroyed his digital life. Firstly, they noticed that his Twitter account was connected to his personal website. On his personal website they found his GMail.com address. Using Google Mails account recovery they discovered that he had a @me.com address, which he used as the backup to receive password resets to.They also had his name and address, which they obtained form his website but could be obtained in a number of ways. Lets face it every time you order pizza you give your name and address, you probably chuck out lots of junk mail with your name and address on it. There are also numerous ways on line to get that information. So, with this information they phoned, yes phoned Amazon. Claiming to be Mat they said that they wanted to add a credit card to their account. With the Name and billing address they were able to do this and using a credit card number made up by a website devoted to generating numbers that conform to the algorithms used they added a card to his account. They then hung up and phoned back and said that they could not get in to their account (Mat’s account). They were then asked for their name, billing address and a credit card on file. Using the credit card they had just added they were then able to add a new email address to the account. They then went to the Amazon website and preformed a password reset to the new email address that they had just added.

They can now see all the credit cards that had been previously added to the account, including the real card that Mat uses. Granted it is only the last four digits of the card as that is what Amazon considers safe to show you (as do a lot of other companies). They now called Apple Care and said that they had lost access to their (Mat’s) @me.com account. Apple kindly helped this fake Mat to recover his password using a temporary password which they issue over the phone which you can then use to access the account and to change the password to the account. This was issued despite the fact that the hackers could not answer any of the security questions on file!! In the end all they needed was his name address and yes, you guessed it the last four digits of a credit card on file.

Once they had hacked in to his @me.com account they could send a password reset from his Twitter account which went to his @me.com address and they quickly reset his twitter account password. This was there intended goal as they could now tweet in his name and upset his followers, just for the fun of it!

Here is the horrible bit: In order to stop Mat from regaining control over his account, they did the following. Deleted his GMail account. Preformed a wipe on his iPhone, iPad and MacBook, thus deleting his entire and only copies of his daughters first year and a half pictures and pictures of relative who are no longer in this word. It was not the intention of the hackers to delete these things but just collateral damage to the main goal, his Twitter account.

You need to be aware of where your accounts lead to and what information you leak out on them. Information these days is very easy to get to because people do not protect it well enough.

Amazon has since confirmed that it will no longer accept information over the phone in this way. Apple has not confirmed yet that it has closed these obvious loop holes, however it did make immediate temporary message and stopped issuing temporary password over the phone, we are still waiting to see what their permanent fix will be.

It is important to note that the companies followed their procedures and the procedures let the customer down. We make it easy from a customer service point of view and that lets the bad guys get in too. It is a shame that we need to have any security at all, it would be nice if we could just have username and no need for a password, but we need passwords and we need to make sure that they are secure and the problem that most companies face is keeping the customer happy, wand secure and that is a tall order as most of the time convenience is the enemy of security. The easiest way to thin of it is a sliding scale with security on one side and convenience on the other. The more convenient we make it the less secure we make it.

Keep your personal data private and do not exposes it unnecessarily. As I have always said, best to have your own domain name and email address and not to use a free generic one for any of your key services, one that you can maintain complete control of and cannot be taken over in anyway by use of social engineering attacks, such as this one. Don’t get me wrong, there are uses for the free accounts but not as your main email address and not as password recovery addresses as these free accounts are constantly hacked in to by this and other methods. They are far too liable to this kind of attack.

CritchCorp.

To get this virus, all you have to do is visit a site that has the malicious code (usually they do not yet know about it either) and the virus will try to install it self, asking permission from the user saying that it is a falsh update that is required. Even if the user does not provide the password the virus can still infect the Mac and after looking around for several different programs it will settle down and phone home for instructions.

To find out if you are infected you can use the list provided by Kaspersky Labs. Go to . All you need to do is enter your UUID (a unique identifier of your Mac, they provide instructions on how to find it). If you are infected then contact us or download the tool provided and run it. This will remove it for you. You then need to ensure that you have antivirus software on your system even though this is a problem in Java, which was fixed in all other formats except for the Mac version because Apple likes to look after it themselves rather than let Oracle (the manufacturer of Java) do it. This has now changed from version 10.7 which requires any user that actually needs Java to download it themselves.

Once you are clean, ensure you run the updates for your Mac by clicking the Apple icon in the top left corner and then upate software. Apple have produced a fix for this bug so get it on as soon as possible.

Anyone who is unsure should email us to book an appointment so that we can come out and check your system for you and advise on the best ways to stay protected. support AT cc-computers.com