{"action":"closed","issue":{"url":"https://api.github.com/repos/AFNetworking/AFNetworking/issues/2690","labels_url":"https://api.github.com/repos/AFNetworking/AFNetworking/issues/2690/labels{/name}","comments_url":"https://api.github.com/repos/AFNetworking/AFNetworking/issues/2690/comments","events_url":"https://api.github.com/repos/AFNetworking/AFNetworking/issues/2690/events","html_url":"https://github.com/AFNetworking/AFNetworking/issues/2690","id":71621605,"number":2690,"title":"AFNetworking 1.2.0 - 1.3.4 does not validate the domain name in the SSL cert","user":{"login":"natecode","id":1581257,"avatar_url":"https://avatars.githubusercontent.com/u/1581257?v=3","gravatar_id":"","url":"https://api.github.com/users/natecode","html_url":"https://github.com/natecode","followers_url":"https://api.github.com/users/natecode/followers","following_url":"https://api.github.com/users/natecode/following{/other_user}","gists_url":"https://api.github.com/users/natecode/gists{/gist_id}","starred_url":"https://api.github.com/users/natecode/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/natecode/subscriptions","organizations_url":"https://api.github.com/users/natecode/orgs","repos_url":"https://api.github.com/users/natecode/repos","events_url":"https://api.github.com/users/natecode/events{/privacy}","received_events_url":"https://api.github.com/users/natecode/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":44,"created_at":"2015-04-28T15:27:57Z","updated_at":"2015-05-03T18:55:54Z","closed_at":"2015-05-03T18:55:54Z","body":"Some number of versions of AFNetworking (not done with reviewing/testing all of them) from 1.2.0 up through 1.3.4 are vulnerable to the domain validation flaw if pinning is not in use + properly configured. This is because AFNetworking/AFURLConnectionOperation.m only creates policies of type SecPolicyCreateBasicX509 (not SecPolicyCreateSSL, which does hostname validation). It’s the same behavior that 2.x has before 2.5.3, just different code.\r\n\r\nIt was first reported in 2013, but never properly fixed in 1.x. We don’t know how many versions of 2.x are also vulnerable. \r\n\r\nIssue: https://github.com/AFNetworking/AFNetworking/issues/1157\r\nPull request: https://github.com/AFNetworking/AFNetworking/pull/1564/\r\n\r\nThere are some interesting parts to the patch, such as self-tests that would have detected the 2.5.2 domain name validation problem (default should be YES). I don’t know what happened to this patch in 2.x as we are still analyzing the history of the AFN SSL code.\r\n\r\nUsers are vulnerable if they use AFHTTPClient for SSL. We successfully ran MITM against a demo app with AFNetworking 1.3.4. This version also happens to be embedded in the RestKit tree, and there are a lot of users of RestKit.\r\n\r\nWe verified it as follows. Configure Burp Proxy to present a cert with the wrong domain name (say, `yahoo.com` for a connection to `sourcedna.com`). Install Burp’s root CA cert on your device or simulator. Make a request to `https://sourcedna.com` with NSURLConnection and see validation returns errors. Then use AFHTTPClient and see that it trusts the server.\r\n\r\nTest snippet:\r\n\r\n    AFHTTPClient *httpClient = [[AFHTTPClient alloc] initWithBaseURL:url];\r\n    NSMutableURLRequest *req = [httpClient requestWithMethod:@\"GET\"\r\n           path:@\"https://sourcedna.com\" parameters:nil];\r\n    AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc] initWithRequest:req];\r\n    …\r\n\r\nThanks,\r\nNate (SourceDNA)"}}