Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Security hole / configuration problem in AFSecurityPolicy.m #2590
[Introduced in the line below, between 2.5.0 and 2.5.1; tested on iOS 8.1.3]
When establishing a security policy for a connection you have two basic options: "pinned" or "not pinned" (default). Selecting pinned mode will then force validatesDomainName to NO.
When it comes to making a decision on whether to trust a domain there is one path that goes as follows:
So if you disable Pinning mode it will ALWAYS accept the certificate. The only way to establish that a certificate is invalid is to set up SSLPinningMode[something, not 'None'].
So the default policy is validatesDomainName = YES, SSLPinningModeNone. This set up results in ALWAYS accepting certificates.
I have verified that a malicious proxy server can sniff all the contents of HTTPS communication in this case.
Please make sure this confusing state of affairs doesn't make it into production applications -- I would love to write a test / fix to help with this but I'm simply not aux fait enough with the libraries involved.
referenced this issue
Mar 12, 2015
PPS. The commit above is designed to test the actual cases, and represent an attempt to set up a test case that matches a sensible (and indeed the previous) set of behaviours. I have tried to create a test case that forces the library to behave in a 'secure is better' way. NB. Initially, changing the behaviour of the function didn't impact the test results significantly, which does suggest that there could be a problem with the tests. either way, I think a stern look at this is appropriate given the implications, and hopefully I have already provided something sensible to work with, if not the actual solution.