Wow, quite the dilemma. It's like with the US and Chip implementation. It's progressing, but at a snail's pace, even WITH the threat of liability being in effect for about a year now. What does one do when neither the carrot nor the stick are working?
Apple drops requirement for apps to use HTTPS by 2017
One of the initiatives Apple trumpeted at its 2016 WorldWide Developer Conference was a requirement for all iOS and OS X apps in its Store to use adopt App Transport Security as of December 31st 2016. App Transport Security (ATS) arrived in 2015 iOS and OS X in 2015, in Apple's own words, “improves privacy and data integrity …
COMMENTS
-
-
-
Friday 23rd December 2016 14:28 GMT Lee D
Re: Dear Apple
Sorry, but you can own the CA. That doesn't stop the data being encrypted and out of your reach.
A CA only certifies that a particular certificate is associated with a particular domain, and that someone checked that you own the domain.
A certificate request to a CA *DOES NOT* contain the private key. Nor can it. You sign something with your key, send it to the CA, who signs it with THEIR key, and sends it back. At no point are the keys, or any information that would help discover the key, ever sent.
ONLY YOU have the copy of the private key that can decrypt communications made with your key, and all the CA is doing is adding their stamp of approval to your ownership of the domain in question (or that you paid them enough).
The private key is called that because - IT'S PRIVATE. And it is only ever present on the machines handling requests from outside. The CA doesn't have it, isn't given it, and cannot work it out. You give out your PUBLIC KEY (called that because you can give it away to the general public) in the certificate, but that's what you're trying to do anyway, so people know that ONLY the person with your private key could have decrypted stuff encrypted with your public key - i.e. the data they send you can only be accessed by you).
With certificate pinning and certificate transparency, people notice dodgy MITM certs quite quickly, and browsers can do it automatically (try faking a Google cert, even with MITM SSL, without having to import your MITM cert into your trusted store first).
So, please, stop commenting on that which you do not understand. A secure website is secure no matter who signs your cert. If they replace your cert and try to MITM, they will throw up browser errors if you've configured your site anywhere near properly. It's that simple. Even with the full co-operation of the CA.
-
-
-
-
This post has been deleted by its author
-
-
Wednesday 28th December 2016 13:27 GMT David Austin
Halfway House
I think if I was Apple, I would have been tempted to De-list all AppStore Apps that weren't compliment: Existing users could still re-download and install those apps as normal, but no new users could get it: I'm pretty sure most developers would have got a working version out the door pretty quick if new users were cut off to them.
As with TLS 1.x and User Account Control, there's more than a fair few software houses around that seem happy to not implement new security features for as long as possible, until it ends up bothering them by irate users calling/complaining, or it just stops working
-
Thursday 29th December 2016 16:33 GMT Anonymous Coward
Apple messed up. They had a bug in ATS in iOS 10 which made it almost impossible to comply if you used webviews (they key NSAllowsArbitraryLoadsInWebContent doesn't work) . Many companies have been in a panic and spending a lot of money trying to comply, but being hurt by bugs in iOS 10.0 and 10.1...Apparently there are still issues in 10.2 so Apple had no choice but to back off their plans. Leaving it until 21st December to announce the delay shows no respect for app developers or their businesses.