SSL error with Xcode 13.3 beta-2 and iOS 15.4 beta-2

As I am preparing for the latest iOS 15.4 rollout, I downloaded the latest Xcode 13.3 beta 2 update.

To my surprise a previous standard REST call made in my app is now failing with the following network issue when running on an iPhone 13 Pro with iOS 15.4 (beta2).

2022-02-10 11:11:00.944 [Info] [main] [AlamofireNetworkService.swift:24] fetch(route:) > post: https://site.serverdev.net:18100/Users?action=login
2022-02-10 11:11:01.087121-0500 MyApp[50029:13165667] [connection] nw_socket_handle_socket_event [C8.1:3] Socket SO_ERROR [54: Connection reset by peer]
2022-02-10 11:11:01.091555-0500 MyApp[50029:13165884] [boringssl] boringssl_metrics_log_metric_block_invoke(153) Failed to log metrics
2022-02-10 11:11:01.104522-0500 MyApp[50029:13165667] Connection 8: received failure notification
2022-02-10 11:11:01.104715-0500 MyApp[50029:13165667] Connection 8: received ECONNRESET with incomplete TLS handshake - generating errSSLClosedNoNotify
2022-02-10 11:11:01.105049-0500 MyApp[50029:13165667] Connection 8: failed to connect 3:-9816, reason -1
2022-02-10 11:11:01.105174-0500 MyApp[50029:13165667] Connection 8: encountered error(3:-9816)
2022-02-10 11:11:01.106574-0500 MyApp[50029:13165667] Task <F53C7A17-7297-4566-9746-1D39807E8356>.<5> HTTP load failed, 0/0 bytes (error code: -1200 [3:-9816])
2022-02-10 11:11:01.118796-0500 MyApp[50029:13165920] Task <F53C7A17-7297-4566-9746-1D39807E8356>.<5> finished with error [-1200] Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." UserInfo={NSErrorFailingURLStringKey=https://site.serverdev.net:18100/Users%3Faction=login, NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <F53C7A17-7297-4566-9746-1D39807E8356>.<5>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
  "LocalDataTask <F53C7A17-7297-4566-9746-1D39807E8356>.<5>"
), NSLocalizedDescription=An SSL error has occurred and a secure connection to the server cannot be made., NSErrorFailingURLKey=https://site.serverdev.net:18100/Users%3Faction=login, NSUnderlyingError=0x6000016e6850 {Error Domain=kCFErrorDomainCFNetwork Code=-1200 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, _kCFNetworkCFStreamSSLErrorOriginalValue=-9816, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9816, _NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: utun3}}, _kCFStreamErrorCodeKey=-9816}

I see there is an error related to the TLS handshake and following that a generic error saying "a secure connection to the server cannot be made".

I ran the same call against the iPhone 13 Pro with iOS 15.0 on the same Xcode 13.3 beta2 version and the call succeeds as expected. This leaves me to believe the issue is tied to the iOS 15.4 beta layer. The release notes don't state any particular mention of SSL requirement changes and am wondering how else I can go about to investigate this issue. (The server I am communicating with enforces TLS 1.2)

Up vote post of MattChan Down vote post of MattChan
2.9k views
Posted by
MattChan
Reply

  • Isn't the issue with Alamofire library ? Did you contact them for an update ?

    —
    Claude31

  • I opened a support ticket on the Alamofire github as well. If there is any feedback on that end I will update this thread. Thought it would be a good idea to open a thread here in case someone else is encountering this kind of issue after the latest beta release.

    —
    MattChan

  • Update from Alamofire ticket: "There's nothing Alamofire can do about underlying TLS errors from the OS. I suggest you investigate your TLS configuration and report a bug to Apple." Was marked as closed on their end.

    —
    MattChan

Accepted Reply

It looks like there was an update on your bug report today that the cipher suite for TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 was removed from the latest version of BoringSSL. An alternative here would be to try using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 instead.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Posted by
meaton
Up vote reply of meaton Down vote reply of meaton
Post marked as solved

  • Thanks. I will be performing an upgrade on the server side to validate the fix is indeed related to the cipher suite supported versions.

    —
    MattChan

  • After upgrading the backend server, I can confirm the issue is resolved. Thanks again for the quick feedback and support.

    —
    MattChan

  • Excellent. Thanks for the update!

    —
    meaton
Add a Comment

Replies

I ran the same call against the iPhone 13 Pro with iOS 15.0 on the same Xcode 13.3 beta2 version and the call succeeds as expected.

Since this is the case, please open a bug report and take a packet trace of this issue taking place. Then send me the Feedback ID.

Note that you are receiving:

2022-02-10 11:11:01.087121-0500 MyApp[50029:13165667] [connection] nw_socket_handle_socket_event [C8.1:3] Socket SO_ERROR [54: Connection reset by peer]
...
2022-02-10 11:11:01.104715-0500 MyApp[50029:13165667] Connection 8: received ECONNRESET with incomplete TLS handshake - generating errSSLClosedNoNotify

So take a look at the server logs because iOS is telling you that the server hung up the connection during the handshake. I suspect that this is during the Server Hello packet but your packet trace will tell you for sure.

Also note this update to our trusted roots that are in the existing iOS Trust Store. What does that mean? It means that some of the CA roots that exist in the trust store today are no longer trusted. Make sure your leaf is not derived from one of these CAs.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Posted by
meaton
Up vote reply of meaton Down vote reply of meaton

  • Thanks for the reply. I am trying to run the trace packets using the rvictl -s udid command however it does not seem to be working on my macbook pro 2019 (macOS Monterey 12.2, intel chip). It also does not seem to detect any of my devices using the rvictl -l command. I will try to get this sorted out and get back to you with the Feedback ID ticket once I am able to run the trace packet command.

    —
    MattChan

  • May need to enable the System Extension and restart.

    —
    meaton

  • Bug report submitted. FB9935377

    —
    MattChan
Add a Comment

Bug report submitted. FB9935377

Thank you. I took a look at your packet trace for iOS 15.4 Beta and it looks like the one TLS failure that's in there is in TCP Stream 2, or tcp.stream eq 2. It looks like the client offers the client hello packet and the server never sends the server hello packet back. Instead, the server waits for a half a second and then sends a reset packet to close the connection.

The only thing unique about the client hello packet is that it's negotiating TLS 1.3 and setting up the initial handshake for connection resumption with a PSK. You can tell this because the key_share extension is provided. As a test, what happens if you test this with TLS 1.2?

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Posted by
meaton
Up vote reply of meaton Down vote reply of meaton

  • I uploaded the ticket with more traces where I enforce TLS 1.2 on the URLSession object. The same problematic behaviour is present. Thanks

    —
    MattChan
Add a Comment

It looks like there was an update on your bug report today that the cipher suite for TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 was removed from the latest version of BoringSSL. An alternative here would be to try using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 instead.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Posted by
meaton
Up vote reply of meaton Down vote reply of meaton
Post marked as solved

  • Thanks. I will be performing an upgrade on the server side to validate the fix is indeed related to the cipher suite supported versions.

    —
    MattChan

  • After upgrading the backend server, I can confirm the issue is resolved. Thanks again for the quick feedback and support.

    —
    MattChan

  • Excellent. Thanks for the update!

    —
    meaton
Add a Comment