Allow setting an expiration date for the pinning policy about trustkit HOT 7 CLOSED

Oh yeah. I was thinking more along the lines of compromising iOS NTP than manually changing the system time 😉 Not a big deal.

from trustkit.

Would this mean that pinning can be disabled by moving the system date up a bit? I'm not entirely sure but it should be noted in the docs.

from trustkit.

Correct, but pinning is not something meant to prevent someone with full access to the phone from being able to decrypt the device's network traffic (although it may, as a side effect, make it harder).

from trustkit.

@nabla-c0d3 @adamkaplan Might this be better if the expiration date results on a "drop matching connections if pins expired" behaviour, rather than allow all valid certs if pins expired?

Or is this going to be more an optional feature (if exp date provided, check the date etc)?

from trustkit.

It will be optional. If an expiration date is set and we're past the date, TrustKit will not perform pinning validation (any valid cert will be accepted).

from trustkit.

Hey @nabla-c0d3 this actually came up in a review discussion today. The use case we’re thinking about are the small minority of users who do not update their app, their OS, or both, sometimes for years. There are many active users who become unsupportable after some time, and ideally their apps don’t just brick when certs roll a year later. Security degradation makes sense in many cases.

Any idea when you’ll have something ready? Or, do you want some help on this one?

from trustkit.

Yes, that's exactly the use case for an expiration date. I have started looking into this and it should be a quick change - probably a couple weeks at most. Also, if you'd like to use our dashboard for the SSL failure reports, feel free to email me (email is on my GH profile).

from trustkit.