feat: support SSL pinning

[eseidel]

My guess is that we will implement this via #114, but i'm breaking it out into a separate issue in case there is a simpler solution.

[eseidel]

My guess is the best way for us to implement this is by shelling out to the platform APIs, bouncing up through the Flutter engine api layer (e.g. flutter.jar or Flutter.framework) exposing a Java/Kotlin or Obj-C/Swift callback?

This is on the assumption that:

1. There are wider benefits to us using platform networking (rather than Rust's like we do today), see feat: Make it possible to use the platform-provided networking apis #114.
2. That some customers may already be doing SSL pinning at the "native" layer and this would allow hooking into such.

Questions to mull over:

• Last I knew, it was common on Android not to use the default networking libraries (rather okhttp, etc.), I'm not sure if that's still the case, but that might inform the design of such callbacks.
• Does such introduce product risk for us (relying on callbacks controlled by the developer to reach Shorebird's servers)?
• Would it be simpler to instead provide some API to provide pinned certs down to the rust layer and make Rust do the SSL pinning?

[eseidel]

We currently use reqwest in our rust code.
https://github.com/shorebirdtech/updater/blob/main/library/src/network.rs#L68

It's not clear that reqwest has out of the box ssl pinning:
seanmonstar/reqwest#298

[eseidel]

OK, I looked into this a little more and I think we can do even simpler on the client side:

It should be possible with reqwest ClientBuilder to just add our api.shorebird.dev cert and download.shorebird.dev certs as "root certs" and remove all other certs in reqwest. That should effectively pin those two, as they'll be the only allowed certs our rust code would know how to connect to:
https://docs.rs/reqwest/latest/reqwest/struct.ClientBuilder.html#method.add_root_certificate
https://docs.rs/reqwest/latest/reqwest/struct.ClientBuilder.html#method.tls_built_in_root_certs
We use rust-tls today:
https://github.com/shorebirdtech/updater/blob/main/library/Cargo.toml#L42

We could then simply offer an option in shorebird.yaml to enable this behavior. This would be disabled by default as it would cause updates to stop working when those certs expired.

There is also some complexity on our server side to consider:

We would likely have to update our SSL policies, as our current certs expire every 3 months. I also suspect that we would need to be able to know our next cert ~30 days ahead of time to include in updates.

[eseidel]

If customers expect to proxy our urls (and maintain their own certs) that's also possible, and would just require us to add an API for customers to provide a cert. The easiest way is probably also just to do so via a path in shorebird.yaml which could be resolved against flutter assets.

[eseidel]

So the primary blocker here is understanding customer needs. I think the better option will be for a customer to proxy our servers and end up managing the SSL pinning themselves. That would allow them to control the expiration of SSL certs. Currently our SSL certs rotate every 3 months automatically (through Google) and we don't currently have a way to know what the next ones will be, so we would have to change our SSL cert rotation (which can be done) in order to be able to build applications with SSL pinning which didn't suddenly stop working every 3 months.

So right now this is blocked on better understanding a customer's needs and working with them to build something they need here. I believe our other security measures we have planned (like shorebirdtech/shorebird#112) will be much more effective at preventing any potential MITM tampering of patches distributed via Shorebird.