There is seems like login issues with Bitwarden Android app, a lot reported are from Malaysian with Unifi ISP.
https://community.bitwarden.com/t/login-pro...ndroid/60958/20

oh no, wife and me are using bitwarden.

seems like the login issues only affects Android app, no such issues logging on vault.bitwarden.com

yes I reported that, people on reddit also facing the same issue with Unifi.

I checked with my adguard home logs, whenever I am connected to wifi and try to login on android, there is not a single request sent to bitwarden. It is like either the app never requested that. But adguard home shows the request when I am on mobile network or VPN.

I have no idea whose fault is this - Unifi, bitwarden, or the app itself. Accessing vault.bitwarden.com on android phone still works, just not the app.

Maybe DNS?
If you get no respond from DNS, sure there will be no single request to bitwarden.

What's the faulty domain name?

I don't have bitwarden so took a blind test with api.bitwarden.com

Unifi fiber, Maxis fiber and Celcom mobile (using Google DNS) resolve to:
2606:4700:4400::6812:28cc
2606:4700:4400::ac40:9334
172.64.147.52
104.18.40.204

However, Unifi fiber goes to Singapore server while Maxis fiber and Celcom mobile goes to Kuala Lumpur server.

Maxis:


Unifi:


Celcom:

My guess is Cloudflare problem. Maybe you need to pass this info to Bitwarden support for further escalation.

EDIT: Tested all the application endpoints listed here with same result:
https://bitwarden.com/help/bitwarden-addresses/

Definitely a Cloudflare issue. Or at least between Cloudflare and Bitwarden server

This post has been edited by kwss: Dec 18 2023, 03:12 AM

Just test for fun.

It might be request the server list data from in.appcenter.ms, so there is some misconfiguration on Microsoft side.
If you connect directly, there is no server loaded, only bitwarden.com available, and no connection made to vault.bitwarde.com.


But...
If you use a VPN(I tested using 1.1.1.1 WARP, on KUL and on SG), it will success on receiving correct data from in.appcenter.ms.

By testing without clear data.
First, it request you to select "Self-hosted" at "logging in on", then saved it, there will be new server bitwarden.eu shown as second choice.
Then, it will success for connecting to vault.bitwarden.com, or vault.bitwarden.eu if you select .eu server.

And, if you reset app(clear data) with VPN enabled, the server list will be requested successful, and showing 2 server which is .com and .eu.
---
So, conclusion, someone at bitwarden fxxked up their server configuration list, and give the wrong server list + configuration to TM/UniFi IP range.
Or
Someone at Microsoft la.

I will said, complain to bitwarden to speed up the fixing.

And correction to my part, so it seem like there is some skip over DNS that I failed to capture, maybe DNS caching happen on my Android phone, lol.

So I find the f-droid version which removed Microsoft appcenter.

https://github.com/bitwarden/mobile/issues/1828

And confirmed it will request the server list from vault.bitwarden.com.
And yes, same issues, the server list will be failed to request.

If I keep looking into github for bitwarden's source code, I sure gonna find which API they are looking to fetch the server list.
But, nah, better keep complain to bitwarden la, lol.

I didn't install the app and test, so I just blindly find some domain and hit it.
If you mitmproxy the app then I trust your analysis is correct.

BTW can I have the endpoint and perhaps the full GET or POST request? I just want to test it.
None of the listed endpoint in the "Bitwarden Addresses" belongs to Microsoft. However I noted func.bitwarden.com indeed is an Azure Function.

It is weird to have an endpoint reply differently based on IP address or telco.

After retest a few time, confirmed it should be cloudflare or bitwarden side issues, because I tried to changing the CloudFlare IP address by modifying the host file, still the same result.

So there is special result given to TM/UniFi customer IP address la...

As above, it still requesting the list of server configuration from vault.bitwarden.com or vault.bitwarden.eu.
For the which get or post request it is asking from, I kind of lazy on performing MiTM the request, lol...

Anyways, if you interesting on looking the source code, here it is.

https://github.com/bitwarden/mobile/pull/2454
https://github.com/bitwarden/mobile/blob/ma...nmentService.cs
https://github.com/bitwarden/mobile/blob/ma...nmentUrlData.cs

Still seeking which one is for the requesting server list, lol.
I wonder why they setup different API than the website version, which is https://vault.bitwarden.com/api/config

A bit tired to looking forward, as I not sleep yet.

Alright. Then just leave it as it is. Since I don't use it, doesn't affect me. At least confirmed is not telco issue.
Full diagnostic can only happen with mitmproxy. Let that be an exercise for bitwarden user.

What to do with Unifi? I thought Bitwarden app can be opened even without any internet access at all?

That's not good.

This post has been edited by gaman: Dec 18 2023, 09:50 AM

Done a bit with mitmproxy, it is getting as this.

https://vault.bitwarden.eu:443/api/config.

GET /api/config/ HTTP/1.1
Accept: application/json
Device-Type: 0
Bitwarden-Client-Name: mobile
Bitwarden-Client-Version: 2023.12.0
User-Agent: Bitwarden: Mobile/2023.12.0 (Android 10; SDK 29; Model HMA-L29)
Accept-Encoding: identify
Host: bitwarden.eu
Connection: Keep-Alive

Then it is dead silence from cloudflare, until timeout.
But should be the MiTM app got issues la, as it get frozen, lol.
---
Hmm, either MiTM app got issues, or it is the real cause found.
Nothing captured, except request head and empty body.

So cloudflare somehow refuse to answer?
Let me see with VPN.
-
And forgot MiTM is works as VPN lol.
Anyways, should enough data, wget etc with http/1.1 might get the answer out la.

vault.bitwarden.eu seem working, only vault.bitwarden.com got issues, hmm...

As the app got cert pin written, so I kind of failed to intercept it la...
---
Yes, if I fill in valut.bitwarden.eu as self-hosted, it works.
Only bitwarden.com down.

And this MiTM not working as it should be lol, lazy to install self-cert then go with fiddler on windows laptop.
Then let it go la, bitwarden issues, lol.

This post has been edited by BenYeeHua: Dec 18 2023, 09:15 AM

Done, with the power of, FIREFOX!!!!!

Someone was DDoS with TM/UniFi IP range of address, with the stupid of HTTP/1.1
So CloudFlare blocked TM/UniFi IP range with the power of, well, "Checking if the site connection is secure"

Solved, bitwarden is stupid one by requesting with old HTTP/1.1, and not supporting the blocking of CloudFlare, lol.

Result out, simple, blocked of cloudflare with request of HTTP/1.1, someone must be brute force with bot/zombie/infected computer running on TM IP range, lol.

And app failed to handle the blocking of cloudflare, double lol.
While app requesting with HTTP/1.1 or app's UA, triple lol!!!
(As that mitm app got issues, it might forcing downgrade the app's connection to HTTP/1.1 for capturing, based on my Tachiyomi skill, CloudFlare partial block based on UA)

In the end, lol!!!
---
Also extra, it is same blocking happen on IPv4 and/or IPv6, as long as it is under TM la.

This post has been edited by BenYeeHua: Dec 18 2023, 09:25 AM

MMM.... I cannot reproduce this problem...
I am on public IP... Those with problem, are you all behind CGNAT?

wget indeed fail on .com but not the .eu... 403.
My Firefox however works beautifully

This post has been edited by kwss: Dec 18 2023, 09:26 AM

Yes, 60.53.x.x.

Can be me testing too much and get blocked, possible, but I was testing on my phone, which is under different IPv6 address, hmm....
Did cloudflare block whole IPv6 range that assigned to each TM customer?
---
Retested again, Firefox

Disabled HTTP2 and HTTP3, only HTTP/1.1 get blocked by CloudFlare
Reenabled HTTP2 and/or HTTP3, solved this issues.

Might better look into the source code of this bitwarden app, see did it support HTTP2/HTTP3 or not?

This post has been edited by BenYeeHua: Dec 18 2023, 09:29 AM

I wget with -4 and -6... Both got 403. So yes looks like the whole 2001:e68/32 is blocked.

Then it is kind of bitwarden's app issues la, even my comic reader app Tachiyomi know to inform me it get blocked by CloudFlare, and asking me to passing the test by opening website via WebView...

Who the hell still using HTTP/1.1 at year 2023, aiyo...

Conclusion, bitwarden(at least Android version) is a lazy developer product, it is better to skip using it, as it seem like iOS app out of this issues...
---

https://github.com/bitwarden/mobile/issues/...mment-975740275


https://github.com/bitwarden/mobile/issues/...ment-1823211981

Kind of reminding me that app showing tips of "Network issues" when it is server caboom, lol.

This post has been edited by BenYeeHua: Dec 18 2023, 09:41 AM

curl which has http2 support indeed success...
So its a combination of factor:
1. The Xamarin used by the Android app (explains why Apple iOS and browser works)
2. Cloudflare DDoS protection is trigger for TM with HTTP/1.1

Why Cloudflare only kills HTTP/1.1 on TM prefix is a mystery. Supposedly if there is an attack, IPv6 should still works since its not NAT.
But seems like they kill the whole AS4788.