[Bug]: Can't use cargo-shuttle behind corporate firewall

[adamrodger]

What happened?

If you are running behind a corporate firewall which does any kind of TLS interception then you can't interact with Shuttle due to the untrusted certificate in the chain

Version

0.34.1

Which operating system(s) are you seeing the problem on?

Windows

Which CPU architectures are you seeing the problem on?

x86_64

Relevant log output

cargo shuttle project list

Getting projects list failed

If getting the projects list fails repeatedly, please check Shuttle status at https://status.shuttle.rs before contacting the team on the Discord server.
Error: failed to make get request

Caused by:
    0: Request error: error sending request for url (https://api.shuttle.rs/projects?page=0&limit=11): error trying to connect: invalid peer certificate: UnknownIssuer
    1: error sending request for url (https://api.shuttle.rs/projects?page=0&limit=11): error trying to connect: invalid peer certificate: UnknownIssuer
    2: error trying to connect: invalid peer certificate: UnknownIssuer
    3: invalid peer certificate: UnknownIssuer

Duplicate declaration

• [X] I have searched the issues and there are none like this.

[iulianbarbu]

Hey, @adamrodger! Thanks for reaching out.

It looks like the firewall can't recognize the authority of the issuer, which for api.shuttle.rs is Amazon.

I am not sure whether adding the Amazon Root CA 1 (https://www.amazontrust.com/repository/) in the firewall certificates store is something you can ask for.

[adamrodger]

The actual cert I need to add is my company Root CA, because corporate firewalls intercept HTTPS, decrypt it and re-sign the stream with their own CA (a classic man in the middle interception, given all your traffic goes through the corporate firewall).

So, I have the Root CA that I need to add, the problem is "which certificate store?".

It doesn't appear to be using the Windows cert store via rustls-native-certs because the cert is installed there, and it doesn't appear to respect the SSL_CERT_FILE env var that rustls supports (presumably because it's a cargo tool...?).

If there was a CA bundle on disk I could edit then I'd add it there, but I don't think there is one?

Preferably there'd be some kind -k/--insecure flag like curl has to just ignore cert errors.

[adamrodger]

I've recompiled cargo-shuttle locally with the reqwest feature rustls-tls-native-roots enabled, and I no longer get certificate errors because that will use the OS cert store instead of the built in one.

Can we maybe make this the default or add an option to configure the built in one?

[iulianbarbu]

Thanks for your investigation @adamrodger! We'll probably want to enable both: extending the rustls root CAs store on demand or default to the OS cert store.

From my understanding, defaulting reqwest compilation to use the rustls-tls-native-roots feature, when compiling cargo-shuttle, should be a low-hanging fruit. This means users will use the native root CA store when doing https traffic through cargo-shuttle. There is a chance though to break some users with this change (in case they have expired certs, or miss a required one), which we'll want to avoid. There are also more downsides with the native root CA store, which are stated here: https://github.com/rustls/rustls-native-certs#should-i-use-this-or-webpki-roots, and we'll want to understand how to go about them.

We might want down the line to have one be the default for cargo-shuttle (e.g. the tls native one), and the webpki-roots based version (bundled by default with rustls), be guarded behind a runtime flag (if possible?), while also giving the option to extend the webpki-roots when needed.

We'll have to give this some thought. We'll discuss this internally and get back with an answer soon.