mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-04-26 09:46:00 +03:00
[GH-ISSUE #1101] Android app complaining about TLS handshake when SSL enabled #780
Labels
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
question
troubleshooting
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/vaultwarden#780
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
Originally created by @JohnnySSH on GitHub (Aug 15, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1101
Subject of the issue
I am not able to access BitWarden using the Android app when using the SSL method. If I disable SSL then I have no problem with the app but of course then browsers do not allow entry to the Vault.
I am able to access properly with any browser (mobile or desktop based) when SSL is enabled. Initially I posted a report at the hassio addon project:
https://github.com/hassio-addons/addon-bitwarden
but got referred here as it may a deeper problem then just the addon.
Your environment
Install method:
HomeAssistant app install
Base system runs Arch Linux with Docker
Clients used:
Android App version 2.5.0
Nginx supplied with addon (see below)
Add-on version: 0.6.2
You are running the latest version of this add-on.
System: Arch Linux (amd64 / qemux86-64)
Home Assistant Core: 0.114.0
Home Assistant Supervisor: 234
Steps to reproduce
Obtained a certificate using Let's Encrypt. Created a DNS fqdn for the server. Enabled SSL on the server side.
Expected behaviour
I should be able to login like I am able to while not using SSL.
Browsers can access the Vault without any issues.
Actual behaviour
An error has occurred.
Exception message: Handshake failed
Relevant logs
Unfortunately nothing is mentioned in the logs even when enabling debug
@mqus commented on GitHub (Aug 15, 2020):
Which Android version do you have? Some older android versions might have difficulties to connect to a modern web server.
Anyways, for analyzing this it might be helpful to have some tcp captures from the handshake, recorded with e.g. wireshark. You could also try to read the android logs with adb logcat (not entirely sure if that is the right name) to see what happened in the app.
Be aware though, that your server version is a bit outdated.
@JohnnySSH commented on GitHub (Aug 15, 2020):
The Android version is the latest from the Play Store which is 2.5.0.
I'll try the wireshark route and see what happens.
If my Bitwarden version is a little old, then that might be what is causing the issue. I'll have to report back to try and get it updated if that is the case to see if there is an improvement.
@mqus commented on GitHub (Aug 16, 2020):
Sorry, you are misunderstanding me. I meant the version of the Android OS (Something between 2.3("Gingerbread", very old) and 11.0("Red Velvet Cake", not released yet)) not the version of the app(which you thankfully already posted).
Could you also post the relevant bits of the nginx SSL configuration? I just read your initial post again and if you're using nginx to create the SSL connection then bitwarden_rs should not have any issues. It has to be the nginx configuration, the bitwarden android app(incl. configuration) or any firewall you put in between, although the firewall thing would be very unlikely.
Another thing that I just noticed was that the app message (Handshake failed) does not specifically include "TLS". Anything other than TLS would be weird since your server didn't log anything but let's keep it in mind.
@JohnnySSH commented on GitHub (Aug 16, 2020):
Oops sorry. One device is running Android 10 or 11 - Samsung Galaxy Tab S6, the other devices are running Android 7 - Samsung Galaxy S6 Edge phones.
I just tested via Wireshark and it reports that TLSv1.0 is attempted to be used??
Here is the Nginx config that comes as default with HomeAssistant:
nginx.conf.txt
nginx.proxy.conf.txt
@mqus commented on GitHub (Aug 16, 2020):
I don't know much about nginx but the config looks reasonable from a first glance.
normally the client requests a range of TLS versions, TLSv1.0 should be the minimal version,and for your android versions TLSv1.2 should absolutely work. I don't know why the app would use TLSv1.0. But the TLS versions seem to be specified twice in the handshake packet, once in the Record Header and once in the Handshake, see https://tls.ulfheim.net/ for a good explanation. are they both TLSv1.0?Do the nginx logs show anything interesting?
Did you try the browser addon and what happened?
EDIT: The range thing is wrong. I forgot to remove it before posting.
@JohnnySSH commented on GitHub (Aug 16, 2020):
Just checked again with Wireshark and both are TLSv1.0. I'll see if I can find the logs as they are in non standard locations on this box and see if anything interesting is shown...
@JohnnySSH commented on GitHub (Aug 16, 2020):
A little more digging and it seems that the client is first starting with TLSv1.2 then going down to 1.1 and then finally 1.0.
At this point I'm not sure if the issue is with the app or with the Nginx proxy which apparently is held in the docker and non-editable.
What I have done also is re-checked the certificate using: https://www.digicert.com/help/
The result is as follows:
Protocol Support
TLSv1.2
TLSv1.3
TLS ciphers supported by the server
TLSv1.2
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLSv1.3
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
so if it's not the server then it must be the client?
@JohnnySSH commented on GitHub (Aug 17, 2020):
Ok here it gets a little strange....
I managed to successfully login using a Google Nexus 7 tablet which runs Android 6.
It seems the issue is related to the Samsung Galaxy S6 and/or Android 7. I'm not sure about the Galaxy Tab as I'll need to have a look at that but definitely something hinky on the S6 side.
@mqus commented on GitHub (Aug 17, 2020):
Android 7 rings a few bells.
https://forum.syncthing.net/t/android-and-tls1-2/12931/6
@JohnnySSH commented on GitHub (Aug 17, 2020):
Ok this is starting to get really confusing....
In the provided link, they initially talk about missing cipher suites within Android 7, then they talk a bug, and at the end DNS is mentioned.
I tested with the Galaxy Tab which runs Android 10, it is on the same subnet as all the other devices (Nexus 7 and Galaxy S6), the initial result was an error message stating that "the operation was cancelled" after spending a few seconds trying to login.
I then turned on OpenVPN. OpenVPN only creates a secure tunnel between my firewall and the device, so name servers and everything else is the same; the IP address is still the same (not the tunneled IP but the one obtained from DHCP).
It worked after this!
Android 7 with OpenVPN active gives a different error message. "the operation was cancelled"
Now I am completely lost and I don't even know if all of these are the same issue any more with the different error messages ???
@JohnnySSH commented on GitHub (Aug 17, 2020):
Just tested the Galaxy Tab again without the VPN and it works fine. Looks like it's Android 7 issue after all which doesn't contain the correct cipher suite and/or has bugs :-S
@mqus commented on GitHub (Aug 17, 2020):
Did you try any browser extension? Those should always have the right cipher suites and everything but connect the same way as the apps do. Other than that I have no clue. I linked Android 7 because of the missing cipher suite. You can look with wireshark into your handshake of TLS 1.2 and compare the cipher suites yourself(first and second packet) and also look what wireshark says on why the connection was retried with TLS 1.1 and 1.0. Does anyone else have similar issues on Android 7?
@mqus commented on GitHub (Aug 18, 2020):
I'm also linking https://github.com/hassio-addons/addon-bitwarden/issues/37 (the initial issue) and https://github.com/dani-garcia/bitwarden_rs/issues/687 (which might be related and contains some suggestions)
@blackneil commented on GitHub (Aug 18, 2020):
I have the same issue. I come to install Bitwarden RS on my Synology.
DSM : 6.2.3-25426 Update 2
Dockers : 18.09.0-0513
Bitwarden_RS :
Server : 1.16.3
Web : 2.15.1
Variables Configured :
DOMAIN, SMTP_HOST, SMTP_FROM, SMTP_PORT, SMTP_SSL, SIGNUPS_ALLOWED, SIGNUPS_DOMAINS_WHITELIST, SIGNUPS_VERIFY, ADMIN_TOKEN
I also use the reverse proxy integrated into the DSM for use a SSL from my ADCS.
On a PC :
Firefox 79.0 (64 bits) : OK
Google Chrome 84.0.4147.125 (Build officiel) (64 bits) : OK
Bitwarden v1.20.1 - Shell 6.1.7 - Renderer 76.0.3809.146 - Node 12.4.0 - Arch. x64 :
vendor.js:122299 POST https://%FQDN%:%PORT%/api/accounts/password-hint net::ERR_CERT_COMMON_NAME_INVALID
vendor.js:122299 POST https://%FQDN%:%PORT%/api/accounts/prelogin net::ERR_CERT_COMMON_NAME_INVALID
vendor.js:122299 POST https://%FQDN%:%PORT%/api/accounts/register net::ERR_CERT_COMMON_NAME_INVALID
iPhone SE (iOS 13.6.1) :
Safari : OK
Bitwarden 2.5.0 : SSL error, can't establish a sercured connection
Galaxy Tab A (Android 10) :
Google Chrome (uptodate) : Warning on the SSL but I can continue and it's OK.
Something with the certificate or in the communication appear no more compliant for the application.
@blackneil commented on GitHub (Aug 21, 2020):
An small update : I don't have found a way with my ADCS but everything work fine with an SSL from zerossl.com (free 90 days) or ssl.com (trial 90 days).
@BlackDex commented on GitHub (Nov 18, 2020):
Closing this ticket because of inactivity.
Feel free to continue this discussion on the forum: https://bitwardenrs.discourse.group/