Open Radar

 
Summary:
When connecting to an untrusted SSL connection, the iOS app receives a challenge via the method:
- (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {

The first time the app receives the challenge, and the authentication method is ServerTrust, the user is prompted to proceed to the untrusted server.  When they accept, the protection space is stored, and the challenge is handled via method:
- (void)performDefaultHandlingForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;
which results in an error response.  The initial request is reissues in the error handler and when the authentication challenge is presented again, and the protection space matched the one stored, the credentials are set based on the trust to complete the challenge via the method:
- (void)useCredential:(NSURLCredential *)credential forAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;

After clearing the stored protection space and waiting for some time and attempting to connect again (over 10 minutes, the timeout for Secure Transport cache detailed in https://developer.apple.com/library/ios/qa/qa1727/_index.html), an authentication challenge is received again.  This falls into a path in the code where the expected behaviour would be to fall into the HTML error handler as it did on the first challenge when resolving it by calling the method:
- (void)performDefaultHandlingForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;

However, the response returned by the request completes successfully with HTTP 200 status, and never falls into the error handler, and the user is never prompted to proceed to the untrusted server again.  It appears that the credentials for the untrusted SSL connection are cached and reused for this second authentication challenge, when the timeout period of the Secure Transport cache has passed.

The second challenge also completes successfully if handled with wither of the following 2 methods:
- (void)continueWithoutCredentialForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;
or
- (void)rejectProtectionSpaceAndContinueWithChallenge:(NSURLAuthenticationChallenge *)challenge;

Steps to Reproduce:
1. Xcode 5.0.2 development environment, application with class handling requests via NSURLConnection, class is an NSURLConnectionDataDelegate.
2. Create a connection to a server with an self-signed certificate via HTTPS, and receive an authentication challenge.
3. Accept the untrusted certificate, and proceed with the connection using the server trust credentials.
4. Wait over 10 minutes.
5. Make a second connection to the same server, and note that there is an authentication challenge again, but the request completed successfully regardless of how is is handled.

Expected Results:
The second authentication challenge will result in an error response when handled via - (void)performDefaultHandlingForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;


Actual Results:
The second authentication challenge results in a successful response when handled via 
- (void)performDefaultHandlingForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;
or
- (void)continueWithoutCredentialForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;
or
- (void)rejectProtectionSpaceAndContinueWithChallenge:(NSURLAuthenticationChallenge *)challenge;


Version:
iOS 6.1.3 and 7.0.6, iPad and iPod Touch

Notes:
Possibly related to another Apple Bug Report:
14085020: Unable to cancel authorization when server certificate changes


Configuration:
Occurs in all configurations