What is the iOS app sync request content?

I’ve setup a self hosted bitwarden vault server that uses a self-signed cert for TLS/SSL. This works for browsers (chrome on windows, safari on iOS), but the bitwarden iOS app won’t authenticate using a self-signed cert (it seems). I can get around this by just pointing the bitwarden iOS app server setting at an http numerical IP address (with port). This all works great on my LAN or when remoting in via a VPN.

Just to see what would happen, I clicked on sync while my phone had wifi turned off (so traffic over cellular) and while the VPN was down. The bitwarden iOS app stalled on the sync (no timeout that I had patience to wait for), and that got me to thinking: what does the app send out when trying to sync to a self-hosted vault server?

Since my system syncs the app data basically in the clear, i’m hoping that an attempt to sync (to a 192.168.xxx.xxx address) while on WAN doesn’t send out username/masterpassword or vault data before connecting to the expected server.

Does anyone know what the sync protocol is between the iOS app and a self-hosted server? Has anyone sniffed the traffic? I can sort of set this up over wifi on a 10.x network with 192.168 routing turned off, but ouch that’ll be some work.

I just want to make sure I’m not leaking sensitive data if I (or my SO) attempts to sync while the VPN is down.


Hello @jig and welcome to the community,

Are you sure you have installed the Official Bitwarden release? As far as I am aware Bitwarden does not have a way to run simply unencrypted on pure HTTP, the clients and many web-crypto APIs that are called for the web-vault also require HTTPS as I understand.
It could very well be that you have unintentionally downloaded an unofficial 3rd party server instead.

Regarding your concern, I’m not too sure how much of a concern this would be as the clients are meant to encrypt everything in the vault locally prior to communicating with the server.
The Sync function may authenticate with the vault server, but past that all that is sent from the server to the client is simply an encrypted BLOB of your vault data, which is then locally decrypted on your device with the encryption key typically stored in memory while the vault is in an Unlocked state.

Thanks Kent!

i may be experiencing a general DNS issue while connecting via VPN… the vault server is accessible over https (the server functions, and https access functions), but to get the vault server to resolve properly i had to set up a hard mapping locally - the browser access (required to set up the account initially) worked perfectly via a manual hosts file mapping, and then i tried to broaden out the accessibility/flexibility by hard coding the mapping on my router (all DNS traffic goes through my router’s built in resolver - the LAN clients all get passed the router’s gateway address as the only DNS server, and all other DNS traffic is dropped by firewall rule, if i remember correctly).

the new data i have today is that when my laptop is connecting over VPN, the browser can get to the vault server using the hostname mapping and over https (as required by direct browser access), but the bitwarden chrome extension required the numerical http address to and port number be entered in order to sync; the extension would not work after entering just the https hostname.

that makes me think that either i’m mistaken about what’s going on with DNS, or the extension and perhaps the iOS app have a selection of DNS server IPs hard coded into them in such a way to override the host OS DNS server entries. i would expect iOS to have some issues with DNS over VPN, and that maybe the iOS bitwarden app might fall prey to Apple’s choices about DNS in a VPN environment, but the bitwarden extension having its own DNS servers (separate from what the browser is using) would be a surprise.

i’ll be able to be more precise about the above tonight i think. i can be more careful about when i’m flushing DNS cache on the laptops to make sure about what i’m seeing. all i know for sure right this second is that using the win10 hosts file to map the vault server IP address to the hostname i’ve selected (vault.synology) works to get chrome on that win10 machine to access the vault server directly over https properly. (i can’t remember if the browser extension worked too.)

tonight i’ll try to make an exhaustive matrix of https/not-https for browser, browser extension, iOS app, in the context of hosts file DNS mapping, router DNS mapping, and VPN DNS mapping.

my guess is that it’s 90% likely that my hard coded DNS mapping isn’t translating properly over VPN.

if i can get bitwarden to work with a self signed cert, locally hosted vault server, sync only accessible over VPN, then this will be an easily implementable and otherwise perfect setup for moving away from some less reliable password managers, and with a nice security boost (in my opinion, anyway).

oh, another surprise today - i can’t edit a password entry (i.e., i can’t update the password database if i want to change a password) without being able to sync immediately upon save. i had hoped that i could run essentially fully locally, updating my device vault here and there, and then only sync at the end of the day (unless i wanted to force an update earlier), but that does not seem to be the case. that would be a pretty cool option, though it would raise potential issues with out of order syncing (not a big deal i don’t think).