search

bitwarden / mobile

Retired Bitwarden mobile app for iOS and Android (MAUI/Xamarin).
https://bitwarden.com
GNU General Public License v3.0
105 stars 12 forks source link

Not using the native httpClient (and its additional security features) #1140

Open nW553vcRKcxBSVdErBdAeDgxUeR9L1iaqlN71da opened 3 years ago

nW553vcRKcxBSVdErBdAeDgxUeR9L1iaqlN71da commented 3 years ago

It appears that https://github.com/bitwarden/mobile/blob/f1419a75f6441f25dcae0fc20b310c47b2993782/src/Core/Services/ApiService.cs#L24 is not using the native HTTP Client of iOS and Android.

This breaks a lot of enterprise settings - where there is a phone or MDM build in token, x.509 client cert or some other security mechanism in that path.

Steps To Reproduce

  1. Install a client x.509 certificate as a profile.
  2. Go to a URL in the browser (e.g. your bitwarden endpoint throught the enterprise mapping) and observe that Safari can get access
  3. Now do the same in bitwarden - and observe, on the server (or security proxy) that it does not proffer its X.509 when asked.

Expected Result

Both Android and iOS use the native httpClient - and thus get the lower layer security tokens, x.509 or similar bearer headers added as needed.

Actual Result

None of this - it seems some build in version of HTTP is used.

Screenshots or Videos

Environment

Additional Context

Typical enterprise setting with a proxy or a MDM setting.

It is by the way perfectly functional in the desktop clients.

pPmnBRRYhIemiuiy3VBYULJIzQyZaEvWMbCPH1P commented 3 years ago

HttpClient is a Xamarin abstraction that is supposed to implement native http clients on each platform.

nW553vcRKcxBSVdErBdAeDgxUeR9L1iaqlN71da commented 3 years ago

That is what I expected as well. However - it does not seem to be used. HTTP calls do not pass through the URLConnection -- and quick test from Safari, 1Password and XKeeppass show that these do get routed through there (and pick up the security tokens).

So I suspect it somehow either is not going through there - or has some odd flags set that let it bypass the preferences/rules of the 'Profile' on OSX.

On android it is less clear what is going wrong. Happy to provide server-side logs and, if you can provide instructions, client side logs.

pPmnBRRYhIemiuiy3VBYULJIzQyZaEvWMbCPH1P commented 3 years ago

HTTP calls do not pass through the URLConnection

How are you determining this?

nW553vcRKcxBSVdErBdAeDgxUeR9L1iaqlN71da commented 3 years ago

Three tests; one installed an x.509 client cert as a profile; the other running an enterprise MDM that adds a security beaker token. Confirm that safari and several other 3rd party apps that make an HTTPs connection include that token or negotiate the x.509 client when connecting. Observe that the bitwarden client does not. So either it is not using NSURLConnection -or- for some reason it gets routed totally differently than other apps on the same phone.

1YuXBe581qTfLmhbpepO19gt67XynA8U22XtZQe commented 3 years ago

@dirkx I have the same issue and can confirm your certificate test. I don’t have a configuration that can use a bearer token to test on, but I assume it’s pretty much the same issue/flow

If this behaved as desired (presenting the certificate from the iOS “profile” to the gateway/proxy between the Internet and the BitWarden server) it would take care of #582 which has been waiting a long time for someone with the time, interest and capability to pick up. If I’m thinking about it correctly, this issue is really just a much more clear and straight to the point of the description of the actual vs desired behavior in #582 (I think)

Unfortunately, my lack of experience with Xamarin, iOS and Android development makes me not too helpful for anything other than confirming the behavior @dirkx describes and confirming that MDMs using device profiles to deploy device certificates are unable to allow the BitWarden app to authenticate to the BitWarden API via a secure gateway/proxy

The only option for MDM users that I know of is to use the browser, in which case things function as expected- the browser (seamlessly) presents the device certificate when connecting and the BitWarden login page loads.

Last I tested, it worked in Safari, Chrome and Firefox. Using a browser instead of the native app is a workaround, but obviously not a very pleasant experience since the app is where most of the convenience and functionality of BitWarden is provided to users

I’m also happy to offer any help in testing or debugging as I have a live configuration requiring a device identity certificate to access the BitWarden API. I’m not able to test the bearer token model, however. Shouldn’t make much of a difference though, if I understand correctly

rocIy0uFEHpUWf0bZeWIhusiGLPDlKribqMrkVo commented 2 years ago

I'd like to put my support behind this issue, as I'm currently having a similar error (trust chain issue). If the HttpClient can't be modified to accept Android's certificate store, then perhaps the authentication & verification process can be made more permissive to accept certain certificate issues.