Post not yet marked as solved
Hi!
Sometimes when calling
DCAppAttestService.shared.generateAssertion(key.id, clientDataHash: hash)
I'm getting DCError.Code.invalidInput. I am formatting clientDataHash usingSHA256.hash - so it is always 32 bytes long.
As I found out - this error depends on hash that I pass to generateAssertion method. But I could not find any system - which hashes are good and which are not.
Keys are always correct, otherwise invalidKey error would be risen.
What can cause the issue? I'm testing on iPhone 11, iOS 15.2.1
Post not yet marked as solved
Hi!
We are using Device Check tokens to prove that HTTP request comes from iOS device.
We found out that both envs - prod and sandbox doesn't limit token lifetime
v1/validate_device_token always return true and can be reused for a long period of time per one DCDevice token.
v1/update_two_bits also can be reused unlimited number of times per one token (didn't measure the exact number)
Is it true - that lifetime of token generated via DCDevice.generateToken isn't short (minutes) and we should build our own infrastructure to prevent replay attacks?
Post not yet marked as solved
Hi!
In the past few weeks we detected over 90 affected users with the following crush log:
std::__1::__shared_weak_count::lock()
CFNetwork
HTTPConnection::_onqueue_doNotAllowMoreRequests()
CFNetwork
HTTPConnectionCacheEntry::ConnectionArray::stopAndRemove(long)
CFNetwork
HTTPConnectionCacheEntry::_removeConnection(std::__1::shared_ptr<HTTPConnection>)
CFNetwork
HTTPConnectionCacheEntry::purgeIdleConnections(double, double)
CFNetwork
HTTPConnectionCache::performIdleSweep()
Unfortunately, our investigation haven't given any results. Did anyone experienced such crushes?
Top iOS versions for the crush:
12.5.4 30%
14.4.2 14%
12.5.3 6%