Xcode 9 iOS 11 BoringSSL SSL_ERROR_ZERO_RETURN

Question

I have a simple program HelloWorld running on iOS. The same code has been running fine for a long time. Recently, I notice that I get the below BoringSSL error when the program runs on my ipad connected to Xcode 9 on my Macbook. I don't see this error when I run the program in simulator. The iOS is 11.2. Xcode is 9.2.

My code has no reference to BoringSSL. However, it does use NSMutableURLRequest to make https call to a server. The call works fine and everything seems to work fine except the BoringSSL messages.

Is there a way the I can debug why the message comes up? HellowWorld[466:85961], what do those 2 numbers mean?

What does the message mean and how to avoid it?

2017-12-13 15:41:13.486047-0500 HellowWorld[466:85961] [BoringSSL] Function boringssl_session_errorlog: line 2871 [boringssl_session_read] SSL_ERROR_ZERO_RETURN(6): operation failed because the connection was cleanly shut down with a close_notify alert
2017-12-13 15:41:13.486363-0500 HellowWorld[466:85961] [BoringSSL] Function boringssl_session_errorlog: line 2871 [boringssl_session_read] SSL_ERROR_ZERO_RETURN(6): operation failed because the connection was cleanly shut down with a close_notify alert

Answer 1

For those of you for whom the above methods did not work, this is what the problem was in my case:

I was sending a GET request with a JSON request body using Alamofire. I changed it to a GET request that contains the parameters as query parameters in the URL instead (along the lines of GET https://your-api.com/v1/request?param=value). Then it worked flawlessly.

Answer 2

I managed to fix the issue by adding the "App Transport Security Settings" key to the info.plist. Make sure that "Allow Arbitrary Loads" is set to "Yes".

Answer 3

Is there a way the I can debug why the message comes up?

Yes, there is, and I'm a bit surprised it hadn't been mentioned yet.

CFNetwork handles the core of Foundation’s networking classes — It also has the (often overlooked) capability of detailed logging via the CFNETWORK_DIAGNOSTICS environment variable.

Programmatically enabling CFNetwork diagnostic logging:

setenv("CFNETWORK_DIAGNOSTICS", "3", 1);

It should be set to an integer value from 0 to 3, where 0 is off and higher numbers give progressively more logging. During normal development you can set this environment variable via Xcode’s scheme editor. When the app is run from Xcode, the CFNetwork log entries will appear in the debug console area (if not visible, choose View > Debug Area > Show Debug Area).

The environment variable should be placed right at the beginning of the app’s launch sequence. Normally putting this at the start of main is sufficient, but if you have C++ static initialisers that use CFNetwork you’ll have to put it before those.

Note: In Swift this code would go in main.swift. By default Swift apps don’t have a main.swift; “The Swift Programming Language” explains how to add one.
_{*Also note, in Swift remove the semi-colon at the end of the setenv.}

Setting the environment variable above should definitely help in determining where the issue is, or at the very least give you a starting point to begin diagnosing a somewhat vague error message.

↳ CFNetwork Diagnostic Logging

Answer 4

I got a similar message when trying to use NSLog to post a very long list as it would post the list for a long time in the debug console then it so list part of the list followed by a few ... to show there was more that was not printed in the console, I fixed this (using OBJ-C) and adding this #define to my VC.m

#define NSLog(FORMAT, ...) printf("%s\n", [[NSString stringWithFormat:FORMAT, ##__VA_ARGS__] UTF8String]);

perhaps you can use something similar to your swift project.