github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-05-06 15:58:22 -05:00
Code Issues 1.1k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #1140] Not using the native httpClient (and its additional security features) #13765

New Issue
Closed
opened 2026-04-14 23:25:17 -05:00 by GiteaMirror · 7 comments
GiteaMirror commented 2026-04-14 23:25:17 -05:00
Owner
Copy Link

Originally created by @dirkx on GitHub (Nov 5, 2020).
Original GitHub issue: https://github.com/bitwarden/android/issues/1140

It appears that f1419a75f6/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

  • iPhone 12, App 2.6.1
  • Android 9, App 2.6

Additional Context

Typical enterprise setting with a proxy or a MDM setting.

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

Originally created by @dirkx on GitHub (Nov 5, 2020). Original GitHub issue: https://github.com/bitwarden/android/issues/1140 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. 1. Go to a URL in the browser (e.g. your bitwarden endpoint throught the enterprise mapping) and observe that Safari can get access 1. 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 <!-- Comment: If applicable, add screenshots and/or a short video to help explain your problem. --> ## Environment - iPhone 12, App 2.6.1 - Android 9, App 2.6 ## Additional Context Typical enterprise setting with a proxy or a MDM setting. It is by the way perfectly functional in the desktop clients.
GiteaMirror commented 2026-04-14 23:25:18 -05:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 6, 2020):

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

<!-- gh-comment-id:722722564 --> @kspearrin commented on GitHub (Nov 6, 2020): HttpClient is a Xamarin abstraction that is supposed to implement native http clients on each platform.
GiteaMirror commented 2026-04-14 23:25:19 -05:00
Author
Owner
Copy Link

@dirkx commented on GitHub (Nov 6, 2020):

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.

<!-- gh-comment-id:722936100 --> @dirkx commented on GitHub (Nov 6, 2020): 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.
GiteaMirror commented 2026-04-14 23:25:19 -05:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 6, 2020):

HTTP calls do not pass through the URLConnection

How are you determining this?

<!-- gh-comment-id:723265249 --> @kspearrin commented on GitHub (Nov 6, 2020): > HTTP calls do not pass through the URLConnection How are you determining this?
GiteaMirror commented 2026-04-14 23:25:19 -05:00
Author
Owner
Copy Link

@dirkx commented on GitHub (Nov 7, 2020):

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.

<!-- gh-comment-id:723436460 --> @dirkx commented on GitHub (Nov 7, 2020): 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.
GiteaMirror commented 2026-04-14 23:25:20 -05:00
Author
Owner
Copy Link

@mzpqnxow commented on GitHub (Dec 14, 2020):

@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

<!-- gh-comment-id:744093465 --> @mzpqnxow commented on GitHub (Dec 14, 2020): @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
GiteaMirror commented 2026-04-14 23:25:20 -05:00
Author
Owner
Copy Link

@gbakeman commented on GitHub (Jun 27, 2022):

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.

<!-- gh-comment-id:1166702914 --> @gbakeman commented on GitHub (Jun 27, 2022): 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.
GiteaMirror commented 2026-04-14 23:25:21 -05:00
Author
Owner
Copy Link

@vvolkgang commented on GitHub (Jun 20, 2024):

Issue migrated to https://github.com/bitwarden/mobile/issues/1140

<!-- gh-comment-id:2181546766 --> @vvolkgang commented on GitHub (Jun 20, 2024): Issue migrated to https://github.com/bitwarden/mobile/issues/1140
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#13765
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?