iOS 11 Beta - NSURLErrorDomain - code: 18446744073709550617 - ios

When running my app on iOS 11 beta 5 built with Xcode 9 I see this error from several of our network calls.
"NSURLError * domain: #“NSURLErrorDomain” - code:
18446744073709550617"
I've never come across this error before and we haven't made any change to the app currently. For networking, we are using AFNetworking v2.5

So it turns out it was ssl related. Eventually what I did was add an exception for the domain in info.plist and was able to get a reasonable error that said there was an ssl issue. Investigating that showed our cert was weakly signed. We replaced it which resolved the issue.

Related

Swift Realm - ATS failed system trust

I am upgrading a project from Swift 3 to Swift 5. The project uses Realm for an internal database, but every time I launch the app in the simulator I get the following errors in the console:
ATS failed system trust
Connection 2: system TLS Trust evaluation failed(-9802)
I'm pretty sure this is a Realm issue as the app doesn't try to make any other external connections. When running on a older version of Xcode(8), it all works fine without errors. I'm currently testing on Xcode 10.3 and 11 (beta) and using Realm 3.17.3.
Any help would be appreciated.
This error is only produced in the simulator. When running on an actual device no errors get logged

Issue - [ONLY IN iOS 11] : The certificate for this server is invalid. You might be connecting to a server that is pretending to be “DOMAIN.COM”

This issue happens only in iOS 11 But works fine in other versions
So this question is not a duplicate and need to know what could be the cause
Issues details:
I am using a 3rd party library(private) & the issue happens in it.
When we debug the results from the library call we found the following issue log,
The certificate for this server is invalid. You might be connecting to
a server that is pretending to be
“DOMAIN.com” which
could put your confidential information at risk
But if the issue occurs in iOS 10 and below it would be fine and would have decided its common issue. But since it occurs only in iOS 11 I wonder why, Any suggestions or solutions please ?

Different behaviour NSAllowsArbitraryLoadsInWebContent IOS 10.1 and 10.2

When loading a certain url in UIWebView in IOS 10.1 it is failing on
Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made"
However the same webview loads fine in iOS 10.2
I can load the url in both 10.1 and 10.2 if I use NSAllowsArbitraryLoads = YES but only in 10.2 with NSAllowsArbitraryLoadsInWebContent = YES
I tested the URL with nscurl --ats-diagnostics and it passes all tests
I think that the issue may have something to do with an ip location validation within the webpage.
Are the differences between 10.1 and 10.2 in the handling of App Transport Security Settings? Are these documented?
---- Edit -----
I managed to resolve my issue by looking at the error in didFailLoadWithError. This told me exactly what the url was that was causing the failure. I added this url to my Exception Domains with NSExceptionRequiresForwardSecrecy=NO (determined using the ats diagnostics)
This fixed my problem but I still would like to understand the differences in the two versions 10.1 & 10.2.
Yes, earlier versions of iOS 10 did still enforce the forward secrecy requirement of app transport security in web views even with the NSAllowsArbitraryLoadsInWebContent key. That was a bug, that was fixed by Apple. The problem is that earlier versions of iOS shipped with the bug so you must be able to handle it, which isn't always possible if you don't know all the possible URLs that your Web you could navigate to. This may be part of the reason that Apple has extended their deadline for enabling app transport security and all apps submitted to the App Store.

iOS 8.4 CFNetwork SSLHandshake failed (-9850)

My code for ssl handshake fails since I updated xcode to 6.4 (and simulator to ios 8.4). The error is: CFNetwork SSLHandshake failed (-9850)
The same code is performing ssl handshake successfully on ios 8.3 simulator (i've also tried ios 8.3 simulator from xcode 6.4 and it handshakes well).
Here's the piece of code that cofigures and starts handshake. I'm using swift.
self.socket.startTLS([kCFStreamSSLLevel:kCFStreamSocketSecurityLevelTLSv1,
kCFStreamSSLValidatesCertificateChain:kCFBooleanFalse])
I was trying to figure this out whole day and I couldn't even find out what the error code -9850 means. It isn't listed with all the other codes in SecureTransport.h file.
Update1:
I found out that apple introduced app transport security which means that you can declare domains you want to establish secure connection to. Anyway I tried with ATS but without any success. -9850 error is still making problems.
Update 2 - Solution
As Michal and Steven suggested in their answers I started to suspect that the main issue is on the server side which ended up to be true.
I talked with guy who implemented the server and all problems were gone after he generated new ssl certificates of length 2048. Before that they were 512. With new certificates, code on my side works perfectly fine.
-9850 appears in the SecureTransport.h header buried inside the iOS 9 SDK:
errSSLWeakPeerEphemeralDHKey = -9850, /* weak ephemeral dh key */
It sounds like Michal is on the right track. A more general search for this problem led me to http://www.chromium.org/administrators/err_ssl_weak_server_ephemeral_dh_key:
As of Chrome 45, this error message is triggered if the SSL/TLS handshake attempts to use a public key, smaller than 1024 bits, for ephemeral Diffie-Hellman key agreement.
I'm not saying that iOS 9 imposes exactly the same requirements as Chrome, but I'd start looking at the server configuration and if you can increase the key size it uses for the SSL handshake.
I believe it has something to do with coreTLS:
Description: coreTLS accepted short ephemeral Diffie-Hellman (DH) keys, as used in export-strength ephemeral DH cipher suites. This issue, also known as Logjam, allowed an attacker with a privileged network position to downgrade security to 512-bit DH if the server supported an export-strength ephemeral DH cipher suite. The issue was addressed by increasing the default minimum size allowed for DH ephemeral keys to 768 bits.
From what I can tell from your code, I guess you're using GCDAsyncSocket. It has been updated 10 months ago, so it definitely does not reflect this issue.
When I get CFNetwork SSLHandshake failed -(*) its because my device is connected to the network but not the internet.

The network connection was lost error only on iOS7 with AFNetworking

I am using AFNetworking 1.2 library in my app. When I have iOS6 as a base SDK everything works fine, but if I change base SDK to iOS7, then receiving an error in some requests(not all) stating that - "The network connection was lost".
I am not able to find out the cause of the issue, also there is no pattern for this issue as all requests are not failing.
Is there something change in the iOS7 SDK which is causing this issue?
After analyzing issue for 2-3 days, found the root cause of the issue. In response header getting some field which sdk not able to handle.
As others have said, for iOS7, you'll want to upgrade to a newer version of AFNetworking (2.x)

Resources