Implementing "browser style" certificate validation / acceptance

[Joseph Heenan]

Hi all,

I've a need in the app I'm working on at the moment where it needs to
sometimes be used against servers that don't have proper signed SSL
certificates.

Ideally rather than switching off validation altogether (which would
obviously be a bad thing) I'd like to do something similar to what
desktop clients tend to do - tell you the certificate is invalid, that
this means something is bad, but still offer you the chance to proceed
and remembering that choice at least for the current session.

It sounds like a similar issue to the one discussed here:

https://devforums.apple.com/message/431758#431758

and here:

http://groups.google.com/group/asihttprequest/browse_thread/thread/4f47ad11a92e4005

and here:

https://github.com/sixten/asi-http-request/commit/c4f1c1485943e2c2d15df2e8cd88c08bf1b0fcc4

The discussion seemed to die out without any real conclusion though -
has anyone managed to get this (or some other concept that might achieve
roughly the same goal) to work?

Any thoughts would be very welcome!

Thanks

Joseph

[Bart Whiteley]

I need to implement this sometime in the next 2-3 months. If you need
it sooner, I could collaborate with you on a patch.

It sounds like it might be difficult to implement properly, based on
the response I received in your second link above. It may be
difficult to intercept the certificate before the first request has
been sent. One option would be to set
shouldPresentCredentialsBeforeChallenge=NO, and then validate the
server certificate when reading the first response (which would
presumably be an authentication challenge). Depending on individual
use cases, this may or may not be sufficient.

It would be nice to get an opinion from Ben or others on how to
address this issue before I/we begin an implementation.

[Ben Copsey]

Hi Joseph and Bart

The comments in sixten's fork suggest that kCFStreamEventCanAcceptBytes will not be called, but there's always kCFStreamEventOpenCompleted. handleNetworkEvent doesn't currently look for this (it would also need to be added to kNetworkEvents at the top of ASIHTTPRequest.m). Quinn's comments on the dev forum also suggest this, and he also points to using a custom read stream, which we already have in the form of ASIInputStream. At the very least, you can prevent the request sending any body with this (return zero from read:maxLength:), but it seems likely that the headers won't get sent either because of CFNetwork's internal buffering.

So, it *might* be workable... :)

Best,

Ben

[Joseph Heenan]

Hi Ben, Bart,

On 14/05/2011 11:43, Ben Copsey wrote:
> The comments in sixten's fork suggest that
> kCFStreamEventCanAcceptBytes will not be called, but there's always
> kCFStreamEventOpenCompleted. handleNetworkEvent doesn't currently look
> for this (it would also need to be added to kNetworkEvents at the top
> of ASIHTTPRequest.m). Quinn's comments on the dev forum also suggest
> this, and he also points to using a custom read stream, which we
> already have in the form of ASIInputStream. At the very least, you can
> prevent the request sending any body with this (return zero from
> read:maxLength:), but it seems likely that the headers won't get sent
> either because of CFNetwork's internal buffering.

Thanks to you both for your feedback; that's certainly useful, and glad
to know it may be possible.

I'm not sure if/when I'll tackle this (still hoping that sense will
prevail and certificates be purchased!), but I'll definitely share any
results with the list if I do.

Thanks

Joseph